Runtime Security for AI Agents

Runtime security for an AI agent means enforcing limits outside the model, at the moment each action is attempted. Policies, system prompts and pre-deployment reviews shape what an agent is meant to do. Only runtime controls constrain what it does when something goes wrong.

The distinction matters because an agent is not a fixed program. It reads context, chooses its next step, calls a tool, reads the result and chooses again. What it does depends on content it meets while running, and some of that content is written by people who do not work for you.

The model proposes; something else decides

OWASP’s guidance on Excessive Agency makes the central design point plainly: enforce authorization in the downstream systems instead of trusting the model’s judgment about what is allowed. Its guidance on sensitive information disclosure adds a warning that matters for anyone relying on prompt wording as a control. Instructions in a system prompt that restrict what the model returns may not always be honored and can be bypassed through prompt injection.

Together these set the rule for the rest of this article. A system prompt states intent. A control that can be talked out of its job is not a control. Anything that must hold has to be enforced by a component the model cannot persuade.

Seven runtime control points

The table maps the places where an agent’s behavior can be observed or limited while it runs. It is an architectural synthesis built on OWASP, NIST and Model Context Protocol guidance, not a certification checklist.

Two properties that make agent runtime different

Context is part of the attack surface

Agents carry state: retrieved documents, tool results, memory that persists across sessions. OWASP’s agentic list treats memory and context poisoning as a distinct risk because anything an attacker plants there can influence later actions, long after the original input has gone. Runtime security therefore has to cover what an agent remembers as well as what it does. That means provenance on memory entries, limits on what can be written to long-lived memory, and the ability to roll memory back during an investigation.

Autonomy compounds mistakes

A single bad step in a multi-step task becomes the input to the next step. OWASP’s agentic list also separates out cascading failures and rogue agents as their own categories. The implication for design is containment by default: limit how many steps an agent may take without a checkpoint, and limit how far one agent’s output is trusted by another.

Where runtime controls fall short

A gateway that checks each call cannot judge intent. A sequence of individually allowed calls can still add up to a leak, which is why policy has to reason about session history and not only the current request. Policy also sprawls. Every new tool needs rules, and a rule set nobody can read is a rule set nobody trusts.

Coverage has gaps too. The OpenID Foundation’s paper on identity for agentic AI points out that browser-based and computer-use agents can bypass API-based authorization entirely by working through the user interface. A tool gateway that governs API calls says nothing about an agent clicking through a web application as the user. Those agents need isolation and egress controls first, because the policy layer cannot see what they do.

The standards are also still forming. NIST’s National Cybersecurity Center of Excellence has published a concept paper and asked for industry input on agent identification, authorization, auditing and prompt-injection controls. That is a signal about maturity: plan for components you can replace as the guidance settles.

Sequencing the work

Not every agent justifies every control. A reasonable approach, offered as a recommendation, is to tier agents by two factors, how much autonomy they have and how bad their worst action could be, then apply controls in this order:

1. Enumerate every agent in use, including those teams built themselves, with its tools, data and owner.

2. Move enforcement out of the model for the highest-consequence tools first, with deny-by-default policy.

3. Shorten credential lifetimes and narrow scopes so a hijacked session expires and cannot reach far.

4. Control egress, since leaks need a way out.

5. Log enough to reconstruct an incident, including the content that preceded each action.

6. Rehearse containment. Practice revoking an agent’s access and clearing its memory before an incident forces the first attempt.

A five-question test

For any agent in production, a security team should be able to answer the following within an hour:

• What can it reach right now?

• What did it do overnight, and what had it read before it acted?

• Who authorized it, and on whose behalf is it acting?

• How would we stop it immediately?

• What does it remember, and could someone have planted it?

Where the answer to any of these is “we would have to ask the team that built it”, the runtime layer is not yet there.

Where to start

Sources

• OWASP GenAI Security Project: Top 10 for LLM Applications, Excessive Agency — OWASP

• OWASP GenAI Security Project: Top 10 for LLM Applications, Sensitive Information Disclosure — OWASP genai.owasp.org

• OWASP GenAI Security Project: Top 10 for Agentic Applications — OWASP genai.owasp.org

• Model Context Protocol: Security Best Practices — Model Context Protocol project

• Accelerating the Adoption of Software and AI Agent Identity and Authorization (concept paper) — NIST National Cybersecurity Center of Excellence

• Identity Management for Agentic AI — OpenID Foundation, AI Identity Management Community Group openid.net