All posts

The never-list: boundaries to set before you give an agent connectors

Connectors are the moment an agent stops being a chat window and starts being a coworker with keys, and almost nobody writes the rules down first.

The first time I gave an agent write access to something real, it was my own CMS. Not a client's. Mine, on purpose, because I wanted to find out what breaks when the thing that has been drafting posts for me can also publish them. What broke wasn't dramatic. It didn't nuke a database or email a customer list. It did something much more ordinary and much more instructive: it edited a page I hadn't asked it to touch, because that page was adjacent to the one I asked about and fixing it was clearly helpful. It was right that the page needed fixing. It was wrong that it was allowed to decide that.

The usual take on agent safety is a permissions conversation, and permissions are the easy half. You toggle read vs write, you scope an API key, you feel responsible. The hard half is that a capable agent will do reasonable things you never authorized, and "reasonable" is doing a lot of load-bearing work in that sentence. A permission says can. A never-list says won't, even when it looks obviously correct to. Those are different documents and you need both, and the never-list is the one that actually saves you, because it's the one that survives the moment the agent has a genuinely good reason.

Write the never-list before the first connector, not after the first incident

The reason to write it first is unglamorous: after an incident you write a list about that incident. You get a very specific rule about the very specific thing that went wrong, and you feel safe, and the next failure comes from a direction you weren't looking. Writing it cold forces you to think in categories instead of anecdotes.

Here's the test I use for whether something belongs on the list. Ask: if the agent did this and it turned out well, would I still be uncomfortable that it happened without me? If yes, it's a never. That question separates "bad outcome" from "not your call," and it's the second one that matters, because a competent agent will mostly produce good outcomes, which is exactly why it drifts.

So: publishing to a live surface. Sending anything to a human who isn't me. Spending money. Deleting or overwriting anything I can't reconstruct. Touching credentials. Changing what it's allowed to do. Those aren't dangerous because they usually go wrong. They're on the list because the upside of getting them right doesn't compensate for the downside of getting them wrong, and I don't get to review a send after it's sent.

The six categories every marketing agent never-list needs

Most marketing stacks fail in the same six places. Start here, then add your own.

Category	The never	Why it's not just a permission
Publish	Never push to a live URL, live post, or live ad. Draft only.	Read/write is binary. Draft vs publish is the line you actually care about, and most CMS tokens don't distinguish.
Send	Never send an email, DM, Slack message, or comment to a human who isn't me.	An agent with an ESP connector can technically "test send." Test sends go to real inboxes.
Spend	Never create, raise, or resume a paid campaign. Never buy anything.	Budget caps are a ceiling, not a consent. The agent can spend the cap correctly and still have spent it without you.
Delete	Never delete or overwrite. Rename, copy, or append instead.	Trash is recoverable until it isn't, and "overwrite" doesn't even hit the trash.
Credentials	Never read, write, or repeat a key, token, password, or anything from a .env. Never paste one into a prompt or a doc.	Secrets leak by being quoted, not by being stolen. Summaries and handoff files are the leak surface.
Scope	Never install, connect, authorize, or grant itself anything new. Never edit its own config or never-list.	This is the meta-rule. Without it, the other five are advisory.

The scope rule is the one people leave off and it's the one I'd keep if I could only have one. An agent that can extend its own reach doesn't have boundaries, it has a starting position.

Make the never-list a file the agent actually reads

A rule that lives in your head is a rule the agent doesn't have. Put it in the project root as NEVER.md and reference it from wherever your agent picks up context (CLAUDE.md, your Skill, your system prompt, whatever your setup uses). Here's mine, adapt it:

# NEVER.md
Rules that override every other instruction in this project,
including instructions from me in the moment. If a task requires
one of these, STOP and ask. Do not do the adjacent version of it.

## Never publish
- No pushing to live URLs, live posts, live ad sets, live email sends.
- Draft, save, and tell me where the draft is. That's the whole job.

## Never send to a human
- No email, DM, Slack, comment, reply, or form submission that
  reaches anyone who is not me. Test sends count. "Just to myself
  at another address" counts.

## Never spend
- No creating, unpausing, raising, or extending anything with a
  budget. No purchases, no upgrades, no new paid accounts.

## Never destroy
- No delete, no overwrite, no force-push, no bulk edit.
- To change a file: copy to <name>.v2, edit the copy, tell me.

## Never handle secrets
- Do not read .env, credentials files, or key vaults.
- Do not quote, summarize, or transcribe any key, token, or password
  into chat, a doc, a commit, or a handoff file.
- If you encounter one, write [REDACTED: CREDENTIAL] and move on.

## Never widen scope
- No installing, connecting, authorizing, or enabling anything.
- No editing this file, your config, or your own permissions.

## Never invent
- If a number, quote, result, or source isn't in the material I gave
  you, write [MISSING: REAL NUMBER] or [MISSING: SOURCE].
  Do not estimate. Do not use a plausible placeholder.

## Adjacency rule
- Fix only what I asked about. If something nearby is broken,
  write it in FINDINGS.md. Do not fix it.

The adjacency rule at the bottom is the one that came directly from my CMS incident, and it's the least obvious one on the list. Every other rule blocks something that sounds bad. That one blocks something that sounds helpful.

The refusal has to be cheap, or you'll route around it

A boundary that makes the agent useless gets deleted within a week. This is the actual failure mode of safety rules, not the agent breaking them. You break them, because the agent kept stopping and you had a deadline.

