CLAUDE.md security rules often outpace agent controls

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Cakewalk's research: Most CLAUDE.md security rules for coding agents cannot be fully enforced by built-in controls, creating a write-only governance channel.

Why it matters: This matters because IAM and security teams cannot treat agent instructions as effective policy unless the control plane can represent the full rule, including conditions, content checks, and approval requirements.

By the numbers:

• Only 4.4% of the rules had a control covering the whole rule, with a 95% confidence interval of 2.6 to 6.7.

Context

CLAUDE.md is a developer-authored instruction file that coding agents read before acting, but the article shows that many security rules written there cannot be expressed as native allow and deny controls. That creates a gap between policy intent and enforcement, especially when the rule depends on a condition, content inspection, or human approval.

For identity practitioners, the important issue is not whether the agent can parse instructions, but whether the control model can actually enforce them. In this case the subject is autonomous-adjacent coding workflow governance, where the risk sits in the mismatch between written constraints and executable permissions.

The article’s core finding is that a security rule can look present while still being unenforceable in practice. That makes CLAUDE.md a governance signal, not a guarantee, unless teams pair it with controls that operate at execution time.

Key questions

Q: What breaks when CLAUDE.md rules do not map to agent controls?

A: The rule becomes advisory instead of enforceable. Developers may believe the agent is constrained, but the platform cannot actually stop the action, verify the condition, or require approval. That creates a governance gap where policy intent exists without a technical boundary, which is especially dangerous for secret handling and release operations.

Q: Why do context-based agent rules fail more often than simple allow or deny rules?

A: Because context-based rules depend on state the control plane does not naturally encode, such as release status, what a commit contains, or whether a human has approved the action. If the system can only inspect commands or paths, it cannot enforce the condition that makes the action wrong, so the rule remains incomplete.

Q: How should security teams tell whether an approval rule is really enforced?

A: They should trace the rule to a concrete approval gate in the runtime and confirm the agent cannot proceed without it. If the approval exists only in documentation, or if the agent can continue after a partial check, the organisation does not have human-in-the-loop control in any meaningful sense.

Q: What is the difference between policy intent and control enforcement in agent governance?

A: Policy intent is the instruction a person writes, while control enforcement is the mechanism that stops or permits the agent at runtime. In agent governance, the distinction matters because written rules can look complete even when the control model cannot express the relevant condition, content check, or approval requirement.

Technical breakdown

Why built-in agent controls miss CLAUDE.md rules

Built-in agent controls usually operate as narrow allow or deny checks over commands, paths, or tool actions. That works when a rule maps cleanly to a single operation, but it fails when the rule depends on context such as release state, repository content, or whether a human has approved the action. The paper’s key point is that a control only matches the whole rule when it can represent the action, target, condition, and approval requirement together. Without that full expression, the rule is advisory text rather than enforceable policy.

Practical implication: Treat any agent rule that depends on context or review as unenforced until you can point to the exact control that implements it.

Why content-based rules create a write-only governance channel

Rules like never commit secrets depend on the substance of what is being changed, not just where the change occurs. Current agent permission models are weak at evaluating commit content, meaning they can stop some actions by location but not by semantic meaning. That is why the article describes CLAUDE.md as a write-only channel: people can record intent, but they do not get reliable feedback that the agent can actually enforce it. This is a policy-to-control translation problem, not a documentation problem.

Practical implication: Classify content-based directives as high-risk unless they are backed by detection, pre-commit checks, or another executable control.

Why approval language does not equal human-in-the-loop control

A rule that says ask before does not by itself establish human-in-the-loop governance. The control plane has to encode who approves, under what conditions, and whether the agent can proceed without that approval. The article highlights that existing controls often lack a field for the human decision-maker, so the agent can satisfy a superficial approval rule while still bypassing meaningful oversight. That leaves organisations with governance language that sounds restrictive but does not enforce review at execution time.

Practical implication: Map every approval rule to a specific approval gate and verify that the gate cannot be skipped by the agent runtime.

Threat narrative

Attacker objective: The practical objective is to induce unsafe agent action under the appearance of governed behaviour, so policy intent exists without effective enforcement.

1. Entry occurs when a coding agent reads security instructions from CLAUDE.md and begins acting on them as if they were enforceable policy.
2. Escalation appears when the agent encounters rules that depend on context, content, or approval and can only apply partial controls such as command or path checks.
3. Impact follows when teams assume the written rule is covered, leaving secrets handling, deletion safeguards, and release gating exposed to agent behaviour that was never truly constrained.

