AI agent runtime security: policy, audit and a buyer checklist
How runtime policy for AI agents works, from allow, redact, deny and ask decisions to audit trails, plus a checklist for evaluating tools.
For Security leaders and buyers
AI agent governance is the set of decisions about which coding agents may run in your company, what they may do, who approves the risky parts, and how you prove it later. AI runtime security is the enforcement half: policy applied while the agent works. This guide covers how runtime policy decisions work, what to record, how to roll them out, and what to ask a vendor.
What is AI runtime security for agents?
Most agent controls are set before the agent starts: a settings file, an allowlist, a sandbox profile. Runtime security adds a decision at the moment of action. The agent is about to run a command, read a file, call a tool or send a prompt, and something outside the model checks that action against policy.
That "outside the model" part is the point. OWASP's AI Agent Security cheat sheet says authorization should be enforced in the execution component, outside the agent's context, and that the agent may propose an action while a policy service independently validates scope, privilege and approval state before it runs. A rule written in a prompt or an instructions file is a request. A check in the execution path is a control.
How do prompt inspection and runtime monitoring differ?
They watch two different things.
Prompt inspection looks at text on its way to a model provider. It answers questions like: did a pasted key, a customer record or a private URL leave the company? It can redact a value or block the prompt.
Runtime monitoring looks at what the agent does on the machine. Which shell commands did it run? Which files did it read? Which MCP servers and skills did it load? Did it write outside the project? It can allow, deny or ask.
Neither covers the other. A clean prompt can lead to a harmful command, and an allowed command can sit beside a prompt that carried a secret. If a vendor offers only one, ask how the other gap is covered.
Which policy decisions should an agent control support?
A useful policy engine gives you four outcomes, not two.
| Decision | Meaning | Typical use |
|---|---|---|
| Allow | Action proceeds | Reads inside the project, test runs, known-safe commands |
| Redact | Action proceeds with a value removed or replaced | A credential in a prompt, a token in tool arguments |
| Deny | Action is blocked and the agent is told why | Reading secret files, calling an unapproved MCP server |
| Ask | A human decides, with the exact action shown | Pushes, deploys, destructive commands, new network destinations |
Agents already work this way at small scale. Claude Code's PreToolUse hooks return a permissionDecision of allow, deny, ask or defer, and a hook can also replace a tool's arguments before it runs with updatedInput. That is the same shape as allow, ask and redact applied to a tool call. What a hook does not give you is central management, cross-tool coverage or a unified record, which is why teams end up looking for a layer above individual agents.
Two details from OWASP's guidance separate a real control from a dialog box. First, approval has to be bound to the exact action: actor, tool, target and parameters, with an expiry, and changed parameters need a fresh approval. A generic "user confirmed" flag is not enough. Second, the system should fail closed. If the risk classification, the policy lookup, the approval check or the audit logging fails, the action does not run.
What should the audit trail contain?
An audit trail is a record that lets someone who was not there reconstruct what happened and who allowed it. For agents, OWASP recommends logging every decision, tool call and outcome, and for high-risk actions the action classification, risk score where there is one, authorization outcome, approval identifier, execution result and the policy version in force.
Policy version is the field people forget. Without it you cannot say whether an action was permitted by the rule that existed at the time or by one written afterward.
Some practical points:
- Record the decision and its reason, not only the command
- Keep secrets and personal data out of the log itself. A log full of raw prompts becomes a sensitive store of its own
- Tie each record to a person or service identity and a machine
- Send logs somewhere the developer cannot edit
- Decide retention up front, since a policy on paper means little if the evidence is gone after a week
Agents also emit their own telemetry. Claude Code, for example, can export OpenTelemetry events for tool decisions and tool results, but prompt text is redacted unless you turn it on. That is useful raw material, and it does not replace a governed record that spans every agent in use.
How do you roll out runtime policy without stalling developers?
Roll out in stages and let evidence drive each step. The stages below are practitioner advice, not a standard.
- Observe. Run in audit-only mode on one team. Log what policy would have done and block nothing.
- Triage. Read the would-have-blocked list weekly. Each entry is either a real finding or a rule to fix.
- Ask before deny. Move uncertain rules to "ask" so developers see the reason and can proceed, while you collect context.
- Enforce the clear cases. Credentials in prompts, secret file reads and unapproved MCP servers are good candidates because few legitimate workflows need them.
- Widen by team, keeping an exception process with an owner and an expiry date.
False positives deserve a plan before launch, not after the first complaint. Give every block a plain-language reason and a route to a human. Track the ratio of overrides to blocks per rule; a rule that people routinely override is either wrong or poorly explained. Keep the false positive cost visible to the team that owns the policy, otherwise rules only ever get stricter and developers learn to route around them.
What belongs on a buyer evaluation checklist?
Use these questions in a demo and in a proof of concept. Several come straight from OWASP's guidance on agent authorization and logging.
Coverage
- Which agents does it cover today (Claude Code, Codex, Gemini CLI, Cursor, Copilot), and how does it attach to each?
- Does it see prompts, actions on the machine, or both?
- What does it do for agents it does not know?
Enforcement
- Does enforcement happen outside the agent's context, and can the agent or the model disable it?
- Does it fail closed when the policy service or log sink is unavailable? What happens offline?
- Can a developer with local admin rights turn it off, and would you find out?
- Is approval bound to the exact action and parameters?
Policy
- Can you express rules for commands, file paths, MCP servers, skills and network destinations?
- Does it support allow, redact, deny and ask, with a reason shown to the user?
- Can it run in audit-only mode before enforcement?
Evidence
- What fields does each record carry? Is the policy version among them?
- Where are logs stored, who can edit them, and how do they reach your SIEM?
- Are secrets redacted in the log itself?
Data and deployment
- Where are prompts processed, and are they stored? Who at the vendor can see them?
- Is it deployed in your environment or hosted?
- What is the added latency for a prompt and for a tool call?
Fit
- How does it work alongside each agent's built-in permissions and managed settings? You want it to add to them, not fight them.
- What does it claim about prompt injection? Treat any claim of full prevention as a red flag. The honest answer is that it limits impact.
Ask to see a deliberate bypass attempt in the demo. Agent rules based on matching command text can be sidestepped by trivial rewrites, and Claude Code's own documentation says so about its deny rules. A vendor who has tested this will not be surprised by the request.
Where does governance fit in the wider program?
Governance gives runtime controls their rules. NIST's AI Risk Management Framework is voluntary, and NIST published a Generative AI Profile (NIST AI 600-1) for it in July 2024. NIST states that the AI RMF 1.0 is being revised, so check the current version before you cite it in policy. For coding agents, the practical governance pieces are an accountable owner per agent, an approved list, written rules for commands, files, tools and credentials, and the records described above. For the larger picture, see the AI coding agent security overview, and for tool-by-tool settings, the Claude Code security guide and the MCP security guide.
This is the layer Rechazo works at. It checks prompts and agent actions against one policy across Claude Code, Codex, Gemini CLI, Cursor and Copilot, sitting next to each tool's own settings, and keeps the record described above. It is in waitlist stage, so if the buyer checklist reads like your shortlist, that is the conversation to have with us.
What to do this week
- Write down which agents your developers use now, and who owns each.
- Choose the five actions you most want to deny, ask about or redact, then write them as plain-language policy.
- Start an audit-only pilot, either with built-in hooks and telemetry or with a tool, and read the output after a week.
- Decide where agent logs will live, how long you keep them and who may read them.
- Send the buyer checklist above to any vendor you are talking to, and ask for a bypass demo.
Frequently asked questions
- What is AI agent governance?
- AI agent governance is the set of rules, owners and records that decide which agents may run, what they may do, who approves risky actions, and how you prove it afterward. For coding agents it means an approved list of tools, written policy on commands, files, MCP servers and credentials, a named accountable owner, and a log that shows what the agent actually did.
- What is AI runtime security?
- AI runtime security means enforcing policy while an agent is working, rather than only reviewing configuration beforehand. It looks at what the agent is about to do, such as a shell command, a file read, a tool call or a prompt leaving the machine, and decides to allow, change, block or escalate it. It complements build-time review and model-level safeguards.
- What is the difference between prompt inspection and runtime monitoring?
- Prompt inspection examines the text going to a model provider, for example to redact a credential before it leaves. Runtime monitoring examines the agent's actions on the machine, such as commands run, files read and tools loaded. A prompt can be clean while the action is harmful, and an action can be allowed while the prompt leaks a secret, so teams usually need both.
- What should you look for when buying an AI agent security tool?
- Check which agents it covers, whether enforcement happens outside the agent's own context, whether it fails closed, how it handles false positives, what the audit record contains, and where your prompts and logs are processed. Also ask how it works with each agent's built-in controls, and whether a developer can switch it off without anyone noticing.