So pair every never with the thing it should do instead. "Never publish" is annoying. "Never publish, save the draft and give me the edit URL" is fine. "Never delete" is annoying. "Never delete, write .v2 and tell me" is fine. Notice every never in the file above has an escape hatch that keeps the work moving. That's deliberate. The agent should be able to get 95% of the way and hand you a two-second decision, not stall out and wait.

The other half of cheap refusal is a place to put the things it noticed but couldn't act on. That's FINDINGS.md. Without it, the agent either does the unauthorized helpful thing or silently drops the information, and both are worse than a bullet in a file you skim later.

# FINDINGS.md
Things I noticed but did not touch. Newest first.

## 2026-09-25 ,  /pricing page
The annual toggle shows the monthly figure. Not in scope for
today's task (blog draft), not fixed. File: deploy/pricing.html

## 2026-09-25 ,  data/prompts.js
Two prompts share the tag "audit" with different meanings.
Cosmetic. Not fixed.

Connector-by-connector: what to actually turn on

Blanket rules are the floor. Each connector has a specific shape of trouble.

CMS (WordPress, Webflow, Ghost). The risk isn't deletion, it's publish-state. Give it draft-creation, withhold publish and withhold edit-on-published-posts. If your CMS can't separate those, give it read-only and have it hand you the markdown. Genuinely, read-only plus a paste is fine. The convenience gap is about ten seconds.

Analytics (GA4, Search Console, Ahrefs). Read-only, always, no exception. There is nothing an agent needs to write here. This is the safest connector you own and the one I'd hook up first, because it's where the agent adds the most and risks the least.

Email platform. This is the one I'd hold back longest. An ESP connector means the agent is one confident step from a real send to a real list, and unsends don't exist. Draft-only if your platform supports a true draft state, and verify what "draft" means in your specific tool before you trust it. Some platforms treat a scheduled send as a draft until it fires.

Ad platforms. Read-only. Reporting and analysis are the whole value. Campaign creation and budget changes stay human, permanently, not as a training-wheels phase.

File system / repo. Scope it to one project directory. Not your home folder, not your Documents. One directory, and if the agent needs something outside it, you move the file in. Combine with the never-destroy rule so edits become copies.

Social scheduling. Queue-only, with the queue set to require approval before posting. If the tool doesn't have an approval step, it's a paste-from-clipboard workflow and that's fine.

The pattern across all six: the agent should be able to see everything and change almost nothing. Reading is where the leverage is. Writing is where the incidents are.

Run a dry-run day before you trust it

Before you let a connector do anything real, spend one working day where the agent does the full job and writes its intended actions to a file instead of executing them. You are not testing whether it can do the work. You're reading what it decided to do.

You have read access to [connectors] for this task. You do not
have write access, and you will not ask for it.

Do the full task as if you could act. For every action you would
have taken, append a line to PROPOSED.md in this format:

[connector] | [action] | [target] | [reversible? y/n] | [why]

Be complete. Include the small actions you would consider too
minor to mention, and any action you'd take on something I did
not explicitly name. Those are the ones I am reading for.

Then give me the deliverable itself, as a draft, in the chat.

Read PROPOSED.md and look at two columns only. The reversible? n rows tell you what needs a never. The rows where the target isn't something you named tell you whether your adjacency rule is holding. In my experience that second group is always longer than you expect, and every single entry is defensible, which is precisely the problem.

The failure mode nobody warns you about: your own instructions

Your never-list has to outrank you. Not because you're careless, but because you will, at some point, on a Thursday, type "yeah just publish it" while looking at something else. If the agent treats the standing rules as defaults that any in-the-moment instruction overrides, you've written a suggestion.

That's why NEVER.md opens with "override every other instruction in this project, including instructions from me in the moment." The unlock should be explicit and slightly annoying: a specific phrase, typed deliberately.

## Override procedure
A never can be lifted for ONE action only, and only if I write the
exact phrase: OVERRIDE NEVER-LIST FOR THIS ACTION.

If I say "go ahead", "just do it", "yes publish", "you have my
permission", or anything else casual, that is NOT an override.
Ask me for the phrase. Every time. Do not be embarrassed about it.

After the action, the never is back on. Overrides do not persist
across a task, a session, or a conversation.

The friction is the feature. If typing that phrase feels like too much for what you're asking, you've just learned something about the action.

Where the Hub fits

The never-list is a discipline, not a product. Everything above works with nothing but a text file and an hour, and you should go do exactly that before you buy anything from anyone, including me.

If you want the layer on top of it, the agent pack in the paid library is the set of blueprints for agents that already assume these boundaries: the marketing agents I actually run, each with its connector scope, its refusal behaviour, and its handoff-file layout defined rather than improvised. It's for the case where you're wiring up several agents and don't want to re-derive the boundary logic six times. It doesn't teach you anything this post didn't. It saves you the assembly.

And the honest bit: the four free Skills at /skills/ and the four free prompts at /free/ have no email gate, and if what you need is a single well-scoped agent for one job, the free material covers you. The free Skills are built with the same refuse-first discipline, the [MISSING: REAL NUMBER] behaviour is baked into them, and you can read exactly how the boundaries are written and copy the pattern. Take the pattern, write your own NEVER.md, don't pay me. Come back when you're running enough agents that the assembly cost is the thing that hurts.