Breaches seen in the wild

• Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.
• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CLAUDE.md has become a governance signalling layer, not a control layer: the article shows that developers can write security intent into agent instructions without gaining assurance that the agent can enforce it. That changes the governance question from whether policy exists to whether the control plane can represent the full rule. Practitioners should treat instruction files as evidence of intent, not evidence of control.

The core failure is control incompleteness, not prompt quality: the paper’s 4.4% figure matters because it exposes a semantic gap between policy language and executable permissions. Conditions, content checks, and approval logic are not edge cases, they are the very elements that make many security rules meaningful. The implication is that governance for coding agents has to be evaluated at the control-model level, not at the documentation level.

Human approval language is structurally weaker in agent workflows than in human workflows: a written ask before rule can imply oversight to a person, while the agent runtime may not encode a verifiable reviewer or decision point. That is a classic control-assurance problem across human IAM and non-human execution. Teams need to understand that review intent without an enforceable gate does not produce meaningful human-in-the-loop governance.

Condition-aware policy is the named concept this article exposes: the security problem is not just that rules are missing, but that many rules cannot be expressed in the same permission model that is supposed to enforce them. Once a rule depends on release state, commit content, or contextual approval, a simple allow or deny system is no longer sufficient. Practitioners should redesign governance around controls that can evaluate state, not just commands.

Agent governance now depends on enforcement provenance: organisations need to know which controls actually produce the outcome and which only record the intent. That aligns with broader identity governance discipline, where effective control requires verifiable enforcement rather than policy statements alone. The practical conclusion is that codifying rules is not enough unless the runtime can prove it will respect them.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: Secrets Management Buyer's Guide

What this signals

Condition-aware policy is the governance gap: coding-agent programmes fail when teams assume an instruction file can replace executable control. The real question is whether the runtime can evaluate the condition that makes a rule matter, not whether a developer wrote the rule down.

Write-only governance will spread wherever approval logic stays outside the control plane: once the human reviewer exists only in prose, the agent can continue to behave as if oversight were present. That means security teams need to verify decision points in the runtime, not just in repository documentation.

Agent-era secrets handling is already showing the cost of weak enforcement: Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, according to the State of Secrets Sprawl 2026. That kind of behaviour makes control completeness a programme-level issue, not a niche coding concern.

For practitioners

• Map every CLAUDE.md security rule to an executable control Classify each rule by whether it can be enforced through allow or deny settings, content inspection, approval gates, or other runtime controls. If the rule depends on context, state, or human review, mark it as unsupported until a real enforcement path exists.
• Separate content-based rules from command-based rules Create a distinct handling path for directives that depend on commit contents, release state, or semantic meaning. Those rules need detection, validation, or workflow controls, not just path or command restrictions.
• Verify approval rules at the runtime gate Check that ask before style instructions actually force a human decision point before the agent can proceed. The agent must not be able to satisfy the rule through text alone.
• Audit for write-only governance gaps Review instruction files for rules that appear present but have no corresponding control semantics. Prioritise secrets handling, destructive actions, and release-related commands because those are the highest consequence gaps.

Key takeaways

• CLAUDE.md can capture security intent without guaranteeing that a coding agent can enforce it, so policy text alone is not a control.
• The article’s central finding is a control-model mismatch: most rules need conditions, content checks, or approval logic that built-in permissions cannot express.
• Practitioners should validate agent governance by runtime enforcement, not by the presence of written instructions in repository files.

Key terms

• Write-Only Governance Channel: A governance pattern where people can record rules, but the enforcement system cannot reliably apply them in runtime. In agent workflows this means the instruction exists, yet the control plane cannot verify the condition, content, or approval logic needed to make the rule real.
• Control-Model Mismatch: The gap between a written policy and the permission model available to enforce it. In practice, the rule may sound complete to a human while the runtime can only evaluate a smaller subset of the required conditions, leaving important behaviour outside enforcement.
• Human-in-the-Loop Controls: Human-in-the-loop controls are decision gates that require a person to approve, review, or override an automated action before it proceeds. They are used when speed matters but the impact is high, such as account blocking, endpoint isolation, or access revocation, to keep automation accountable and bounded.
• Context-Aware Policy: Context-aware policy is a control model that decides access based on current conditions, not just preassigned entitlement. For AI agents and other non-human identities, this means privileges, tool use, and monitoring expectations can change as the task, environment, or risk signal changes.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.