A policy your agents can ignore is not a control. It is a culture document, and culture documents do not pass audits.
Someone ran a clean experiment this week and published the numbers, and they are the most useful governance datapoint I have read all month. They took one writing task and ran it two ways: once with a compact 742-word brief, and once with the full 5,197-word method — about 4,500 more words of instruction. Then they blind-scored the output. The long version wrote measurably better prose: 19.67 out of 20 against 17.5. It also failed the actual delivery contract two runs out of three. The compact brief, the one with far less instruction, passed that same contract three times out of three.
The obvious reading is that the model got fussy, or that this is a prompt-engineering problem someone will tune away. Both are wrong. The hard requirement — return valid JSON under 1,400 words — was written down as a polite reminder, buried in a long instruction file. A model does not experience a reminder as a boundary. It experiences it as tokens to predict against, and it is allowed to ignore it. That is the whole post in one sentence: a rule your agents can read is not a rule your agents will honor, and a rule they can ignore is exactly the kind that fails an audit.
I run information security and DevOps for a fintech that answers to more than 1,500 financial institutions and, through them, to their examiners. So I read that result the way I read every AI story now — as a control review. My team built our own agent platform, AgentOS, and the single most useful thing I have learned building it is this: a hard requirement left as prose is the same failure class as a wire-transfer limit left as a code comment. It might describe the right behavior perfectly. It stops nothing.
The proof landed on July 15: more instruction, better prose, a broken contract
Sit with the direction of that result, because it is counterintuitive and it matters. More instruction bought better prose and cost the contract. The extra words were not wasted on quality — they clearly helped. They just did nothing to enforce the one requirement that was non-negotiable, because enforcement is not a thing prose does. You can write a boundary in beautiful, specific English and the model will still walk through it, because to the model there was never a wall there, only more text.
This is not a fluke of one experiment. Anthropic's own published guidance for its instruction files tells you to keep them specific, concise, and well-structured, precisely because long files reduce adherence — constitution bloat. More instruction is negative-yield past a point. That is exactly backwards from how most teams treat their AI policy, where the response to every near-miss is to add another paragraph and feel safer for having done it.
Here is why that should bother anyone who has ever survived an audit. In banking, a wire-transfer limit is not a sentence in the operations manual. It is a hard stop in the system that refuses the transaction at the dollar figure, logs the refusal, and routes the exception to a named human. Nobody would accept "we told the team to be careful over fifty thousand dollars" as a control. Yet that is precisely the maturity level of every AI rule that lives only in a markdown file. Boundaries belong in validators, not paragraphs.
Your AI policy is prose, and prose is context, not control
Most teams now run on three documents they rarely think of as one problem. There is the CLAUDE.md or AGENTS.md that steers the coding agents. There is the AI acceptable-use PDF that legal and security wrote for the humans. And there is whatever governance standard the board signed off on. All three are prose. Prose shapes behavior, sometimes very well, but it never stops an action at a defined point. If something must happen, or must not happen, at a specific moment in a specific run, it needs a deterministic hook behind it, not a promise in a text file.
This stopped being an internal-quality problem in June, when BCG's research made the point that agents acting on your behalf now express your company's culture — they are, functionally, your policies in motion. That reframes an unenforced standard from a private documentation gap into something board-visible. The distance between what your policy says and what your agents actually do is no longer an embarrassment you can manage quietly. It is a thing an examiner can point at.
And an examiner does not accept "we have a policy." Treasury's Financial Services AI RMF, published in February, is 230 control objectives across seven domains — a control catalog, not a position paper. A control, in that world, is always the same shape: a trigger, a binary check, and a consequence. Never a paragraph. Your SOC 2 and HIPAA access controls all assume an enforced boundary that the prose describing them does not create.
To be clear about what this is and is not: it is not about runtime agent controls — the judge at the action boundary, the kill switch, the autonomy ladder — I have written about those elsewhere. And it is not about which regulation applies to you. It is the plainer question underneath both: how does any written rule actually come to bind?
The enforcement ladder: five rungs, and only the top two bind
There is a framing circulating in the AI-at-work discourse that I have adopted, because it maps cleanly onto how a security team already thinks. Picture every rule you write as sitting on one of five rungs, lightest first. The order is load-bearing, so it has to be a list:
- Value. A principle you hope shapes judgment — "we prioritize customer trust." Ambient, unenforceable, fine as culture.
- Instruction. A direct request the agent usually follows — "cite the source row for every claim." Better. Still advisory.
- Reminder. The same instruction, repeated because it keeps getting missed. If you are on this rung, the rule is already failing and you are treating volume as enforcement.
- Hard block. A deterministic check that refuses the action — a validator, a CI gate, an admission controller — and emits a binary pass or fail. The first rung that actually enforces anything.
- Human-owned decision. The action stops and a named person decides, on the record. The act-or-interpret boundary, made explicit.
There is no rung six. Now run the diagnostic: take every rule in your AI standards and name its current rung. Rules that merely inform can live at instruction or reminder without much harm. But any rule that must not be violated — and "return valid JSON under 1,400 words" becomes one of those the moment a downstream system parses that JSON — belongs at hard block or human-owned decision. If it is sitting at reminder, it is a suggestion with a serious tone.
The rule I keep returning to is this: automate the check before you automate the consequence. Run the binary validator first, then let the machine act on the result. That is just the compensating-control pattern every security team already trusts, pointed at agents. A rule stuck at reminder while the consequence downstream is fully automated is not a control. It is hope wearing a policy's clothes, and it fails open — quietly, on the run nobody was watching.
Every rule needs binary evidence, a named owner, and a defined appeal
Naming the rung is half the work. The other half is giving each rule that must bind the five fields an auditor will ask for anyway. Write it once in this shape and you have written it audit-ready:
- Trigger. The exact condition that fires the rule — this action, this data class, this threshold.
- Evidence. A binary pass/fail artifact the check produces, not a vibe.
- Action. What happens on pass, and — the part people skip — what happens on fail.
- Owner. Two names, primary and backup, accountable for the rule. Not a team alias.
- Appeal. Who can override, on what evidence, and where the override is logged.
Three of those fields are where controls actually die. Evidence has to be binary, not inferential. "The agent should be careful with production data" is inferential — nobody can hand it to you as an artifact — and inferential evidence is exactly what collapses in the one meeting where the examiner asks a question your logs cannot answer. "The write validated against the schema," "the row counts reconciled," "the egress destination was on the allowlist" — those are pass/fail. Those are the log the examiner asks for.
Owner has to be two real names, because an orphaned rule is the governance twin of an orphaned service account: nobody can attest to it, and nobody notices when it rots. Every build agent and automation you run needs a named owner and a review path, or you accumulate ungoverned credentials and abandoned jobs no one can vouch for and no one dares turn off.
And a blank appeal field is not a stricter control. It is a future incident you have already written down. A hard block with no designed exception path does not hold under real pressure; it gets bypassed out of band, off the record, by someone with a deadline and no other option. A designed appeal — who can override, on what evidence, logged where — is the difference between a segregation-of-duties control and a speed bump.
One rule, one canonical home
There is a second failure mode, and a widely shared harness audit this week put numbers on it. One team's setup carried 66 reusable skills across 172 instruction-related files, and a common route loaded 18,384 words of instruction before the agent ever reached the actual task guide. Fifteen of those 66 skills carried their own copy of the same source-governance rule — fifteen places to drift out of sync. Six of the 66 had any detectable test or evaluation asset at all.
For a control owner, the same rule living in fifteen places is not thoroughness. It is fifteen versions of the truth, which is precisely what you cannot attest to. Writing to two sources that disagree is not an inconvenience in a regulated shop; it is a data-integrity finding. Every governance rule needs one canonical home and one named owner, and every AI-surfaced answer needs a source_reference back to the approved decision it came from — or you cannot trace it when someone asks you to.
The sharpest part is quieter than drift. OpenAI documents a skill-list budget for Codex of two percent of context, or 8,000 characters. The audited skill descriptions totaled 27,197 characters — so the harness silently truncated them mid-run and merely warned that it had. OpenAI's own GDPval research found that prompts compressed to roughly 42 percent of their length lost information in the squeeze. Read that plainly: a control your harness drops because the context budget overflowed is not a control. It is non-determinism in your control set, and you cannot attest to a rule you cannot guarantee was even loaded on the run in question.
So bloat is not just drag on quality, the way Anthropic frames it. In a regulated system it is a governance defect. Dedupe every rule to one owner, and keep the instruction surface small enough that nothing load-bearing gets quietly cut.
The board view: which rules are context, and which ones actually bind
All of this rolls up into one artifact a board can use. Take your AI standards and, for each rule, show its rung: which are still instructions — context, not control — and which are hard blocks with binary evidence behind them. Mark any rule that has failed open, where the human decision never actually happens or the appeal path does not exist, as a control needing repair. That single table is an honest maturity narrative, and it beats a fabricated maturity score because every cell in it is verifiable.
The urgency here is not vendor fear. EU GPAI enforcement switches on August 2 this year, with fines up to three percent of global turnover. Texas's TRAIGA safe harbor has been live since January 1, and it rewards documented, demonstrable governance over good intentions. Treasury's 230 control objectives are already how examiners think. Every one of those regimes asks the same three questions the rule machinery encodes — who owns it, what is the evidence, what is the appeal.
There is a piece of writing lore worth closing on, and worth correcting. The famous Amazon narrative — one six-page document reportedly redrafted 57 times — usually gets told as a parable about the discipline of good writing. That is not the lesson anymore. These documents are now read by agents that cannot push back, cannot ask a clarifying question, cannot infer the intent behind an awkward sentence. So precision matters more than ever — and precision in prose is still prose. The 58th draft of a reminder is still a reminder. The fix was never a better-written rule. It was converting the rules that must bind into checks that run.
Automate the check before you automate the consequence
So here is Monday, in four moves. Inventory your three standards — the CLAUDE.md, the AGENTS.md, the acceptable-use PDF — and name the enforcement rung of every rule in them. Anything that must bind, move from reminder to hard block: a validator, a CI gate, an admission controller that emits a binary pass or fail. Give each surviving rule the five fields — trigger, binary evidence, action, two owner names, a defined appeal — and treat a blank appeal as an incident you have pre-written. Then dedupe to one canonical home per rule and confirm your harness actually loads it, because a truncated control is no control at all.
The through-line is the one I opened with. A written standard your agents can read and still ignore is what fails an audit. Give every rule that matters binary evidence, a named owner, and an appeal path — or admit you have a culture document that enforces nothing. A wire-transfer limit belongs in the validator, not the code comment. Your AI policy is no different.
Which of your AI rules is still just a reminder that everyone treats as a hard block — and what happened the first time it wasn't? Tell me in the comments.
