The OWASP GenAI Security Project has posted Securing Agentic Applications V2, a 106-page “Builder & Defender’s Guide” for people who design, build, or assess software that plans, remembers, and calls tools. The PDF on the resource page is labelled Version 2.0, October 2026, and is released under a Creative Commons Attribution-ShareAlike 4.0 licence. The project listed the resource on 10 November. A first edition, Guide 1.0, was posted in July 2025.
The new document is part of the project’s Agentic Security Initiative. It is not a catalogue of threats. That job sits with the companion Agentic AI Threats and Mitigations list, whose T-codes this guide cites when it turns a mitigation into an architectural pattern. Governance, organisational policy, and CISO-level strategy are explicitly out of scope; the authors say those will follow in a separate Managing Agentic Risk Guide. The intended readers are intermediate to advanced developers, AI and machine-learning engineers, security architects and engineers, and technical leads.
“Where the T&M list identifies what threats exist and what mitigations are needed, this guide focuses on how to implement those mitigations technically.”
— OWASP GenAI Security Project, Securing Agentic Applications V2, section 1.3
In plain terms, V2 is the implementation companion: if the threats list says what can go wrong, this document is meant to show how a builder or defender would actually put the countermeasure into the system. A later chapter on architecture-specific controls still keeps the single-agent checklist from V1 as a reference, but says that where the two overlap, the new lifecycle guidance in section 3 is the authoritative text. A numbering note at the start of section 9 also records a table-of-contents bug in V1, where a runtime-hardening block was numbered 9.1–9.6 under a chapter still labelled 8; V2 splits deployment principles into section 8 and the concrete hardening steps into section 9.
The architectural core is a six-part model the authors call key components, or KCs, and then reuse, in the same colours, in later figures. KC1 is the generative model itself. KC2 is orchestration, or how control flows. KC3 is the reasoning and planning style (plan-and-execute, ReAct, chain of thought, and similar patterns). KC4 is memory, including the awkward cases where memory is shared across users or across agents. KC5 is the tool-integration layer. KC6 is the operational environment: APIs, code execution, databases, browsers, a desktop, or a critical-control system. The security claim that runs through that inventory is unusually blunt about the model’s place in the trust boundary.
“A probabilistic model component that interprets inputs and proposes content, plans, or actions; its output is untrusted input to deterministic orchestration, policy enforcement, and sink-side authorization.”
— OWASP GenAI Security Project, Securing Agentic Applications V2, section 2.1, on KC1
That sentence is doing a lot of work. The model is allowed to propose a plan or a tool call, but the proposal is not, by itself, permission to act. Whatever comes out of KC1 is supposed to be treated the way a system would treat any other untrusted input: checked by deterministic code, authorised at the point where something actually happens, and never treated as a source of policy. Hosted models, the same section says, should be treated as an external trust boundary, with the usual questions about retention, tenant isolation, regions, and version changes written down rather than assumed.
Three concerns then cut across all six components. They are not new building blocks; they are properties the authors say have to be designed in from the start: a control plane for instructions and policy, identity and delegation, and the risk that comes from combining capabilities.
“System prompts, developer instructions, tool descriptions, retrieved documents, memory summaries, policies, and hook logic are all control-plane inputs that shape behavior and control flow, but they are not equal in authority. Prompt roles, delimiters, and sections are provenance cues rather than security boundaries.”
— OWASP GenAI Security Project, Securing Agentic Applications V2, section 2.7.1
In everyday language: marking a block of text as a “system” message, wrapping it in tags, or putting it in a special section of the prompt may help the model tell things apart, but it does not enclose that text in a wall. The guide wants each input to carry a provenance and trust label with it, wants mail, documents, web pages, tool responses, and messages from other agents to arrive through a lower-trust path, and wants the actual policy decision kept outside the model, at the “action sink” where a tool is invoked. It also wants the live system prompt and tool definitions checked against approved hashes when a session starts, so that a later change — including a tool that quietly alters its own description after it was approved — is visible.
Identity is framed the same way: an agent should have a distinct, manageable non-human identity, and authority handed to it, or between agents, should shrink rather than linger in the background.
“A useful framing is the effective-scope relationship Effective Scope = User Permission ∩ Agent Capability ∩ Bound Intent. Delegation should use On-Behalf-Of (OBO) token exchange (never raw user credentials) with depth limits and monotonically narrowing scope at each hop, and should bind authorization to the declared user intent so that an agent does not become a ‘confused deputy’.”
— OWASP GenAI Security Project, Securing Agentic Applications V2, section 2.7.2
The formula is easier than it looks. An action is in scope only if it sits in all three sets at once: things the user is allowed to do, things this agent is actually able to do, and things this particular task was meant to do. If any one of those is missing, the action should not go through — including the case where the agent has the technical ability, and the user has the permission, but the current task never asked for that step. When a person is present and the agent needs access to something they own, the guide extends the same idea with a fourth set, consented scope, and describes an OAuth consent step in which the agent receives a short-lived token and never sees the user’s password. Where one agent must call another, each hop is supposed to get its own narrower, shorter-lived token, not a copy of the original. Section 4 later calls a signed, immutable, intent-locked task descriptor that sub-agents cannot rewrite mid-chain “the structural mitigation for the confused deputy problem.”
“Simon Willison’s “Lethal Trifecta” identifies the dangerous combination of (1) access to private or sensitive data, (2) exposure to untrusted content, and (3) the ability to communicate externally; an agent holding all three can be manipulated into exfiltrating data. Meta’s “Rule of Two” formalizes the mitigation: expose an agent to at most two of {processes untrustworthy input, accesses sensitive systems/data, communicates externally or changes state}.”
— OWASP GenAI Security Project, Securing Agentic Applications V2, section 2.7.3
The point is composition, not any single feature. A helper that can read a private inbox, look at a web page, and send a message already holds all three legs. The default advice in V2, when a design would combine them, is to take one leg away or split the work across separately authorised components with hard boundaries on what information can flow and what can leave the system. Exceptions, the authors say, need deterministic enforcement, tested controls, a named owner for the residual risk, and evidence that a human in the loop is supporting those controls rather than standing in for them.
The same caution about what a check actually proves turns up in the memory guidance. Hashing a stored memory record, or tagging it with a source and a trust level, is useful, and the guide recommends it. It also says what that hash does not do.
“Integrity checks detect unauthorized modification of a stored record; they do not prove the content is semantically safe, and they do not by themselves prevent legitimately-written-but-poisoned content (e.g., “sleeper agent” instructions) from influencing later reasoning. A cryptographically intact record can still be malicious.”
— OWASP GenAI Security Project, Securing Agentic Applications V2, section 3.1.6
If someone, or some earlier step, is allowed to write a memory entry, a later checksum will confirm that the entry was not quietly altered in storage. It will not tell you whether the contents were a planted instruction waiting for a similar question to come up later. The authors want integrity hashing paired with content checks and provenance labels, and they want retrieved memory treated as untrusted again before it can influence an action that matters.
They also split validation into two gates, because the two jobs happen at different moments. Context admission is the check before untrusted material — a user prompt, a web page, a retrieval result, a tool description, a message from another agent — is allowed into the model’s context at all. Action execution is the check before anything reaches the outside world: an API call, a database write, a sent message, a file change, a browser or operating-system command. The first gate is about not treating hostile text as if it were a trusted instruction. The second is about confirming that the action is authorised, in scope, and still matches the declared intent. For images and audio, the guide adds that running optical character recognition or speech-to-text does not sanitise the media; it only produces another untrusted representation, and a multimodal model may still see something the extractor missed.
The rest of the PDF is a lifecycle walk-through rather than a second architecture essay: design-time choices, build and deployment checks, then operations, including security hooks, behavioural circuit breakers, and a later chapter on assuring agentic applications through red teaming and behavioural tests. A supply-chain chapter covers third-party libraries, agent-generated code, agent cards and registries, and tool lifecycle controls, including integrity of tool definitions after onboarding. A long contributors list appears at the end. The document does not present itself as legal advice, and it is careful, in the opening pages, to say that examples of vendor platforms are illustrative rather than a recommended stack.
Discover more from Sulat AI & Tech News
Subscribe to get the latest posts sent to your email.
