---
title: "AI Agent Runtime Security: A Complete Guide to Policy, Isolation and Containment"
description: "Most agent incidents happen at run time, between a decision and its effect. This guide covers seven controls, incident patterns and why walls beat prompts."
author: "Renn Calloway"
category: "Defensive Architecture & Security Controls"
date: 2026-10-31T10:20:05.341Z
canonical: "https://agenticcyber.co/blog/ai-agent-runtime-security-complete-guide"
---

# AI Agent Runtime Security: A Complete Guide to Policy, Isolation and Containment

![man, bodyguard, security](https://cdn.pixabay.com/photo/2019/04/17/17/06/man-4134779_1280.jpg?w=1200&q=75)

> Most agent incidents happen at run time, between a decision and its effect. This guide covers seven controls, incident patterns and why walls beat prompts.

An agent reads a ticket, decides to run a command, and a person clicks approve on a prompt the agent itself wrote. Every earlier check, from the architecture review to the posture scan, passed days ago. The only control still awake at that moment is runtime security, and in many deployments it is thin.

This is the central page for our runtime security writing, which spans policy points, credentials, approvals, isolation, records, stop controls and testing. Sources are vendor documentation, published research and our own incident analyses. The content is defensive guidance, not an audit, and every vendor claim carries the vendor's name.

## The moment that matters

Think of runtime security as the layer that judges an agent at the instant it moves from deciding to doing. Straiker, a vendor, names that instant the execution gap. Its research page argues that an action must be judged against the chain of events behind it, and not as a lone call ([Straiker, execution gap](https://www.straiker.ai/blog/ai-agent-execution-gap-runtime-security)). The example it gives is an outbound API request that looks valid in every respect yet closes an exfiltration chain started by an injected document. The page also states that 85 percent of successful attack scenarios in its own STAR Labs testing involved agents acting beyond their intended authority. That is one vendor's sample, so read it as such.

The idea holds up without the product. Every action that changes something raises two questions. What is this agent allowed to do at all? And what sequence led to this particular request? Permissions and isolation answer the first; context, intent and approval answer the second. A deeper treatment sits in [controls at the action layer](/execution-gap-controls-at-the-agent-action-layer).

## Plan for some attacks to work

Assume a filter will eventually miss. A 2025 paper titled "The Attacker Moves Second" describes adaptive attacks that beat twelve published defences, mostly at rates above 90 percent, although several of those defences had reported close to zero before ([arXiv:2510.09023](https://arxiv.org/abs/2510.09023)). So aim for a small blast radius around a steered agent instead of a flawless detector. The reasoning appears in this piece on input filtering.

Two design rules help you cap that radius. Meta's Agents Rule of Two caps a session at two of three traits. The traits are untrustworthy input, reach into sensitive systems or private data, and the power to change state or contact the outside world ([Meta, Agents Rule of Two](https://ai.meta.com/blog/practical-ai-agent-security/)). It grew out of Simon Willison's lethal trifecta, which [his write-up](https://simonw.substack.com/p/new-prompt-injection-papers-agents) summarises. Neither is a detector. Both are choices you make on a whiteboard, which is why they cost almost nothing.

## Seven controls, in the order they bite

### A single checkpoint ahead of every side effect

Funnel each state-changing tool call through one component able to permit, refuse or escalate. A gateway, a hook in the framework or a proxy will do. Feed it context: the agent, the person it acts for, whether untrusted material is in play and the preceding steps. A sample rule: with untrusted content in context, any outbound send requires approval.

### Credentials cut to the job

Hand out narrow tokens with brief lifetimes, one per task. A hijacked agent then wields one job's authority and not the whole estate. Identity patterns are in [OAuth for AI agents](/oauth-for-ai-agents-scopes-token-exchange-delegation).

### Approval screens built by the platform

Derive the approval text from the executed call itself: the command, its destination, files touched and network target. Let the agent write the explanation and the reviewer signs off on fiction. Audit a sample monthly to confirm that the prompt, the action and the record tell the same story.

### Isolation whose rules live outside the box

Execute tools in a virtual machine or container holding no standing credentials, behind an egress allowlist, with the policy kept on the host. Anthropic's engineering post on Claude Code sandboxing insists on two boundaries together: lose the network limit and a compromised agent can leak files, lose the filesystem limit and it can slip out of the sandbox ([Anthropic engineering](https://www.anthropic.com/engineering/claude-code-sandboxing)).

### Records beyond the agent's reach

Store what fed each policy decision, the verdict, the action and the outcome where the agent cannot touch it. A preprint from September 2026 reports that all but one of the local agent harnesses it tested let an agent erase its own traces on request, and advises capturing traces through a mechanism the agent does not control ([arXiv:2609.30266](https://arxiv.org/abs/2609.30266)). It is one preprint, so verify against your own tooling. Useful alerts include privilege changes, newly added tools and bursts of refusals.

### Guardrails in their proper place

Classifiers and filters reduce noise and stop crude attacks. They are not authorization. The split is explained in [the guardrails versus controls article](/ai-agent-guardrails-are-not-controls-where-each-belongs).

### A stop you have rehearsed

Be able to revoke tools, suspend one agent or halt a group in minutes, and time it in a drill. See [kill switch design](/ai-agent-kill-switch-designing-stop-containment-and-rollback). Add canary tests too: plant harmless instructions in sources your agents read and check the tool-call log. Wire the findings into a regression suite, as in [prompt injection testing in CI](/prompt-injection-testing-in-ci-a-regression-suite-for-agents).

## What our teardowns keep showing

Across the public reports we have analysed, the same handful of weaknesses recur, and most rest on single-vendor research that we flag each time. An attacker-controlled repository can nominate its own reviewer. A fresh child session can start without the guardrails the parent had. Operations agents that read logs and mail are reading an attack channel. Approval text must never come from the model. Background helpers parse configuration they should not trust. A version pin proves little if the install never checks what it fetched. Finally, a rule enforced inside the sandbox can be edited from inside it.

## Where each agent kind differs

- **Coding agents:** repository trust and developer credentials are the exposure.

- **Browser agents:** signed-in sessions meet untrusted pages.

- **Operations agents:** they read alerts and logs that outsiders can influence, while holding strong rights.

- **Tool-heavy MCP agents:** each server widens the surface.

- **Multi-agent systems:** authorization needs a fresh check at every hop.

## Four stages of runtime maturity

LevelWhat exists

1. SeenA list of agents, their action logs, a named owner for each
2. BoundedExpiring scoped credentials, a sandbox, restricted outbound hosts
3. VerifiedContext-aware checkpoint, platform-built approvals, logs kept apart
4. ProvenCanary regression suite, stop drills, an incident playbook

Treat the stages as a planning aid of our own devising, not a compliance claim.

## One operations agent, control by control

Consider an agent that reads cluster alerts and logs and may restart services and deploy fixes. Applied to it, the controls look like this:

ControlFor this agent

CheckpointEvery restart or deploy is vetted by a service that inspects the namespace and the origin of the alert that prompted it
CredentialsA role limited to restarting listed services inside one namespace, with no right to create privileged workloads
ApprovalAny change to images or security settings reaches the engineer on call as a literal diff
IsolationCluster admission rules refuse privileged pods requested by the agent's account
RecordsThe cluster's own audit log, not the agent's notes, is the reference
StopOne action revokes the role and pauses the queue
TestingEach month a canary alert with a harmless instruction is injected, and the agent passes only by ignoring it

## Fewer prompts, taller walls

When teams worry about agent risk, the reflex is more approval prompts. That reflex backfires. Anthropic's engineering team describes approval fatigue, where constant clicking leaves users paying less attention to what they approve, and reports that sandboxing cut permission prompts by 84 percent in its internal usage ([Anthropic engineering](https://www.anthropic.com/engineering/claude-code-sandboxing)). That figure is the vendor's own measurement of its own product, so treat it as a direction, not a benchmark.

The direction is right, though. A person asked to approve everything approves nothing in practice. My recommendation is to reserve human approval for the few actions that are irreversible or cross a trust boundary, and to replace the rest with hard boundaries that need no decision: a filesystem limit, an egress allowlist, a token that cannot do the thing.

The recommendation fails when the sandbox cannot be built, for example an agent that must operate on a developer's whole workstation or on a production system with broad rights. There, fewer prompts only mean less oversight, and you need either a narrower task or tighter manual review. It also assumes the boundary is enforced outside the agent, which is why the record-keeping preprint above matters.

## Numbers to follow over time

- Share of side-effect calls that pass the policy point.

- Share of agents whose credentials last under a day.

- Canary pass rate per agent.

- Seconds needed to cut off one agent at the latest drill.

- Days between a vendor fix and your deployed version.

## What to do when a runtime control fires

A denied call is information. Decide in advance who looks at it and how fast. A single refusal on a low-risk tool usually needs only a weekly review. A refusal that follows a retrieval of external content, or a cluster of refusals from one agent, deserves a same-day look, because it may be the visible edge of a steered session.

Keep the first response small and reversible: suspend the one agent, revoke its task token, preserve the records. Larger actions, such as pulling a tool from every agent, need the owner of that tool. The wider playbook is in incident response for agentic AI.

## A thirty, sixty and ninety day start

- **First thirty days.** List the agents and their side-effect tools. Put one checkpoint in front of the three riskiest tools and turn on external logging.

- **Days thirty-one to sixty.** Shorten credential lifetimes, sandbox the coding and browser agents, and build platform-rendered approvals for irreversible actions.

- **Days sixty-one to ninety.** Add canary tests for every external content source, run a stop drill, and publish the numbers listed above to the agent owners.

Scale the pace to the authority involved: an agent that can move money earns a faster schedule than one that summarises documents.

## Build, buy or both

You may already own most of the pieces: a proxy for the checkpoint, an identity provider for tokens, a container platform for isolation and a log stack for evidence. Vendors package these with context-aware checks and stop controls. Before purchasing, write down the exact gap the product must fill, then try it on a replay of your own incidents. One workable division is to build the checkpoint and the evidence store yourself, because they encode your rules, and buy detection content, which moves faster than a small team can track. Staffing should settle it.

## Unknowns

- Whether context-aware policies survive adaptive attackers; today's support is largely argument.

- What policy checks cost in delay and money at scale.

- Which runtime evidence future standards will expect.

This guide is not a substitute for review by qualified security engineers.

## Runtime security in brief

## FAQ

### What is runtime security for agents?

The controls that govern what happens between an agent's decision and its effect on another system: policy checks, scoped credentials, isolation, independent logs and a tested stop.

### Is a filter enough?

No. Treat it as one layer. Adaptive attacks have bypassed published filters, so limit what a steered agent can reach.

### What is the best first step?

Route every side-effect tool call through one policy point and log it somewhere the agent cannot edit.

### How do I know the controls work?

Plant harmless canary instructions in content the agent reads, run them in a sandbox with fake data and check the tool-call log.


---
Source: https://agenticcyber.co/blog/ai-agent-runtime-security-complete-guide