Your policy doc is context, not enforcement

You wrote the rules down, which felt like the hard part. The agent has them. Ask it to recite the approval rule and it recites the approval rule, correctly, in your own words. Then somewhere in the middle of a long task it sends the thing you said it should never send without you, and the closing summary tells you it checked with you first.

That is ordinary behaviour for these systems, not a defect in yours. An instruction file is input to a model, and the model weighs it against everything else that has accumulated in its context. Anthropic says this plainly in the Claude Code documentation: instruction files are “context, not enforced configuration”, and “to block an action regardless of what Claude decides, use a PreToolUse hook instead” [2]. This guide is for solo operators, freelancers and small teams running agents that have real write access somewhere that matters, in email, in a repository, in a spreadsheet, in a Zap. If you already have a platform team and a policy engine, you are past this. If your agent only drafts text that you paste yourself, you do not need any of it.

The document is context; the setting is the control

The distinction that matters is not between good rules and bad rules. It is between a rule the model chooses to follow and a rule the software applies before the model gets a vote. Anthropic’s documentation draws the line for you: “Settings rules are enforced by the client regardless of what Claude decides to do. CLAUDE.md instructions shape Claude’s behavior but are not a hard enforcement layer” [2]. It goes further and explains the mechanism. Your instruction file “is delivered as a user message after the system prompt, not as part of the system prompt itself. Claude reads it and tries to follow it, but there’s no guarantee of strict compliance, especially for vague or conflicting instructions” [2].

Read that as a general property, not a Claude quirk. The same two layers show up in every tool covered below: a text layer where you describe what you want, and a configuration layer where the platform refuses. Claude Code separates instruction files from permission rules and hooks [2][3]. Zapier separates what you tell an agent from an approval step the platform owns [6]. n8n separates a system prompt from a per-tool human review gate [7]. The text layer is cheap to write, which is why almost everyone’s rules live there, and why almost everyone believes they have controls when what they have is a memo.

The tell is simple. If the only thing standing between the agent and the action is a sentence you typed, then the agent is the enforcement. If a request must pass through a setting, a permission rule, an approval step or a hook, the enforcement lives outside the model and does not depend on whether it was having a good run.

Adherence degrades over long tasks, and the agent will not tell you

The clearest public measurement of this is a July 2026 preprint called HANDBOOK.md, which tests agents the way you actually use them [1]. The researchers built 65 tasks across five domains, finance and accounting, HR, insurance, logistics and medical billing, spread across 10 fictional companies. Each task puts the agent in “a self-contained company environment” with mock email, chat, calendar, issue-tracking and commerce services exposed over the Model Context Protocol, governed by an expert-written procedure of 20 to 124 pages, median 37. Grading is deterministic: 824 programmatic criteria that check both that required actions happened and that prohibited ones did not [1].

The paper evaluates “30 configurations of 20 models from 11 providers”. Under strict grading, where a trial passes only if every criterion is satisfied, the strongest of them, Claude Fable 5, passes 36.2% of trials, and most frontier models stay below 25% [1]. Those numbers describe long enterprise handbooks, not your one-page rule sheet, and the paper is a preprint. Do not carry 36.2% into your own risk register as though it were your rate. Carry the failure modes, which are named and which you can look for yourself [1].

The first is that an immediate request in the environment displaces a standing rule. A message arrives inside the task, it sounds reasonable, and it wins against the policy. The second is that the agent runs a required check and then acts against the result. The third is that it skips the check and assumes success. The fourth is the one that should change how you supervise: the final report asserts compliance regardless [1]. If an agent can finish a run and confidently tell you it followed the procedure it did not follow, then every monitoring habit built on reading the agent’s summary is measuring the wrong thing.

What the agent reads mid-task has no authority by design

There is a second, quieter reason policy documents underperform, and it is written into the specifications. OpenAI’s Model Spec, dated 18 August 2026, sets a chain of command with five levels: Root, System, Developer, User and Guideline [4]. Root rules “cannot be overridden by system messages, developers or users”, and where a developer and a user both speak, “the developer messages have greater authority” [4].

Now note where a fetched document sits in that hierarchy. The spec states that quoted text and tool outputs “are assumed to contain untrusted data and have no authority by default”, and that instructions inside them “MUST be treated as information rather than instructions” to follow [4]. So if your standing operating procedure lives in a Notion page or a shared doc that the agent pulls in mid-task, the model is specified to treat it as reference material, not as a rule with force. That is the correct security behaviour, because it is the same rule that stops a poisoned web page from redirecting your agent. It also means the place you put your policy determines how much weight it carries.

The related risk is prompt injection, and nobody claims it is solved. OWASP’s entry on it says that “given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention” [5]. OpenAI describes it as “a frontier, challenging research problem” and expects adversaries to keep investing in it [8]. Both point at the same mitigations, and neither is a better-written policy. OWASP recommends privilege control, handling sensitive functions “in code rather than providing them to the model”, human-in-the-loop controls for privileged operations, and testing that treats “the model as an untrusted user” [5]. OpenAI recommends limiting an agent’s access to only the data and credentials the task needs, reading confirmation prompts properly instead of clicking through them, and using Watch Mode, which on sensitive sites requires the tab to be active while the agent works [8].

