Executive summary
Every enterprise agentic AI deployment has to engineer four dimensions: agent identity and scoping, policy-as-code enforcement, audit and observability, and revocation. Each dimension is grounded in published standards work — OWASP Top 10 for Agentic Applications, NIST AI Risk Management Framework, ISO/IEC 42001, MITRE ATLAS, the IETF AI Agent Authentication and Authorization draft, RFC 9635 (GNAP), and the Model Context Protocol specification. The Whitepaper that follows walks each dimension at the depth a CTO or CISO needs to brief their engineering team.
Beyond the four dimensions sits the operational artefact NETEVO recommends every organisation operating agents at scale maintain: the Authority Register. The Authority Register is to agentic governance what a share register is to corporate governance — a continuously-maintained record of every agent's identity, the authority it holds, the systems against which that authority applies, and the controls (scoping, observability, revocation) attached to it. The closing IDC question — 'How much authority have we delegated, to which systems, under what controls?' — has a definitive answer when an Authority Register exists. The Authority Register chapter later in this document is its first public use.
This Whitepaper is for the people who design and build agentic infrastructure. If you need the procurement argument — why this is a board-level question and what AU standing obligations already require — the companion Insight covers that surface. If you need the engagement model, the AI Agent Infrastructure solution page covers that. This document covers the engineering reality between the two.
NETEVO's principal is a registered Trans-Tasman patent attorney and systems architect, architect of the Law-to-Code Methodology. The same evidentiary rigour applied to patent prosecution — define constraints precisely, defensible under examination, reproducible in practice — is applied to digital infrastructure here. The RISKflo platform at HSBC processes more than 13 million events per year with 99-plus per cent uptime over 24 months on the same event-sourced primitives this document recommends for agent infrastructure. The principal who designs the strategy is the principal who builds the platform; there is no handoff between strategy and execution.
What this Whitepaper covers
- The four-dimension architecture and where each dimension is grounded in published standards
- Agent identity and scoping — IETF AI Agent Auth, GNAP, MCP authorisation, scope-narrowing at delegation
- Policy-as-code enforcement — OPA, Cedar, Oso, and the failure modes each prevents
- Audit and observability — event sourcing as the evidentiary primitive, the IETF Agent Audit Trail draft, RISKflo precedent
- Revocation — short-lived credentials, central revocation registry, kill-switch UX
- The Authority Register — first public coining of the operational artefact
- Standards mapping — failure modes against OWASP, NIST, ISO/IEC 42001, MITRE ATLAS, CWE
- The 2026 AI agent breach pattern walked through the four-dimension model
- Reference patterns — Three-Plane Stack, Tool Registry with Proxied Access, Authority Register as operational source-of-truth
- FAQ for technical-mechanics questions
The architecture in four dimensions
Identity, policy, audit, and revocation are not a NETEVO invention. They are the natural decomposition of what every published agentic-AI standard requires. NETEVO's contribution is the synthesis and the Authority Register that holds the four together; the dimensions themselves are the consensus picture.
Agents need distinct, revocable identifiers separate from the users they represent. Scope must be narrowable per task. Credentials must be short-lived. Maps to OWASP Agentic ASI03 Identity and Privilege Abuse, NIST AI RMF GOVERN 1.4 and MAP 4.1, ISO/IEC 42001 clauses 5 and 7.5, IETF RFC 9635 (GNAP), and the IETF AI Agent Authentication and Authorization Internet-Draft.
Controls must be executable and version-controlled, not asserted in PDFs. Every agent action passes through a policy decision point; no out-of-band path exists. Maps to OWASP Agentic ASI02 Tool Misuse and ASI03 Identity and Privilege Abuse, NIST AI RMF MAP 5.1 and MANAGE 2.4, ISO/IEC 42001 clauses 6.1 and 8.1, and policy engines Open Policy Agent (Rego), AWS Cedar, and Oso.
Every agent action logged immutably with full decision context against the policy version that authorised it. The evidentiary record is the audit committee's surface. Maps to OWASP LLM02 Sensitive Information Disclosure and LLM07 System Prompt Leakage, OWASP API9 Improper Inventory Management, NIST AI RMF MEASURE 2.7, ISO/IEC 42001 clauses 9.1 and 10.2, the IETF Agent Audit Trail Internet-Draft, and Martin Fowler / Greg Young event-sourcing canon.
Every agent's access revocable in real time, from a console, by humans, without code deploys. The dimension most often missed at procurement. Maps to OWASP Agentic ASI03, OWASP API2 Broken Authentication, NIST AI RMF MANAGE 4.1 and 4.3, ISO/IEC 42001 clauses 8.4 and 10, and standard OAuth 2.0 refresh-token rotation patterns extended with a central revocation registry.
Dimension 1 — Agent identity and scoping
Why agent identity is not the same as user identity. The human-vs-agent distinction is not cosmetic. Agents have no UI; permission must be per-call. IDC's 2029 forecast (>1 billion actively deployed AI agents) puts the population at a scale where service-account patterns and user-account patterns will both fail. The standards-track answer is forming. IETF RFC 9635 (GNAP) is the published Internet Standard for grant negotiation and authorisation; it is general-purpose, not agent-specific, but the conceptual model (grant request, grant response, continuation tokens, capabilities, identifiers) is the substrate agent authentication is being built on.
The IETF AI Agent Authentication and Authorization Internet-Draft (Kasselman, Lombardo, Rosomakho, Campbell) builds on RFC 9635 and the WIMSE workload-identity work to propose unique agent identifiers, short-lived credentials, scopes specific to agent capabilities, token-forwarding anti-patterns, revocation, observability, and audit. The draft is an Internet-Draft, not a finalised RFC; drafters working against it should track the draft version (currently in active iteration) and re-validate citation freshness at publication time.
MCP authorisation patterns. The Model Context Protocol specification (Anthropic, with multi-vendor adoption — OpenAI, Microsoft, Google) describes how AI agents discover and access tools. The MCP authorisation model is OAuth 2.1-derived, with explicit security considerations naming confused-deputy attacks, token-passthrough vulnerabilities, server-side request forgery, and session hijack as primary risks. Cloudflare Agents MCP Auth ships a citable production implementation pattern with OAuth scopes mapped to MCP tool capabilities. Tetrate Agent Router provides a comparable gateway-level pattern for MCP and LLM endpoints with per-team and per-agent budgets, runtime guardrails, PII handling, and audit logging.
Scope-narrowing at delegation boundaries — Implicit Authority Cascade. The failure mode in multi-agent workflows where an upstream agent delegates a task to a downstream agent without explicitly narrowing the downstream agent's scope. The downstream agent inherits the upstream agent's full authority by default. The architectural prescription is that every delegation must produce a scope-narrowed token with an explicit allowlist of resources and operations. Confused-deputy literature dating from 1988 names the prior art; what is new in 2026 is the frequency at which delegation now happens, in production, without a designer in the loop.
Architectural prescription: agents authenticate with short-lived, scope-narrowed credentials; identity is verifiable to a central registry; every delegation produces a narrower-scope token; the Authority Register records the agent's identity, owner, authority, target systems, and policy bindings.
Dimension 2 — Policy-as-code enforcement
From PDF to executable. The procurement-failure framing extends naturally into the engineering layer: PDFs do not enforce; code does. OWASP Top 10 for Agentic Applications ASI02 Tool Misuse and Exploitation and ASI03 Identity and Privilege Abuse name the categories the enforcement layer has to defend against. NIST AI RMF MANAGE function (MANAGE 2.4 in particular) requires the implementation of controls that automate the risk responses identified in MAP. The mechanism is policy-as-code: every agent action proposed → evaluated against the policy → ALLOW, DENY, or OBLIGATE decision returned with audit context.
Open Policy Agent (OPA) and Rego. OPA decouples decisions from enforcement: the policy lives in OPA, the enforcement point sits inside the application (typically a sidecar or a library invocation). Rego is the policy language. The typical agent pattern is: agent proposes an action against a resource; the application invokes OPA with the action, agent identity, resource identifier, and request context; OPA returns ALLOW/DENY with optional obligations. General-purpose, vendor-neutral, well-suited to multi-cloud or hybrid agent deployments.
AWS Cedar and Amazon Verified Permissions. The Cedar principal-action-resource-context evaluation model is default-deny. Each policy expresses a permitted combination of principal (who), action (what), resource (against), and context (under what conditions). Amazon Verified Permissions is the managed implementation that hosts Cedar policies and serves as the policy decision point. Strong fit for AWS-native agent deployments and for organisations with existing IAM investment in the Cedar grammar.
Oso and Polar. Oso models actor-resource-role-permission relationships with the domain-rich Polar language. Where OPA and Cedar are general-purpose, Oso is domain-modelling-first — the right fit when the authorisation logic depends heavily on the modelled relationships between entities (multi-tenant SaaS, marketplaces, complex hierarchies). The decision is fit-for-purpose, not theoretical.
Where policy-as-code goes wrong. The failure modes are predictable. Policy bypass via direct API access — an agent that reaches a backend without going through the policy decision point. Policy staleness — the policy was correct when written, but the systems it governs have moved and the policy has not. Policy explosion — every team writes its own policy and the result is overlapping, contradictory, untestable. The architectural prescription against each: every agent action passes through the policy decision point with no out-of-band path; policies are tested as code in CI; one team owns the policy taxonomy and per-domain teams contribute under that taxonomy.
Architectural prescription: choose one policy engine (OPA, Cedar, or Oso) on fit grounds, not on novelty. Every agent action is mediated by a policy decision point. Policies are version-controlled in Git, tested in CI, and deployed alongside the agent infrastructure they govern. Decisions are captured in the audit log (Dimension 3) with the policy version that produced them.
Dimension 3 — Audit and observability
Event sourcing as the evidentiary primitive. Martin Fowler's 2005 essay Event Sourcing is the canonical reference: state is captured as an append-only sequence of events; state at any point in time can be reconstructed by replaying events; the event log is the source of truth and current state is a materialised view. Greg Young's CQRS and Event Sourcing materials extend the pattern with the command-query separation that makes it operationally tractable. The properties (append-only, replay-able, temporal-query-able, audit-by-construction) make event sourcing the natural primitive for agent audit.
Event-sourced autonomous agents. The 2026 arXiv preprint Event-Sourced Autonomous Agents by Filho describes a deterministic orchestration pattern: agents produce validated JSON intentions; a deterministic orchestrator turns intentions into commands; commands produce events; events are appended to a log; materialised views are reconstructed from the log; hashing and replay verification provide forensic traceability. The pattern is testable in unit tests because the orchestrator is deterministic; the agent's intentions and the deterministic transitions both fall under inspection.
The IETF Agent Audit Trail Internet-Draft. The 2026 IETF Internet-Draft on Agent Audit Trail proposes a structured field set — identity (who), action (what), outcome (result), trust (assurance level) — with SHA-256 plus RFC 8785 JSON canonicalisation for hash chaining, optional ECDSA signing for non-repudiation, and compliance mappings into OWASP, NIST, and ISO/IEC controls. The draft is at Internet-Draft status, not finalised; the architectural pattern (hash-chained immutable log with cryptographic attestation) is the durable contribution and is already widely adopted.
What the audit trail must capture for board-defensibility. The explicit field set: agent identity, requested action, resource, policy decision and policy version, input data, output data, downstream side-effects, human override (if any), timestamp, hash chain link. The clause-level mapping to ISO/IEC 42001: clause 9 (Performance evaluation — monitoring, measurement, internal audit, management review) and clause 10.2 (Continual improvement). Without this field set, the audit log is a debugging tool, not an evidentiary surface.
The RISKflo precedent (NETEVO proof point). NETEVO's RISKflo platform at HSBC processes more than 13 million events per year with 99-plus per cent correlation accuracy across the deployment. The platform is event-sourced; every action is an append-only entry; the materialised views serve the operational read-side; the event log is the audit committee surface. The same primitive applied to agent infrastructure produces the same evidentiary surface — the architecture pattern is domain-neutral.
Architectural prescription: every agent action emits an immutable event with the field set named above; the event log is append-only, hash-chained, and cryptographically signed where audit-grade non-repudiation matters; the Authority Register holds a pointer to the audit log per agent.
Dimension 4 — Revocation
Why revocation is the dimension procurement tends to miss. The Lilli pattern is instructive: writable system prompts in the database, no console to disable a specific compromised configuration quickly. McKinsey's patch went out within hours, which is fast — but the question for procurement was rehearsed before the incident, not invented during it. IDC's board-reframe captures the right question: 'can the buyer pull an agent's access from a console without waiting for a vendor deploy?' If the answer is no, the procurement is incomplete.
Short-lived credentials and rotation cadence. The OAuth 2.0 refresh-token pattern is the primitive: short-lived access tokens (typical cadence 60 minutes) backed by longer-lived refresh tokens that must be exchanged for new access tokens, with the exchange itself audited and revocable. Daily refresh-token rotation and weekly underlying-key rotation are reasonable defaults; risk-sensitive systems compress further. The point is not the specific cadence; it is that the credential's lifetime puts an upper bound on how long a compromised credential can act.
The central revocation registry. One source of truth for revocations; every agent action checks the registry on the path. Cache with short TTL (typically 30-60 seconds) to keep latency tolerable while bounding the worst-case revocation-propagation delay. The registry itself is part of the control plane and is audited like any other policy decision.
Kill-switch UX and operational requirements. One-click revocation from a console, not a database query. Every revocation event itself audit-logged with the operator's identity, the agent's identity, the reason, and the timestamp. Rehearsed in production-equivalent environments before incident — revocation that has never been tested under realistic conditions usually does not work the first time it is needed.
Architectural prescription: short-lived credentials (60-minute access tokens; daily refresh-token rotation); a central revocation registry checked on every action with a short cache TTL; a one-click kill-switch console for human operators; revocation rehearsal in production-equivalent environments quarterly at minimum.
The Authority Register
The share register equivalent for agentic governance
A continuously-maintained record of every agent operating in the enterprise: its identity, the authority it holds, the systems against which that authority applies, and the controls (scoping, observability, revocation) attached to it.
The Authority Register is to agentic governance what a share register is to corporate governance — the answer to who can do what, against what, on whose say-so.
“How much authority have we delegated, to which systems, under what controls?”
An organisation operating agents at scale either has an Authority Register, or has the IDC question hanging unanswered.
Contents of the Register
The structural fields every entry carries:
- Agent identity — unique to the platform
- Agent owner — the human accountable party
- Authority scope — the operations the agent is permitted to perform
- Target systems — the systems against which that authority applies
- Policy bindings — the policy decision points and policy versions that govern the agent
- Audit-log pointer — where the agent's action history is recorded
- Revocation contact — who pulls the agent's access in an incident
- Last-review date — the discipline cadence
Maintenance discipline
Quarterly review at minimum; automated change capture so every provision and deprovision auto-updates the register; and a board-readable summary that the audit committee actually reads.
The Authority Register is the discipline, not a tool — specific tooling is downstream of the discipline, not a substitute for it.
Standards mapping
How to read the table
Each row is a failure mode the architecture has to design against. Each column names the framework or standard in which the failure mode is recognised — OWASP categories (LLM Top 10 2025, API Top 10 2023, Agentic Top 10 2026), NIST AI Risk Management Framework 1.0 subcategories from GOVERN/MAP/MEASURE/MANAGE, ISO/IEC 42001:2023 clauses with MITRE ATLAS techniques and CWE common weaknesses where applicable. Mapped against the four-dimension deep walk earlier in this Whitepaper: identity failures sit in Dimension 1, policy failures in Dimension 2, audit failures in Dimension 3, revocation failures in Dimension 4.
What this table is for
Architectural threat modelling for an agentic AI platform. Pre-procurement: ask the vendor to demonstrate which row they design against and how. Pre-deployment: walk the table with the engineering team and capture the controls for each row in the Authority Register. Post-incident: identify the row the incident sits in and update the controls accordingly. The table is a reference, not a checklist; the architectural work is the controls each row implies.
The 2026 AI agent breach as a worked example
The McKinsey Lilli incident of March 2026 walked through the four-dimension model. Not a re-narration — a diagnosis. For each dimension, what was missing in the platform's architecture and what Agentic Due Diligence would have surfaced pre-procurement. Procurement-failure framing, not McKinsey-failure framing — McKinsey's response was textbook (alerted by the researcher, patched within hours, transparent communication); the architectural exposure is category-wide. The companion Insight covers the procurement-level argument; this section is the engineering diagnosis.
Identity (Dimension 1) — what was missing
Twenty-two endpoints out of the platform's two-hundred-plus required no authentication. CodeWall's offensive agent had no scope-narrowed credential; once one endpoint was reached, the entire platform was traversable. The Dimension 1 prescription — unique agent identifiers, short-lived credentials, scopes specific to agent capabilities — was absent. An Agentic Due Diligence pass would have asked: does every endpoint require an authenticated, scoped agent credential? The answer would have been no, and the procurement decision would have caught it.
Reference: Identity & Scoping (Dimension 1)
Policy (Dimension 2) — what was missing
JSON-key concatenation into SQL is input-validation failure at the endpoint, but the architectural fault is that no policy decision point sat between the endpoint and the database. Co-residence of user data with writable AI configuration (95 writable system prompts across 12 model types in the same database as user records) is a resource-segregation failure — the data plane and the control plane shared the same enforcement surface. The Dimension 2 prescription — every agent action passes through a policy decision point with no out-of-band path — would have caught both.
Reference: Policy-as-code (Dimension 2)
Audit (Dimension 3) — what was missing
CodeWall's report that OWASP ZAP did not detect the vulnerability is a continuous-monitoring observation. The two-plus-year vulnerability persistence (per Dream11's Rajat Rai via The Stack) implies an audit-log cadence that was not catching the relevant signal. The Dimension 3 prescription — immutable event-sourced audit with the explicit field set, replay-able for forensic traceability — would have produced the evidentiary surface needed to detect the pattern earlier.
Reference: Audit & Observability (Dimension 3)
Revocation (Dimension 4) — what was unproven
The writable system prompts were the highest-impact reachable surface. The patches went out within hours, which is fast — but the pre-incident question was whether revocation was rehearsed. The Dimension 4 prescription — short-lived credentials with daily rotation, central revocation registry, one-click console kill-switch, quarterly rehearsal — is the work that makes a fast post-incident response reliable rather than fortunate. Whether this was in place pre-incident is unverifiable from public sources; an ADD pass would have asked the question explicitly.
Reference: Revocation (Dimension 4)
What an Agentic Due Diligence engagement would have surfaced: a board-readable risk position naming the four dimensions where the platform's architecture did not meet the standards-mapped controls. The output is not 'do not buy', it is 'these are the architectural conditions on which deployment is defensible'. The engagement model is described on the AI Agent Infrastructure solution page.
Reference implementation patterns
Three patterns that recur across NETEVO's agentic AI engagements with sufficient frequency to be worth naming. A specific deployment usually combines all three. These are not a reference architecture (that is a separate, longer document); they are the recurring patterns.
Pattern A — The Three-Plane Stack
- Control plane: where authority is granted, scoped, observed, and revoked. The Authority Register lives here. Policy decision points (OPA, Cedar, Oso) live here. The revocation registry lives here.
- Data plane: where the agent operates. Tool registries, MCP servers, vendor APIs, internal business systems. Every action passes through the control plane on the way out and emits an event to the audit plane.
- Audit plane: where the evidentiary record accumulates. The event log lives here. The hash chain lives here. The audit committee surface and the regulator-facing export both reside here.
- Cross-reference: Forrester's Agent Control Planes Still Need A Robust Standards Stack observes that 'agent control planes are a third plane' and 'agent governance identity does not travel' — the Three-Plane Stack is the response to both observations.
Pattern B — Tool Registry with Proxied Access
- One central tool registry that every agent capability is discovered through.
- Access proxied through a gateway that enforces the policy decision and emits an audit event.
- Per-team or per-agent budgets, runtime guardrails, PII handling, audit logging in the gateway itself.
- Mirrors NETEVO's existing MCP Architecture deliverable on the AI Agent Infrastructure solution page.
Pattern C — Authority Register as operational source-of-truth
- The Authority Register sits inside the control plane and is queried by the policy decision point on every agent action.
- The Register answers — for this agent, against this resource, with this scope — should the action be permitted?
- The audit committee reads the Register directly as the artefact that captures the organisation's current agentic posture.
- Together with Pattern A and Pattern B, the Authority Register becomes the operational source-of-truth at the centre of the three planes.
Questions
Frequently asked questions
What is an Authority Register and how does it relate to an AI inventory?
An Authority Register is a continuously-maintained record of every agent operating in the enterprise: its identity, the authority it holds, the systems against which that authority applies, and the controls attached to it. An AI inventory lists what AI is in use; the Authority Register answers what authority each agent holds. The Authority Register is the operational artefact NETEVO recommends every organisation operating agents at scale maintain; it is the discipline that answers IDC's board-reframe question — 'How much authority have we delegated, to which systems, under what controls?' Specific tooling is downstream of the discipline. The Authority Register chapter of this Whitepaper is its first public coining.
Should we use OPA, Cedar, or Oso for AI agent policy enforcement?
All three are credible. The decision is fit-for-purpose. Open Policy Agent (Rego) is general-purpose and vendor-neutral; it is the right fit for multi-cloud or hybrid agent deployments where the same policy needs to be evaluated across heterogeneous environments. AWS Cedar with Verified Permissions is the right fit for AWS-native deployments and for organisations with existing investment in the Cedar grammar. Oso is the right fit when the authorisation logic depends heavily on the modelled relationships between entities (multi-tenant SaaS, marketplaces, complex role hierarchies). The wrong move is to pick one because of novelty; pick one because the deployment characteristics warrant it.
How do agents authenticate to MCP servers?
The Model Context Protocol authorisation model is OAuth 2.1-derived. Agents request tokens with explicit scopes mapped to MCP tool capabilities; the MCP server validates the token and the scopes on every request. Cloudflare Agents MCP Auth ships a citable production implementation pattern; the MCP specification names confused-deputy attacks, token-passthrough vulnerabilities, server-side request forgery, and session hijack as the primary security considerations. The Identity & Scoping prescription earlier in this Whitepaper applies: unique agent identifiers, short-lived credentials, scopes specific to agent capabilities, and an audit event emitted on every authorised call.
What is the IETF AI Agent Authentication and Authorization draft?
An Internet-Draft by Kasselman, Lombardo, Rosomakho, and Campbell that builds on IETF RFC 9635 (GNAP) and the WIMSE workload-identity work. It proposes unique agent identifiers, short-lived credentials, scopes specific to agent capabilities, token-forwarding anti-patterns, revocation, observability, and audit. The draft is at Internet-Draft status (not a finalised RFC); drafters and architects should track the active draft version at publication time and re-validate at each implementation milestone. The architectural model the draft describes is the model the Identity & Scoping chapter prescribes against.
What does event-sourced agent audit look like in practice?
Every agent action emits an immutable event with a structured field set: agent identity, requested action, resource, policy decision and policy version, input data, output data, downstream side-effects, human override (if any), timestamp, and hash-chain link to the previous event. The event log is append-only; current state is a materialised view over the log; replay is the forensic verification mechanism. NETEVO's RISKflo platform at HSBC processes more than 13 million events per year on this primitive with 99-plus per cent correlation accuracy. The same primitive applied to agent infrastructure produces the same evidentiary surface.
How short should agent credential lifetimes be?
Defaults: 60-minute access tokens, daily refresh-token rotation, weekly underlying-key rotation. Risk-sensitive systems compress further (15-minute access tokens, hourly refresh-token rotation). The specific cadence matters less than the principle: a credential's lifetime puts an upper bound on how long a compromised credential can act, and the upper bound has to be tolerable for the operational risk profile. Pair short-lived credentials with the central revocation registry from the Revocation chapter so that even within the lifetime window, immediate revocation is available.
What is the difference between agent identity and service-account identity?
Service accounts are identifiers that humans use to grant non-human systems access to other systems; the access is usually long-lived and broadly scoped. Agent identity in the IETF AI Agent Auth draft model is per-agent, short-lived, scoped to specific capabilities, and revocable. The architectural distinction is that service-account identity ages well in the SaaS era because the systems it accessed were UI-mediated; agent identity has to be designed for the API-mediated agentic era. Conflating the two is the most common identity failure observed in 2026 agentic deployments.
Does ISO/IEC 42001 require an Authority Register?
ISO/IEC 42001:2023 requires an AI management system that delivers operational planning and control (clause 8), performance evaluation including monitoring, measurement, and internal audit (clause 9), and continual improvement (clause 10). An Authority Register satisfies the operational-planning and audit requirements by providing the organisation-wide record of agent authority, scoping, observability, and revocation that the standard's controls assume exists. Whether your specific deployment meets your specific obligations under the standard is a question for your AIMS implementation team and your certification auditor; NETEVO encodes the obligations identified by counsel or compliance into executable controls and does not interpret which obligations attach to which facts.
What is the OWASP Top 10 for Agentic Applications?
The OWASP Top 10 for Agentic Applications was published in 2026 and complements the earlier OWASP Top 10 for Large Language Model Applications and the OWASP API Security Top 10. It identifies the most significant security risks in agentic AI systems — ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI06 Memory and Context Poisoning, and others. The standards mapping table in this Whitepaper maps each failure mode to the relevant OWASP categories along with NIST AI RMF subcategories, ISO/IEC 42001 clauses, MITRE ATLAS techniques, and CWE entries.
How does Zero Trust apply to autonomous agents?
Zero Trust principles — never trust by default, verify continuously, scope minimally, monitor everything — extend naturally to autonomous agents. Concretely: every agent action is authenticated (Dimension 1), authorised against a policy (Dimension 2), captured in an audit event (Dimension 3), and bounded by short-lived credentials with central revocation (Dimension 4). The agent has no implicit network position, no implicit authority over resources it has not been explicitly scoped to, and no implicit persistence beyond its credential lifetime. Zero Trust for agents is not a new framework on top of the four dimensions; it is the philosophical shorthand for the architectural prescriptions of the four dimensions.
What is the relationship between this Whitepaper and the Agentic Procurement Failure Insight?
The Agentic Procurement Failure Insight is the procurement-architecture argument for boards, CEOs, heads of procurement, and CTOs at strategic level. It explains why this is a procurement question, what standing AU obligations already require, and where Agentic Due Diligence sits in the procurement cycle. This Whitepaper is the engineering depth artefact for CTOs, CISOs, and Lead Architects. It assumes the procurement argument and builds the implementation blueprint on top of it. Readers needing both surfaces typically read the Insight first, then this document, then book a discovery call with NETEVO.
Discuss this architecture
If your team is sitting on the post-Lilli decision about how to deploy autonomous agents in your enterprise, a short call covers the four-dimension model, the standards mapping that applies to your context, and what Agentic Due Diligence would look like for the specific vendor or platform you are evaluating.