Execution-layer security is the real boundary for AI agents

At a glance

What this is: This piece argues that AI agent rule files are context, not control, and that only runtime enforcement can reliably constrain tool use, filesystem access, and network actions.

Why it matters: It matters because identity and access teams need to govern agent behaviour at the execution layer, not assume prompt instructions will hold across long contexts, tool chains, and autonomous actions.

Context

AI agent guidance files such as CLAUDE.md, AGENTS.md, GEMINI.md, and Cursor rules create conventions, but they do not create guarantees. The security gap is simple: a model can be instructed, but it is not an enforcing control plane, so the same text that looks like policy often behaves like ordinary prompt context.

The governance problem is that teams often confuse instruction with restriction. In agentic systems, the effective control point is the runtime where tools, files, shells, and network access are actually permitted or denied. That is the boundary practitioners need to design and audit.

This is why execution-layer security matters more as agents gain broader tool access and longer contexts. A rule buried in a prompt is still only a rule in language, not a constraint in the system.

Key questions

Q: What breaks when AI agent harness controls are not governed like production security controls?

A: The agent can still stay within its technical permissions and yet behave unsafely because prompts, tool routing, retrieval, and escalation logic are unconstrained. That creates a control gap where intent is translated into action without a reliable enforcement layer. The practical failure is not just misuse, but ambiguous boundaries that make unsafe execution possible without obvious policy violation.

Q: Why do prompt instructions lose reliability in long-context agent systems?

A: Because relevant instructions can lose salience as the session fills with code, logs, prior messages, and tool output. The model is not violating a hard control, it is operating under probabilistic attention. As context grows, the chance that a critical instruction is overlooked or deprioritised increases.

Q: How should teams enforce AI agent access to files, shells, and networks?

A: They should enforce it at runtime with deny, allow, or ask-first decisions on each tool call. That means the filesystem, process layer, and network layer make the final decision, not the prompt file. This is the difference between guidance and control.

Q: Should organisations rely on project rules or runtime policy for agent governance?

A: Runtime policy should own the guarantee, while project rules should own the guidance. Project rules help the agent behave consistently, but runtime controls define what it can actually do. If the action matters operationally, the enforcement must sit outside the prompt.

Technical breakdown

Why prompt files fail as control boundaries

Prompt-side instruction files help agents follow conventions, but they do not change the model's underlying behaviour into deterministic enforcement. The model still weighs the instruction against competing context, and long-context retrieval can degrade when relevant text is buried. That means a rule can be present, correctly worded, and still fail at the moment it matters. In governance terms, these files provide coordination, not prohibition. Security teams should treat them as policy inputs that support behaviour, not as the mechanism that constrains action.

Practical implication: Use prompt files for guidance, but place hard restrictions in the runtime that executes agent actions.

How execution-layer controls actually constrain agent action

Execution-layer controls sit between the agent's decision and the system effect. They can deny filesystem reads, block process launch, suppress outbound network connections, or require approval before a tool call proceeds. Unlike prompt text, these controls do not depend on the model remembering or honouring an instruction. They operate at the point of enforcement, which is why they are materially different from rules embedded in markdown files. The practical architecture is closer to a policy engine than a style guide.

Practical implication: Map every high-risk agent capability to a runtime deny, allow, or ask-first decision before deployment.

Why long-context agents make governance harder

As agents absorb more code, logs, docs, and rules into a single session, the probability that a critical instruction loses salience rises. The issue is not just context length. It is that the agent's working memory becomes crowded with competing signals, so important constraints can drift away from the decision point. That is why a model can appear compliant in one turn and ignore a constraint in the next. The governance implication is that salience cannot be the only control strategy when action risk is high.

Practical implication: Assume critical constraints can fade from attention and enforce them outside the prompt.

NHI Mgmt Group analysis

Prompt files are governance aids, not enforcement controls: files like CLAUDE.md and AGENTS.md help shape behaviour, but they do not create a boundary the model cannot cross. That distinction is the core control failure in many agent deployments. If the only safeguard is language inside the context window, the organisation is relying on salience instead of authority. The practitioner conclusion is clear: classify instruction files as policy inputs, not as access controls.

Execution-layer security is the real trust boundary for AI agents: the moment that matters is not when the agent reads an instruction, but when it opens a file, starts a process, or makes a network request. That is where permission can be granted, denied, or logged. In identity terms, the effective control point is runtime authorisation, not prompt persuasion. Practitioners need to treat that boundary as the system of record for what the agent may do.

Context salience is not a dependable governance model: long-context systems can still miss or de-prioritise critical instructions when the prompt grows crowded. That makes human-written rule files fragile under realistic tool use, especially when logs, code, and prior messages compete for attention. The lesson is not that rules are useless. It is that rules cannot carry the guarantee load alone. Security teams should design for disappearing attention, not perfect recall.

Identity governance for AI agents must shift from declarative guidance to runtime constraint: the same governance assumption that works for humans, that instructions are followed because they are authored and reviewed, breaks down when an agent can act without fixed human pacing. The implication is that the governance model has to move from telling the actor what to do to controlling what the actor can actually execute. That is the difference between policy and permission.

What this signals

Execution-layer security is becoming the governance model that matters most for agents: as tool use expands, the control point shifts from what the model is told to what the runtime will allow. That change should reshape how teams design approvals, logging, and policy enforcement for autonomous tools.

Prompt files will remain useful as operational context, but they should be treated as advisory control inputs rather than assurance artefacts. The more an agent can do without human pacing, the less credible it becomes to treat text in the context window as the primary safety mechanism.

For practitioners

• Define the runtime boundary first List every action class the agent can take, then decide which ones must be denied, approved, or logged at execution time instead of relying on prompt text.
• Separate guidance from enforcement Keep conventions and project rules in markdown files, but move access controls, tool gates, and network restrictions into the agent runtime.
• Treat tool access as a privileged capability Review file, shell, and network permissions for each agent as if they were privileged identities, because those capabilities are the real blast radius.
• Add approval gates for high-risk actions Require ask-first handling for credential access, outbound connections, and any write outside the expected workspace.

Key takeaways

• AI agent rule files can shape behaviour, but they do not enforce it, so they are not sufficient as a security boundary.
• The decisive control point is the execution layer, where systems can block or approve file access, process launch, and network activity.
• As agent contexts grow, teams should move governance away from prompt salience and toward runtime permission controls.

Related NHI Mgmt Group resources: Ultimate Guide to NHIs · Top 10 NHI Issues · AI Agents vs Agentic AI

Key terms

• Execution-layer security: Execution-layer security is the practice of enforcing policy where a system actually performs an action, such as opening a file, launching a process, or making a network request. For AI agents, it is the difference between being told not to do something and being technically prevented from doing it.
• Prompt Context: Prompt context is the text and surrounding instructions that define what an AI system is being asked to do. In governance terms, it can become an early signal of intent because it often reveals the target, objective, and desired output before any data movement occurs.
• Runtime Policies: Runtime policies are enforcement rules that control what a workload is allowed to do while it is running. They can be used to block dangerous actions, contain suspicious behavior, or automate response based on security requirements. In container environments, they turn detection into immediate control.
• Context salience: Context salience is the degree to which an instruction remains prominent enough in a model's working context to influence a decision. In long-context agent systems, salience can fade even when the instruction is present, which makes it unreliable as a sole control.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.