Your board told you to adopt AI agents. You are the one accountable for making sure they do not become the next incident. The problem is that an autonomous agent is not a user and not an application. It decides its own next step, calls tools, and reaches into systems and data on its own, and it usually does so with the full access of the person it is acting for rather than the narrow access its task actually needs. OWASP now treats this as a formal risk category, naming excessive agency and uncontrolled autonomy among the risks in its Top 10 for Agentic Applications.
The tooling to control all this is fragmenting fast, and no single product covers the whole problem. Some tools guard the prompt, some watch behavior, some discover shadow agents, some hand agents an identity, and some decide what an agent is actually allowed to do.
This guide breaks the AI agent security and governance stack into the layers you actually need, names the notable tools in each, and shows which layer most teams skip. It is the one that decides what an agent may do, and it is the one auditors ask about.
What makes AI agents hard to secure
Three things break the assumptions your existing controls were built on.
An agent acts on its own. A traditional app does what its code says, but an agent chooses which tool to call and when, so the risk is not a bug in a fixed path, it is an action nobody predicted. This is what OWASP means by excessive agency.
An agent usually has no identity of its own. It runs with the credentials of the person who started it, so every system it touches sees that person and not the agent. It inherits everything that person is allowed to do, which is almost always far more than the task in front of it needs, and nothing in the logs separates what the human did from what the agent did. Giving agents an identity of their own, and evaluating it alongside the human's, is what makes them governable.
An agent follows access, not instructions. It is bounded by the credentials it holds, not by the wording of its prompt, so an instruction like do not touch production is a request it can ignore, misread, or be talked out of by a prompt injection. If the credentials allow the action, the action is possible.
Most security investment for agents goes to the model surface, the prompts and the outputs. That matters, but the layer that decides what an authenticated agent is allowed to do, the authorization layer, is where control silently goes missing. Keep that in mind as you read the categories below.
The layers of AI agent security and governance
1. Prompt and input security
This layer defends the model's inputs against prompt injection and jailbreaks, the manipulation attacks that trick an agent into ignoring its instructions. Notable tools include Lakera, Prompt Security (part of SentinelOne), and Aim Security. Think of it as filtering what goes into the model, not what the agent is allowed to do once it acts.
2. Guardrails and behavior control
Guardrails constrain what the model can output and, for agents, which actions are even on the table. NVIDIA NeMo Guardrails and Guardrails AI are common here. These are useful for keeping an agent inside a lane, but they live at the model layer and are enforced by the agent framework, so they are guidance rather than an independent control on access.
3. AI posture and shadow-agent discovery
You cannot govern what you cannot see, and agents are being spun up faster than security teams can track. This layer, sometimes called AI security posture management, finds and inventories the agents, models, and AI usage across your environment, including shadow AI that no one registered. Wiz AI-SPM, Palo Alto Prisma AIRS, and Zenity work here, and Microsoft has released an open-source Agent Governance Toolkit for runtime agent security. Discovery is the prerequisite for everything else.
4. Agent identity and secrets
Once you know an agent exists, it needs an identity of its own. Most agents start out borrowing the credentials of the user who ran them, which is exactly what makes them impossible to govern separately, so the work here is giving each one a managed identity, an owner, and credentials that get rotated rather than left in a config file.
This is the non-human identity layer, and tools like Astrix Security, Entro, and Oasis Security focus on discovering agent and workload identities, mapping their access, and managing their secrets. Identity answers who the agent is. It does not answer what the agent may do, which is the next layer.
5. Authorization and access control for agents
This is the control that decides, at the moment an agent tries to act, whether it is allowed to. It is the direct answer to OWASP's excessive agency and uncontrolled autonomy, and it is the layer most agent-security stacks skip. Cerbos sits here, as the policy-based authorization layer for agents.
A few things make this layer different from the rest. The check happens per action, not once per session, so an agent is authorized for each tool call rather than handed a broad grant up front.
It gates Model Context Protocol (MCP) tool calls directly, the protocol agents use to invoke tools, where the action is the tool name, a policy can block a tool outright or restrict it to certain paths, and the deny reason is handed back to the agent.
It evaluates the agent and the human behind it together, so the delegating user's permissions become the ceiling and the agent's own policy scopes it below that, instead of the agent simply inheriting everything the person can do.
And it starts in an observe-then-enforce mode, watching what agents actually do before you write restrictive policies, which is how you roll this out without breaking legitimate work.
Cerbos runs this same engine for AI coding agents through a Claude Code hook that checks every tool use, and it is the enforcement side of the governance model we have written about for agents. Every decision is logged with an id, which is what turns "the agent did something" into an audit record.
6. Data access and RAG protection
Agents read data, often through retrieval-augmented generation, and the risk is that an agent surfaces data the underlying user was never allowed to see. Two things help.
Sensitive-data tools like Protecto and Nightfall strip or mask regulated data before it reaches the model.
And authorization-aware retrieval, which Cerbos provides for RAG pipelines, filters the vector store at query time so the agent only retrieves the records the requesting user is permitted to access, rather than filtering after the fact.
7. Runtime monitoring and threat detection
The last layer watches agent behavior in production and flags anomalies, an agent calling tools it never used before, or moving in a way a baseline would not predict. CrowdStrike, Zenity, and WitnessAI operate here. Monitoring tells you when something went wrong. The layers above are what stop it.
How the layers fit together
None of these layers replaces another, and the mistake is assuming one product covers the stack.
| Layer | What it does |
|---|---|
| Identity | Establishes who the agent is and who it acts for. |
| Authorization | Decides, per action, what it may do, and produces the record of every decision. |
| Prompt security and guardrails | Handle the model's inputs and outputs. |
| Posture and monitoring | Give you visibility, before deployment and during it. |
| Data protection | Controls what the agent can retrieve |
Two of these map directly to what an auditor will ask and to what regulators now require. The EU AI Act, Regulation (EU) 2024/1689, requires event logging for high-risk AI under Article 12 and human oversight under Article 14, and the NIST AI Risk Management Framework sets out the govern, map, measure, and manage functions you will be measured against. Logging and human oversight are the authorization layer's job. Knowing what every agent can access is the identity layer's job. Those are the two an audit will press on hardest.
Source: NIST AI Risk Management Framework
How to prioritize
You will not stand up seven categories at once, so sequence by risk and by what you will have to prove.
Start with the two layers that map to OWASP's top agentic risks and to the questions an auditor asks.
Give every agent a managed identity with an owner and the least access it needs, and put an authorization layer in front of what it does, tied to the human behind it, logging every decision. Those two directly address excessive agency and uncontrolled autonomy, and they produce the evidence Article 12 and Article 14 expect.
Add prompt security and guardrails next, to protect the model surface, since a prompt-injected agent with tight authorization can do far less damage than one with broad access. Then layer in posture and monitoring for visibility across your growing fleet of agents. Data protection comes in wherever agents touch regulated data.
The through-line is that authentication and prompt filtering get most of the attention, while authorization, the control that actually limits what an agent can do and creates the audit trail, is the one most often missing. It is also the one that scales, since the same policy engine can govern human users, service accounts, and agents together rather than as separate systems.
Getting started
The agent security stack is layered, and the fastest way to close the gap most teams have is to make what your agents are allowed to do an explicit, logged decision rather than an implicit grant. If you want to see that layer in practice, our writeups on dynamic authorization for MCP servers and fine-grained authorization are the place to start.
Try Cerbos to put a policy-based authorization layer in front of your agents, or book a call to talk through your agent governance with the team.
Go deeper:
- Securing MCP servers (Webinar) for the controls behind governing agent access
- Securing AI agents and non-human identities (eBook) for the identity and permissions side
FAQ
Tagged in