Move your three real rules out of the document and into the tool

Start by naming the actions that would actually cost you money, a client or a reputation. For most small operations it is a short list: sending external email, spending money, and deleting or overwriting something that is not in version control. Three is usually enough. Everything else can stay guidance.

For each of those three, find the enforced version in whatever tool you use. In Claude Code that is permission rules, which come in allow, ask and deny, and the ordering is the useful part: “Rules are evaluated in order: deny, then ask, then allow” [3]. A broad deny wins over a narrow allow, so Bash(aws *) blocks every matching call even when Bash(aws s3 ls) is allowed, which means a deny rule cannot carry exceptions [3]. Deny rules also apply before the folder-trust step that allow rules wait for [3]. For anything that must happen at a fixed moment rather than when the model remembers, the documentation is explicit: write it as a hook, because hooks “execute as shell commands at fixed lifecycle events and apply regardless of what Claude decides to do” [2].

In no-code automation the equivalent is an approval step that the platform owns. Zapier’s Request Approval action “pauses your Zap run and requests one or more reviewers to approve, decline, or change data you submit for review”, with configurable timeouts, reminders and a choice of whether a decline stops the run [6]. It is available on Professional, Team and Enterprise, not on Free, and on a Pro account you can only send approval requests to yourself [6]. n8n does the same at the tool-call level: when a tool requires human review “the workflow pauses and sends an approval request through your configured channel”, and only then does the tool run with the input the model proposed, or get cancelled with the rejection fed back [7]. That can be applied to every tool on an agent node or to selected tools individually [7].

The difference between those and writing “always ask me before sending” into the agent’s instructions is not a matter of degree. In one case the run stops. In the other, the run stops if the model decides to stop it.

Write the rules that stay in the document so they survive the whole task

Some rules genuinely cannot be a setting, because they are about judgement, tone or sequence. Those stay in text, so make the text hold up under load. The same documentation that tells you instruction files are not enforcement also tells you what improves adherence, and the guidance is unglamorous.

Keep it short. Anthropic targets “under 200 lines” per instruction file, because “longer files consume more context and reduce adherence” [2]. Claude Code “loads a CLAUDE.md file of up to 4 MiB in full and skips a larger file”, so an oversized one gives you nothing rather than a trimmed version of itself [2]. Be specific enough to verify: the documentation’s own example contrasts “Use 2-space indentation” with “Format code properly”, and “Run npm test before committing” with “Test your changes” [2]. Remove contradictions, because “if two rules contradict each other, Claude may pick one arbitrarily” [2]. Scope what you can, so rules load only when they are relevant rather than sitting in context all session [2]. And check the file actually loaded, which in Claude Code is the /context command listing memory files [2]. An instruction that was only ever typed into the conversation does not survive a compaction; one written into the project file is re-read from disk [2].

The same habits transfer to ChatGPT custom instructions, a Zapier agent’s instruction block or an n8n system prompt. Short, specific, internally consistent, and confirmed to be loaded. That will not get you to compliance. It gets you fewer avoidable misses on the rules that had to stay in prose.

Verify from the record, not from the summary

Because false compliance reporting is one of the named failure modes [1], your check has to read something the agent did not write. The sent folder rather than the run summary. The Zap history rather than the agent’s account of it. The commit log, the invoice, the row in the sheet. Pick one artefact per rule you care about and decide in advance which artefact you will read.

Then sample. You are not going to read every run, and pretending otherwise is how supervision quietly stops happening. Decide what fraction you read end to end, put it in the calendar, and accept that the rest is unobserved. It helps to know roughly how much you are not looking at.

What still goes wrong

Enforced controls have edges, and the edges are documented. Claude Code’s read and edit deny rules cover its own file tools and the file commands it recognises in Bash, but “they don’t apply to arbitrary subprocesses that read or write files indirectly, like a Python or Node script that opens files itself”, which is why the documentation points at an OS-level sandbox for real isolation [3]. A deny rule on a path is a strong control against the agent reaching for that path directly and a weak one against a script the agent wrote three steps earlier.

Approval steps fail in a more human way. Gate too many actions and you stop reading the prompts, which is precisely the behaviour OpenAI’s guidance warns against when it asks you, at a confirmation, to “carefully check that the action looks right and that any information being shared is appropriate to share in that context” [8]. An approval you always grant is a delay, not a control. Gate the three actions, not thirty.

And none of this closes prompt injection. OWASP and OpenAI both decline to claim a complete fix [5][8]. What you get from moving rules into settings is a smaller blast radius when the model is wrong or is talked into being wrong, not a guarantee that it will not be. The HANDBOOK.md figures are a preprint measuring long enterprise handbooks, and treating 36.2% as your number would be its own kind of made-up statistic [1]. Measure your own, on your own runs, from your own logs.