AI Agent Security
AI agents now take real actions. They move money, change code, query production databases, and reconfigure infrastructure, driven by instructions they read at runtime. AI agent security is the discipline of governing those actions: deciding, on every tool call, what an agent is allowed to do before it does it.
Model safety asks what an agent says. Agent security asks what it does. The two are different problems, and the second one is not solved in the prompt. The durable control point is the action itself, evaluated against deterministic policy at runtime, outside the model's reasoning loop, where a misled or compromised agent cannot reason its way past it.
This is the reference for how to secure and govern AI agents in production: the trust boundary that actually holds, runtime enforcement, the governance that surrounds it, and how it applies to the 224,124 tools across 8,806 servers in our catalogue. Written for platform engineers, security leads, and CTOs putting agents to work against real systems.
What AI agent security means
An AI agent is a model given tools and a loop: it reads context, decides on an action, calls a tool, reads the result, and repeats. Every consequential thing an agent does happens through a tool call. So the unit of agent security is not the model and not the prompt. It is the call: this tool, with these arguments, made by this identity, right now.
That reframes the problem. Securing an agent is not about making the model more obedient. It is about putting a decision in front of each action: allow it, deny it, slow it down, or send it for human approval. When that decision is deterministic and lives outside the agent, the agent's behaviour stops being a security assumption. It becomes an input that policy bounds.
Why prompt guardrails are not agent security
The first instinct is to instruct the model: "never delete production data", "only refund under $100", "do not email external addresses". These prompt guardrails live inside the agent's context, and a sufficiently capable agent can reason around them. Worse, untrusted content the agent reads — an issue, a web page, a database row — can carry instructions that override the system prompt. This is prompt injection, and it turns the agent's own helpfulness against you.
The lesson from documented incidents is consistent: the agent is rarely compromised in the classic sense. It is simply following instructions it received through a channel it trusts. No amount of prompt engineering closes that gap, because the gap is the model's willingness to follow instructions in the first place. The fix is structural. Move the rule out of the context the agent can see and into the path the agent must use.
Runtime enforcement: govern the action, not the prompt
Runtime enforcement puts a policy check in the request path between the agent and the systems it calls. Every tool call passes through it. The check reads the tool, its arguments, and the calling identity, evaluates them against deterministic rules, and returns a verdict before the call executes: allow, deny, rate-limit, or require approval. The agent never sees the rules. It sees only the decision.
Because this runs outside the model's reasoning loop, it cannot be negotiated with. A prompt injection can convince the model to attempt a $50,000 refund; it cannot convince the policy layer to allow one. The same property holds for a buggy agent, a runaway loop, or a compromised client: the blast radius is whatever policy permits, not whatever the agent decides. This is what "AI runtime security" means in practice, and it is the half of agent security that the prompt cannot provide. PolicyLayer is the runtime layer: connect your servers and every call is checked before it runs. See writing policies for how rules are expressed.
AI agent governance: identity, approvals, and audit
Enforcement stops a bad action. Governance is the surrounding system that decides what counts as bad, for whom, and proves it after the fact. Four pieces make an agent fleet governable:
- Per-identity scopes. Each person and each agent connects with its own scoped credential, carrying only the tools and limits you grant. A support agent reads invoices; only the finance agent issues refunds.
- Approval gates. Sensitive or destructive calls pause and wait for human sign-off before a credential is issued, so a person stays in the loop exactly where it matters and nowhere it doesn't.
- Rate and spend limits. Caps per identity and per window mean a loop or a bad input cannot compound a single mistake into a real loss.
- Audit by identity. Every call is logged with who made it, the tool, the arguments, and the allow-or-deny decision, so a security team can answer "who did what, and was it allowed".
Together these are what turns an autonomous system into a governed one, and what an "AI governance platform" has to deliver to be more than a dashboard. PolicyLayer provides them at the same point it enforces policy: one control plane across every server and every seat.
Securing agents that use MCP
Most agents reach their tools through the Model Context Protocol (MCP), the emerging standard for connecting agents to servers. MCP makes integration uniform, and it makes the security problem concrete: the protocol defines transport and message format but takes no position on authorisation, so every server decides for itself what its tools allow, and most decide nothing. That is why the enforcement point belongs at the protocol boundary, in an MCP gateway that evaluates every call before it reaches the server.
This is where AI agent security gets specific and operational. PolicyLayer classifies every tool in its catalogue by what it can do — read, write, execute, destructive, financial — across 224,124 tools and 8,806 servers, so you start from recommended policy instead of a blank page. Go deeper from here:
- MCP security reference — how MCP fails in production and what it takes to run it safely.
- The MCP Attack Database — documented attack patterns against agent deployments, and the policies that stop them.
- The tool catalogue — every classified MCP tool, filterable by risk level.
- Securing autonomous agents — hard limits for always-on agents with no human in the loop.
- Compliance — mapping enforcement and audit to your control framework.
How to secure your AI agents
A practical sequence, in priority order:
- Put a policy gateway in the path. Route the agent's tool calls through an enforcement point that runs outside the model.
- Deny destructive and financial actions by default. Make the dangerous classes opt-in, not opt-out.
- Scope each identity. Give every person and agent only the tools their task needs, with their own credential.
- Gate the calls that matter. Require human approval on irreversible or high-value actions.
- Cap rate and spend. Bound how fast and how much any single agent can do.
- Audit everything. Log every call, argument, and decision against the identity that made it.
PolicyLayer does all six at one gateway. Connect the servers your agents already use, start from recommended policy, and point your client at the gateway URL. Nothing to install.
Frequently asked questions
What is AI agent security?
AI agent security is the practice of governing what an AI agent is allowed to do when it takes actions through tools, before those actions execute. Unlike model safety, which concerns what an agent says, agent security concerns what it does: the refund it issues, the branch it merges, the query it runs, the resource it deletes. The durable control point is the tool call itself, evaluated against policy at runtime, outside the model.
What is AI agent governance?
AI agent governance is the operational layer that decides which agents and people can use which tools, under which conditions, with what oversight. In practice it means per-identity scoped access, approval gates on sensitive actions, rate and spend limits, and an audit trail of every call and decision. Governance is what lets a security team answer "who did what, and was it allowed" for an autonomous system.
How do I secure AI agents in production?
Put a deterministic policy check in front of every tool call. Deny destructive and financial actions by default, scope each agent and person to only the tools their job needs, require human approval on the calls that matter, cap rate and spend so a loop cannot compound, and log every decision. Enforce it at the transport layer rather than in the prompt, so a compromised or misled agent cannot reason its way around the rule.
What is the difference between AI agent security and AI governance?
Security is the enforcement: stopping or gating a specific action at the moment it is attempted. Governance is the surrounding control: who is granted what, how approvals and audit work, how access is reviewed and revoked. PolicyLayer provides both at one point in the path: deterministic enforcement on every tool call, with the scopes, approvals, and audit trail that govern it.
How do I limit what an AI agent can do?
Route the agent through a policy gateway and give it a scoped credential that exposes only the tools its task needs. Every call is then checked against deterministic rules before it runs: deny-by-default on destructive classes, argument-level conditions, rate caps, and approval gates. The limit lives outside the agent, so it holds regardless of what the prompt, the context, or a prompt injection tells the model to do.
What is runtime security for AI agents?
Runtime security evaluates an agent's actions as they happen, rather than relying on instructions given to the model beforehand. A runtime policy layer sits in the request path between the agent and the systems it calls, inspects each tool call and its arguments, and allows, denies, rate-limits, or escalates it for approval. Because it runs outside the model's reasoning loop, the agent cannot negotiate with it.
Can prompt guardrails secure an AI agent?
Not on their own. Prompt guardrails are instructions inside the model's context, and a capable agent can be reasoned or injected around them. They reduce mistakes but do not bound a determined or manipulated agent. Transport-layer enforcement does, because the agent never sees the rule, only the allow or deny decision. Use guardrails for guidance and runtime policy for security.