Explainer
What is AI runtime security?
An AI agent decides what to do while it is running. That single fact is why design-time review cannot secure one, and why a new control layer has appeared: enforcement at the moment of action. This page explains what runtime security is, why prompt instructions are not a control, what a runtime layer is made of, and what an auditor will ask you to show.
The short answer
Runtime security is the set of controls that decide, live, whether an action an AI system is attempting may proceed. Not whether it was a good idea — whether it is permitted. It answers four questions on every step: may this tool be called with these arguments, may this code execute and inside what isolation, may this identity read or write this data, and must this stop for a human.
The reason it exists as a separate discipline is that the risk in an agentic system is not the text the model produces. It is the action the model takes: a file written, an API called, a payment issued, a record deleted. Text can be reviewed after the fact. An action cannot be un-taken.
Why runtime enforcement matters for AI agents
In ordinary software the code path is fixed, so reviewing the code reviews the behaviour. In an agentic system the path is chosen at runtime by a model responding to inputs you do not control — a retrieved web page, an uploaded document, a message from another agent. Instructions in your prompt sit in the same channel as that content and compete with it on equal terms. Published research documents the consequence plainly: instructions planted in retrieved content get acted on with the agent’s own permissions, and the industry risk lists rank that class first among application-layer threats.
So the control cannot live in the prompt. It has to live somewhere the model cannot argue with: a sandbox that has no route to production, a policy engine that inspects the arguments before the call leaves, a vault that declines to release a credential for this identity. Those refusals hold whatever the model was persuaded to attempt — which is the entire point.
The five components of a runtime layer
Most teams build these in the wrong order, starting with prompt hardening and adding isolation after the first incident. The cheaper sequence is isolation, identity, policy, secrets, evidence — each one narrows what the next has to handle.
Four checks that test a runtime posture
- Can a forbidden action be refused by a control, rather than merely discouraged in a prompt?
- Does each agent authenticate as itself, with permissions narrower than the application’s?
- Are secrets fetched under policy at the moment of use, and absent from context and logs?
- Can you reconstruct any past run — every action, decision and denial — from the logs alone?
A deployment that fails any one of these will demo well and stall in security review, which is where most promising agent products lose a quarter.
Questions people ask about AI runtime security
What is AI runtime security?
AI runtime security is the enforcement of what an AI system is allowed to do at the moment it acts, rather than the review of what it was designed to do beforehand. It covers four decisions taken live, on every step: whether this tool call is permitted, whether this code may execute and inside what isolation, whether this data may be read or written by this identity, and whether the action must stop for a human. It is the difference between a policy document and a control that can actually refuse.
Why does runtime enforcement matter for AI agents?
Because an agent's behaviour is decided at runtime by a model, not at build time by you, so there is no fixed code path to review. Instructions in the prompt are advisory — a sufficiently persuasive input overrides them, and the model has no obligation to obey. Runtime enforcement moves the decision outside the model: the sandbox refuses the network call, the policy engine rejects the tool invocation, the vault declines to release the credential. That refusal holds regardless of what the model was convinced to attempt.
How is runtime security different from model security or AI governance?
Model security is about the model itself — training data, weights, alignment, jailbreak resistance. Governance is the documented programme: inventories, risk assessments, approvals and audits. Runtime security is the layer in between that turns governance into behaviour: it is what physically prevents the action the policy forbids. A programme with governance and no runtime enforcement can describe its controls but cannot demonstrate them, which is exactly what fails an enterprise review.
What does an AI runtime security layer actually include?
Five components. Isolation — a sandbox that scopes filesystem, network and process access for generated code. Identity — every agent authenticating as itself, never as the application. Tool-call policy — an allow-list of actions with argument-level constraints, evaluated before execution. Secret mediation — credentials fetched from a vault under policy and never held in the agent's context. Evidence — an append-only log of each action, its decision and its outcome, sufficient to reconstruct any run.
How do you secure an AI agent at runtime?
Work in that order, because each step depends on the one before it. Put execution in a sandbox first. Give the agent its own identity with the narrowest permissions that let it complete its work. Put every external action behind a policy check that inspects the arguments, not just the tool name. Move secrets into a vault the agent must ask for. Then log everything and alert on denials, because a denial is a signal — either a misconfiguration or an attempt. Finally, add a human-in-the-loop gate and a kill-switch on anything consequential.
Can prompt engineering replace runtime guardrails?
No, and relying on it is the most common structural mistake in agent deployments. A prompt instruction is text competing with other text, including instructions hidden in a web page, a document or another agent's output. The agent's permissions, not its prompt, decide what damage a successful injection can do. Prompt design reduces the frequency of bad attempts; runtime enforcement bounds their consequence. Only one of those survives a determined input.
How does runtime security apply to citizen development and shadow AI?
It is the only control that scales to work you did not commission. When staff build agents in low-code tools and copilots, you cannot review each one, but you can make the platform itself refuse: identity on every agent, an allow-list of connectors, egress restrictions, secrets available only through a vault, and central logging of what was built and what it touched. That turns shadow AI from an unknown risk into an inventoried one with a ceiling on its permissions.
What evidence do auditors ask for on AI runtime controls?
Four artefacts, consistently. An inventory of agents and the permissions each holds. The policy set, versioned, with a record of changes. Action logs showing what was attempted, what was allowed or denied, and by which identity. And a demonstrated deletion and kill-switch path. Controls you cannot evidence are treated as absent, which is why logging belongs in the first release rather than the hardening sprint.
Domain assets in this category
Each name below is the exact phrase one part of this layer is searched by, and is available to buy outright or lease for twelve months.
Sources
- NIST AI Risk Management Framework — Generative AI Profile (NIST AI 600-1)
- OWASP Top 10 for LLM Applications
- Not what you've signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection (arXiv:2302.12173)
- AI Agents Under Threat: A Survey of Key Security Challenges (arXiv:2406.02630)
- Why Do Multi-Agent LLM Systems Fail? — the MAST failure taxonomy (arXiv:2503.13657)
Public standards and published research, linked so every claim above can be checked at source.