AI agents and MCP clients increasingly invoke external tools and APIs on a user’s behalf. Doing this safely calls for a set of security functions: establishing who an agent is, what it is allowed to do, where a request came from, whether a sensitive action should proceed, and leaving an auditable trail.
This page maps that problem space — anchored to the OWASP Top 10 for Agentic Applications 2026 (ASI01–ASI10) — and shows how the building blocks we are working on fit into the larger picture. The three views below are linked: click any block, requirement or card to trace one thread across all of them.
Linked views. Click a block, requirement or card to highlight the same thread everywhere; filter by maturity on the right.
01How the pieces fit together
A single tool call from an agent passes through several security functions — verifying identity and credentials, checking authorization, validating intent and provenance, reaching a policy decision, then enforcing and recording it. Click any block to see the matching requirement and work item; the open areas at the bottom are where we are looking for collaborators.
Blue = what the agent presents · teal = our active building blocks · grey-dashed = open, welcome collaboration.
02The security requirements landscape
The same problem space, organised as twelve requirements across the request lifecycle and mapped to the OWASP ASI risks each one addresses. Click a requirement to see the security function it belongs to and our work on it.
The building blocks we are actively developing, the early-stage ones, and the open areas where contributions are most welcome. Each card links back to its place in the two figures above.
Active building blocks
Agent & MCP identity
A verifiable identity for both the calling agent and the MCP client.
ASI03 · ASI09
Credentials & lifecycle
DID / VC / VP, authorization tokens and capability VCs, issued and status-tracked.
ASI03
Trigger-source binding & confirmation
Distinguishing user-, agent- and delegated requests, with confirmation where needed.
ASI01 · ASI09
Tool authorization
Sensitive tools execute only after an explicit policy decision.
ASI02 · ASI03
Sensitive-data handling
Sensitive data is processed as ciphertext, without plaintext visibility.
ASI02 · ASI06
Early-stage
Inter-agent / MCP channel trust
End-to-end assurance of the agent-to-agent and MCP transport channel.
ASI07
Capability scoping
Both the agent's own authorization and the user-to-agent delegated authorization (the IETF analogue of user consent) — scoping authority to least-agency, not just what it can reach.
ASI03
Audit & evidence chain
A replayable record across request, verification, decision and execution.
ASI10
Open · welcome collaboration
Goal / instruction integrity
Detecting goal drift and injected instructions.
ASI01
Memory / context-poisoning defense
Provenance and integrity of memory and retrieved context.
ASI06
Runtime containment / kill-switch
Containing dangerous execution, cascading failures and rogue agents.
ASI05 · ASI08 · ASI10
3rd-party MCP attestation
Attesting and vetting external MCP servers, tools and schemas.
ASI04
04Collaborate with us
We are bringing several of these building blocks to an IETF hackathon to show how they relate within a common picture of agentic security.
We welcome collaboration
If you are working on agent identity, credentials and authorization, intent and provenance, tool-access policy, auditability — or on any of the open areas above such as memory / context-poisoning defense, runtime containment, third-party MCP attestation, or goal / instruction integrity — we would love to compare notes and build together.
The aim is not a single finished product but a shared, interoperable picture of how these security functions connect, so the community can contribute pieces that fit.
Reach out via this repository or the relevant IETF working groups.