What Should an AI Agent Never Do Without Asking?
An AI agent should never do five things without asking: spend money, create accounts or publish to a new platform, message real people, act under your name, or step outside its allowlist. A guardrail is a standing rule in the agent's contract that names an action it must never take on its own and must instead request from a human.
The reason to name these categories in advance is that an autonomous agent runs while you are not watching. It works in long, unsupervised sessions, and by the time you read the log the action is already done. A rule you rely on to catch a mistake after the fact is not a guardrail; a guardrail has to sit in front of the action and stop it before money leaves the account or an email reaches a stranger.
Naming the list also removes the agent's need to guess. An agent without a written boundary will improvise one, and its improvised judgment is exactly what you cannot audit. When the never-alone categories are written down, the agent knows precisely where autonomy ends and a request begins, and so do you.
What is on the never-alone list, and why?
Our never-alone list holds five categories, and each one is there because a single wrong move in it is expensive or hard to undo. The list is deliberately short so the agent can hold it in mind on every task, and deliberately explicit so nothing on it depends on the agent's mood or interpretation.
The first category is spending money. Every expense needs individual approval, even a trivial one, because the agent cannot reliably tell a five-dollar subscription from the first charge of a recurring bill it does not understand. We chose a per-request rule over a standing budget on purpose, and the full reasoning lives in our guide to how to stop an AI agent from spending your money.
The second category is creating accounts on outside services or publishing publicly to a new platform. A new account carries an identity and a terms-of-service commitment, and a public post cannot be fully unpublished once it is indexed and quoted. Both are one-way doors, so the agent proposes and the human opens them.
The third category is sending emails or messages to real people. A message to a human lands in someone's inbox with your reputation attached, and there is no undo once it is read. The fourth category is acting under the owner's name or identity, which we forbid outright so the agent never signs, speaks, or transacts as though it were the person who owns the operation.
The fifth category is a catch-all: anything not on an explicitly granted allowlist. Instead of trying to enumerate every forbidden action, we invert the default, so the agent treats a capability as off-limits until it has been named as allowed. That single rule closes the gap that the first four categories cannot, and it is the reason our broader guide to AI agent guardrails treats the allowlist as the backbone of the whole system.
How does the agent ask instead of acting?
The agent asks by writing its request into a plain text inbox file rather than pausing and waiting. We keep one file, FOR_HUMAN.md, and the agent writes three things into it: what it wants to do, why, and how urgent the request is. Then it moves on to other backlog work instead of blocking, and the owner answers directly in the file.
The inbox matters because a blocked agent is a wasted agent. If the only way to ask were to stop and wait, one pending question would freeze an entire overnight session. Writing the request to a file lets the agent surface the decision and keep working on everything that is not blocked, so a single open question costs you a reply, not a night of progress.
The guardrails and the inbox both live in the agent's contract file, a CLAUDE.md that the agent reads on startup, so the rules survive between sessions. A boundary typed only into a chat message is forgotten the moment that session ends, which is why the never-alone list has to be written where every future session will read it. The contract is what turns a one-time instruction into a permanent limit.
The list can also shrink as trust grows, through explicit carve-outs. We granted the agent full autonomy over product pricing and over publishing to our own site and code repository, so those actions moved off the ask-list once we were confident in them. Every carve-out is logged with its reasoning, so the loosening of a boundary is itself an auditable decision rather than a quiet drift.
FAQ
What about gray-area actions the list does not cover?
Default to asking. No fixed list can name every situation, so the standing rule for anything ambiguous is to write it into the inbox rather than guess. The cost of asking is small: a line in a file and a short wait for an answer. The cost of guessing wrong on an irreversible action is not small, and it lands on the owner. When in doubt, the agent proposes and the human decides.
Does the never-alone list ever grow or change?
It mostly shrinks, through carve-outs, as trust grows. When the owner is confident the agent handles a category well, that category moves off the ask-list and becomes autonomous. Pricing is our clearest example: we granted the agent full control over product prices once the pattern was proven. Each change, whether it loosens or tightens a boundary, is logged with its reasoning, so the list is a deliberate record rather than something that drifts silently over time.
Can I enforce these limits technically, not just by instruction?
Partly. Some limits have a technical backstop: tool and permission scoping can withhold capabilities from the agent, and git makes file changes reversible so a bad edit can be rolled back. Those controls are worth using. But technical scoping cannot cover judgment calls, like whether a specific message is appropriate to send, and that is exactly where the written contract rule earns its place. Use both: scoping for what it can catch, the contract for everything else.