OWASP—the one and only. Here is the newly released State of Agentic AI Security and Governance v2.01.
The document’s main point is that agentic AI security is no longer a collection of theoretical horror stories. We now have real incidents, CVEs, prompt injection, supply-chain attacks, memory poisoning, tool-calling abuse, and agents that independently do things nobody expected them to do.
Here are the key points:
Risk is no longer determined solely by how good or bad the model itself is, but by what the agent can do without human approval.
OWASP proposes assessing agents by their level of autonomy: supervised → semi-autonomous → fully autonomous.
If an agent can plan, take action, and repeat the cycle without human involvement, prompts and guardrails alone are no longer enough. What is needed:
- strict boundaries on authority;
- deterministic checkpoints and automated interruption mechanisms;
- an emergency shutdown mechanism;
- limits on execution time, the number of API calls, and compute resources;
- a separate digital identity for the agent;
- a complete log of its actions.
Prompt injection has not gone away and remains one of the fundamental problems.
The reason is architectural: to an LLM, the system prompt, user request, a document retrieved through RAG, an email, an MCP tool description, and other content ultimately become a single stream of tokens. There is still no reliable boundary between “data” and “instructions.” The strategy is therefore gradually shifting from “let’s completely prevent prompt injection” to “let’s ensure that even an agent compromised this way cannot do anything critical.”
This is where the so-called lethal trifecta fits particularly well:
- the agent has access to private data;
- it reads untrusted content;
- it can independently send data outside the system.
If all three capabilities are present at the same time, a single successful injection can potentially turn into a complete exfiltration chain.
The supply chain for AI agents has become far more interesting than an ordinary dependency in requirements.txt. Attackers can now target not only code but also:
- MCP servers;
- tool descriptions;
- skill and plugin registries;
- RAG;
- persistent memory;
- external data sources;
- other agents.
One particularly interesting class of attack is tool poisoning, in which the malicious instruction is not in executable code but, for example, in a tool’s description. A person inspects the tool and considers it legitimate, while the model reads the description and receives entirely different instructions.
Another example is an MCP rug pull: a tool appears safe and passes review today, but its description or behavior changes tomorrow. A conventional SBOM is therefore no longer sufficient. With agentic AI, you need to know not only which components are installed, but also which capabilities the agent dynamically connected at runtime, who owns them, and on whose behalf they are being used.
Digital identity is becoming the new perimeter.
OWASP distinguishes between the conventional digital identity of non-human entities and the digital identity of an agent. An API key or service account answers the question, “Is this entity allowed to connect at all?” That is not enough for an agent. You also need to understand:
- “Who launched this agent?”;
- “On whose behalf is it acting?”;
- “What task is it currently performing?”;
- “Who delegated authority to it?”;
- “Is it authorized to perform this specific action right now?”.
This leads to requirements for short-lived credentials, just-in-time authorization, cryptographic attestation, identity-chain binding, and preservation of delegation context across agents and tools. In short, giving an autonomous agent a permanent service account with broad OAuth scopes is, frankly, not a great idea.
MCP, A2A, and other agent protocols should be treated not as convenient integrations but as new trust boundaries.
If an agent can dynamically discover tools, communicate with other agents, and delegate tasks to them, new risks emerge:
- agent impersonation;
- privilege escalation;
- delegation loops;
- transitive trust;
- registry poisoning;
- tool substitution;
- lateral movement between agents.
This calls for separate authentication of agents and tools, constraints on delegation, schema validation, least privilege, end-to-end tracing, and the ability to revoke access quickly.
At the deployment level, AI safety and operational reliability are beginning to merge into a single problem.
Suppose an agent deletes a production database.
If an attacker made it do so through prompt injection, that looks like a cybersecurity incident. If the agent lost track of a constraint and deleted the database because of a reasoning error, that looks like a reliability or AI safety failure. But the architectural problem is the same: the agent had the ability to delete the production database in the first place. Therefore, the authorization model, blast-radius limitations, monitoring, and emergency shutdown mechanisms protect against both scenarios at once.
For this reason, OWASP argues that, at the deployment level, AI safety and cybersecurity can no longer be effectively managed as two independent disciplines with separate teams and incident-response processes.
Explainability is changing too.
For an agent, it is not enough to explain “why the LLM produced this answer.” You need to be able to reconstruct the entire execution trajectory:
- what input the agent received →
- what it retrieved through RAG →
- which tool it selected →
- which parameters it passed →
- what it received in return →
- how its memory and state changed →
- to whom it delegated the task →
- which policy checkpoint authorized the action.
Moreover, the chain of thought is not, in itself, evidence of the actual decision-making process. In other words, observability for agentic AI is effectively becoming part of the security architecture.
Governance also needs to operate at agent speed.
A quarterly review and a PDF risk assessment are of little help if an agent can perform several thousand actions in an hour.
What is needed is runtime monitoring, behavioral baselines, detection of deviations from the plan, automated incident classification, and shutdown mechanisms that operate within seconds.
Human involvement is not going away, but a person physically cannot review every action taken by a high-throughput autonomous agent.
The model is therefore shifting toward risk-based approval: routine actions are performed automatically, while potentially dangerous ones must be deterministically routed for approval.
The maturity model.
OWASP proposes assessing two dimensions at the same time:
- Adoption tier AT0–AT8—how sophisticated the agents you have already deployed are.
- Governance maturity level 0–4—how capable you are of governing them in the first place.
AT0 is shadow AI: for example, employees are already using ChatGPT, Claude, Gemini, browser extensions, local models, and AI tools with corporate data, while the organization has little real awareness of it.
Next come embedded assistants, agents built on low-code platforms, agents that can execute code, custom-built agents, MCP, multi-agent systems, and finally cross-organizational federated agent systems.
The logic is quite simple: if deployment complexity exceeds governance maturity, either raise the level of governance maturity or reduce the system’s autonomy.
The bottom line: agentic AI security is about far more than protecting the model itself. The more autonomy, tools, and access to real systems an agent receives, the more important architecture, authority, identity, control over the chain of actions, and the ability to stop it quickly become.
The central question is therefore gradually shifting from “How safely does our model respond?” to “What happens if the agent makes a mistake or someone manages to alter its behavior?”
And judging by the OWASP document, an organization needs to be able to answer that second question before the agent ever reaches production.