takeawaysTL;DR
- An AI harness is everything around the model: instructions, tools, MCP servers, permissions, memory, hooks and the agent loop.
- Teams write security rules into harness files like CLAUDE.md and AGENTS.md. The model reads them as suggestions, not limits.
- A 2026 study found only 4.4% of those security rules had a matching enforced control. For personal data rules, it was about 1 in 20.
- Fixing it means backing every written rule with a deterministic control that sits outside the model.
"Harness" became one of the most used words in AI engineering this year, and for good reason. As teams moved from chatbots to agents, they realized the model was only part of the product. What the agent can see, which tools it can call, what it is allowed to touch and how it decides its next step all live in the layer around the model. That layer is the AI harness.
It is also where most companies put their AI security policy, usually as a list of "never do this" lines in a rules file. This post explains what an AI harness is, how each part works, and why research now shows those written rules are almost never enforced.
01What Is an AI Harness?
An AI harness is everything around a language model that turns it into a working agent: the instructions it follows, the tools and MCP servers it can call, its permissions, memory and context, hooks, and the loop that plans and executes each step. The model provides the reasoning. The harness decides what the agent can see and do.
A useful way to picture it: the model is the engine, the harness is the rest of the car. Two products can run the same model and behave completely differently, because their harnesses differ. Claude Code, Cursor, Codex and Copilot are all harnesses.
02The Parts of an Agent Harness
Most harnesses share the same six components. Click each one to see what it does and whether it is typically written guidance or an enforced control. That distinction is the whole story of this post.
Six parts around one model
Amber tags are guidance the model may follow. Green tags are controls the harness can enforce.
03Written Rules vs Enforced Rules
Here is the problem in one sentence: a rule written in a harness instructions file is a request to the model, not a limit on the agent.
When a developer writes "Never read .env files" in CLAUDE.md, the model will usually comply. But "usually" is not a security property. The model can misread the rule, lose it in a long session, or be talked out of it by a prompt injection hidden in a file it reads. An enforced rule is different: it lives in a permission setting, a hook or an external control, and it blocks the action no matter what the model decides.
| Dimension | Written rule | Enforced control |
|---|---|---|
| Where it lives | Instructions file read by the model | Permission config, hook, gateway or policy engine |
| Who decides | The model, every time | Deterministic code, outside the model |
| Survives prompt injection? | No. Text can override text | Yes. Injected text can't change config |
| Survives long sessions? | Can fade or be dropped from context | Applies to every call |
| Auditable | No record of whether it was followed | Every block and allow is logged |
| Feedback to the author | None. Looks the same enforced or not | Explicit, testable |
04The Research: Only 4.4% of Harness Security Rules Are Enforced
In August 2026, a study titled When "Do Not" Is Not deny examined 481 public repositories that use CLAUDE.md files. It pulled out 870 security related rule segments and checked each one against Claude Code's built in controls, like permission deny rules, to see whether anything actually backed it up.
Even with the loosest matching standard, coverage only reached 14.3%. The author describes CLAUDE.md as a "write only security channel": developers write rules and never find out whether they're enforced.
The gap was worst exactly where the stakes are highest. Rules about destructive commands were the most likely to be backed by a control. Rules about personal data and approvals were the least.
Roughly 19 out of 20 rules about personal data had nothing enforcing them. Those are the rules a compliance team cares about most: don't send customer data out, don't log PII, don't paste records into prompts. In most harnesses, they are a sentence the model is politely asked to respect.
05Test a Harness Rules File
Here is a rules file that looks like hundreds of real ones. Run the check to see which lines a default harness setup actually enforces.
- Do not run rails credentialsnot checked
- Never run rm -rf outside the projectnot checked
- Never commit secrets or tokensnot checked
- Don't send customer data to external APIsnot checked
- Never paste PII into prompts or logsnot checked
- Ask for approval before deploying to prodnot checked
The first and third rules are examples cited in the research. The rest are illustrative of common rules; actual enforcement depends on how each harness is configured.
06Why Written Harness Rules Don't Hold
Written and enforced rules look identical
Nothing in the file tells you whether a line is backed by a control. Teams assume coverage because they wrote the rule down.
Prompt injection can talk the agent out of it
A malicious instruction in a README, issue or email competes directly with your rules file.
Permissions are broader than they look
A grant like Bash(python:*) reads as "allow Python" but effectively permits any command an interpreter can run.
The harness pulls in code nobody reviews
MCP servers and skills install with no lockfile and no validation. A skill can pre approve shell access for every repo that installs it.
That last gap is measured too. A September 2026 study by Red Hat researchers scanned 2,660 coding agent harness setups across Claude Code, Cursor, Copilot, Gemini CLI and others, and found 16.0% carried confirmed security defects.
And at the enterprise level, the gap between belief and reality is the same shape. Research from Cequence and EMA found 94% of enterprises trust that their AI agents aren't over provisioned, but only 33% actually enforce it.
Your AI policy is already written. The question is whether anything enforces it.
Polygraf AI07How to Enforce AI Harness Security Rules
The fix is not to stop writing rules. Written rules still shape good behavior. The fix is to make sure every rule that matters has a control behind it that the model can't argue with.
Audit your rules files
List every security line in CLAUDE.md, AGENTS.md and system prompts. Mark each one: enforced, partly enforced or written only.
Use the harness's own controls
Turn written rules into permission deny rules and pre tool hooks wherever the harness supports them.
Tighten grants
Replace wildcard permissions with specific commands. Avoid interpreter grants that quietly allow everything.
Pin and vet MCP servers and skills
Lock versions, review what each one can do, and block unapproved servers from being installed.
Enforce data rules outside the harness
Personal data and egress rules span every tool and every harness. They need a control at the boundary where data actually moves.
Make enforcement visible
Log every block and allow so security teams can prove a policy holds, not just that it was written.
Your AI policy is written. Polygraf enforces it.
Harness controls only cover what one tool's config can express, and only in that tool. Polygraf enforces policy at the AI boundary itself, inspecting prompts, retrieved content, tool calls and responses in real time across every agent and harness your teams use. The data rules that research shows are almost never backed by a control, like "don't send customer data out," become rules that actually block.
It runs inside your environment, so enforcement never depends on sending your data to someone else's cloud.
08AI Harness FAQ
What is an AI harness?
An AI harness, or agent harness, is everything around a language model that turns it into a working agent: the instructions it follows, the tools and MCP servers it can call, its permissions, memory and context, hooks, and the loop that plans and executes steps. The model provides reasoning; the harness decides what the agent can see and do.
What is the difference between an AI model and an AI harness?
The model is the engine that generates text and reasoning. The harness is the vehicle around it: the system prompt, rules files, tools, permissions, memory and orchestration logic. Two products can use the same model and behave very differently because their harnesses differ.
What is harness engineering?
Harness engineering is the practice of designing and tuning the environment an AI agent runs in, including instructions files such as CLAUDE.md or AGENTS.md, tool and MCP configuration, permissions, hooks, memory and evaluation, so the agent behaves reliably and safely.
Why are most AI harness security rules not enforced?
Most security rules are written as natural language instructions in files like CLAUDE.md, which the model treats as guidance rather than hard limits. A 2026 study of 481 repositories found only 4.4% of security rules had a matching built in control under strict matching. Developers get no feedback on whether a rule is actually enforced.
How do you enforce AI harness security rules?
Back every written rule with a deterministic control: permission deny rules and hooks inside the harness, pinned and vetted MCP servers, scoped credentials, and an inline enforcement layer that inspects prompts, tool calls and data flows and blocks violations before they execute.
Turn Written AI Policy Into Enforced Policy
Inline enforcement across prompts, tool calls and data flows, for every agent and harness. On premise, CPU only, sub 100ms, zero data egress.