{ "meta": { "kit": "ledger-kit", "buildDate": "2026-09-15", "lastVerified": "2026-09-15", "license": "CC BY 4.0", "licenseUrl": "https://creativecommons.org/licenses/by/4.0/", "cadence": "weekly, every Monday, and the same day for any NIST, IETF or MCP publication", "note": "Five verdicts carry every row. Verified means the document was fetched at its own publisher on the date given. Reported means a reliable secondary carries it and the primary could not be reached, so the row carries no primary source and is never printed as verified. Announced means a body said it will act and no document exists yet. Absent means the ledger searched and found nothing, and the search itself is written into the record. Open means a question nobody has settled, posed here and not answered.", "vocab": { "idPrefix": "AAL", "root": "/tools/agent-authority-ledger", "title": "The Agent Authority Ledger", "short": "Agent Authority Ledger", "claim": "Every standard, protocol, draft, law, guidance and open question that decides how an AI agent is identified, authorized, limited, logged and revoked. Each row a verdict about a document, dated and sourced.", "changesHeading": "For a team deploying an agent", "kinds": [ { "key": "standard", "label": "Standard or protocol", "question": "What is settled?" }, { "key": "draft", "label": "Draft in progress", "question": "What is being written?" }, { "key": "guidance", "label": "Guidance", "question": "What do regulators and security bodies advise?" }, { "key": "law", "label": "Binding law", "question": "What binds an agent's operator today?" }, { "key": "question", "label": "Open question", "question": "What has nobody settled?" } ], "jurisdictions": [ { "code": "US", "name": "United States" }, { "code": "EU", "name": "European Union" }, { "code": "UK", "name": "United Kingdom" }, { "code": "IN", "name": "India" }, { "code": "SG", "name": "Singapore" }, { "code": "GLOBAL", "name": "Global" } ], "facets": [ { "key": "identity", "label": "Identity" }, { "key": "authorization", "label": "Authorization" }, { "key": "delegation", "label": "Delegation" }, { "key": "limits", "label": "Limits" }, { "key": "human_approval", "label": "Human approval" }, { "key": "logging", "label": "Logging and audit" }, { "key": "revocation", "label": "Revocation" }, { "key": "accountability", "label": "Accountability" } ] }, "source": "https://www.gage.academy/tools/agent-authority-ledger", "attribution": "GAGE (Global Academy of Generative-AI Education), Agent Authority Ledger", "documentation": "https://www.gage.academy/tools/agent-authority-ledger/data", "methodology": "https://www.gage.academy/tools/agent-authority-ledger/method" }, "records": [ { "id": "AAL-2026-0001", "slug": "nist-concept-paper-software-and-ai-agent-identity-and-authorization", "title": "NIST concept paper on software and AI agent identity and authorization", "kind": "draft", "verdict": "verified", "jurisdiction": "US", "answer": "NIST's National Cybersecurity Center of Excellence published a concept paper on 5 February 2026 asking whether existing identity standards can carry AI agents. It proposes a laboratory demonstration applying identification and authorization controls to agents in enterprise settings, and it invited public comment until 2 April 2026. It is a proposal for a project, not a control an auditor can test.", "key_facts": [ "The paper is titled Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization.", "Its named authors are Harold Booth, William Fisher, Ryan Galluzzo and Joshua Roberts of NIST.", "NIST writes that AI agents are software systems that use data and algorithms to autonomously perform tasks.", "The paper asks for feedback on use cases, challenges, standards and technologies, and the comment window closed on 2 April 2026.", "Nothing in the paper is normative: it describes work NIST may do in its own labs with commercially available technology." ], "facets": [ { "key": "identity", "value": "The paper treats an agent as a distinct digital actor that needs its own identification, rather than borrowing a human user's identity.", "verdict": "verified", "source": 0 }, { "key": "authorization", "value": "It proposes applying existing authorization controls to agents given access to data sets, tools and applications.", "verdict": "verified", "source": 0 } ], "what_it_changes": "Read this as the direction of travel, not a requirement. If you are deploying an agent inside a United States enterprise, the message is that the identity stack you already run is the stack NIST expects you to stretch over agents, so the practical work is naming each agent in your directory and scoping its authorization, not waiting for a new protocol to arrive.", "sources": [ { "name": "NIST Computer Security Resource Center", "url": "https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd", "type": "primary", "date": "2026-02-05" } ], "related_ids": [ "AAL-2026-0002", "AAL-2026-0003", "AAL-2026-0028" ], "tags": [ "nist", "identity", "authorization", "concept paper" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0002", "slug": "nist-ai-agent-standards-initiative", "title": "NIST AI Agent Standards Initiative", "kind": "guidance", "verdict": "verified", "jurisdiction": "US", "answer": "NIST runs a programme to push technical standards and open protocols for AI agents. Its own page says the aim is an ecosystem where agents act securely for users and interoperate. The programme has gathered input through a request for information on agent security, the identity concept paper, and listening sessions on barriers to adoption.", "key_facts": [ "NIST states it aims to catalyze an ecosystem where agents function securely on behalf of users and interoperate smoothly across the digital landscape.", "The approach is explicitly industry led: NIST convenes and documents rather than regulating.", "The page names a request for information on AI agent security, the draft concept paper on agent identity and authorization, and listening sessions for healthcare, finance and education.", "The initiative page was published on 17 February 2026 and last updated on 14 August 2026." ], "facets": [ { "key": "identity", "value": "Agent identity is one of the two named workstreams, carried by the concept paper on software and AI agent identity and authorization.", "verdict": "verified", "source": 0 }, { "key": "accountability", "value": "The initiative frames agents as acting on behalf of users, which keeps the user or the deploying organisation as the accountable party.", "verdict": "verified", "source": 0 } ], "what_it_changes": "This is where a United States team should watch for the control language that will eventually land in procurement questionnaires. Nothing here is enforceable, so treat it as an early warning system: the dimensions NIST is collecting evidence on are the dimensions your agent inventory should already record.", "sources": [ { "name": "NIST", "url": "https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative", "type": "primary", "date": "2026-08-14" } ], "related_ids": [ "AAL-2026-0001", "AAL-2026-0028" ], "tags": [ "nist", "standards", "agent security" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0003", "slug": "nist-sp-800-63-4-digital-identity-guidelines", "title": "NIST SP 800-63-4 Digital Identity Guidelines", "kind": "standard", "verdict": "verified", "jurisdiction": "US", "answer": "The United States identity baseline sets assurance levels for enrolment, authentication and federation across online services. It is the document an agent identity scheme has to build on, and it is also the document that explains why agents do not fit: it says that for this publication person refers only to natural persons, and it excludes machine to machine authentication from its scope.", "key_facts": [ "The guidelines apply to all online services for which some level of assurance in a digital identity is required, regardless of the constituency.", "The publication states that for this publication, person refers only to natural persons.", "It says it does not address machine to machine authentication, interconnected devices such as Internet of Things devices, or access to Application Programming Interfaces.", "AI agents are not named anywhere in the guidelines." ], "facets": [ { "key": "identity", "value": "It defines identity assurance, authenticator assurance and federation assurance levels for people, which is the vocabulary any agent scheme will be measured against.", "verdict": "verified", "source": 0 }, { "key": "delegation", "value": "The guidelines do not cover a non human actor holding or exercising a person's authority, and they exclude machine to machine authentication from scope.", "verdict": "absent", "source": 0 } ], "what_it_changes": "If somebody tells you their agent is compliant with the federal identity guidelines, ask which clause. The guidelines govern how a person proves who they are, not how software acts for that person, so the assurance level of your human sign in says nothing about what the agent it launched is allowed to do.", "sources": [ { "name": "NIST SP 800-63-4", "url": "https://pages.nist.gov/800-63-4/sp800-63.html", "type": "primary", "date": "2025-08-26" } ], "related_ids": [ "AAL-2026-0001", "AAL-2026-0032" ], "tags": [ "nist", "identity", "assurance", "baseline" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0004", "slug": "model-context-protocol-authorization", "title": "Model Context Protocol authorization", "kind": "standard", "verdict": "verified", "jurisdiction": "GLOBAL", "answer": "The authorization section of the Model Context Protocol is the closest thing agent tooling has to a settled access rule. An MCP server is an OAuth resource server, a client is an OAuth client, and a token must be issued for the server it is presented to. The specification is explicit that a server must not accept or transit any other token.", "key_facts": [ "Authorization servers must implement OAuth 2.1 with appropriate security measures for both confidential and public clients.", "MCP servers must implement OAuth 2.0 Protected Resource Metadata (RFC 9728) and clients must use it for authorization server discovery.", "MCP clients must implement Resource Indicators for OAuth 2.0 (RFC 8707) and must send the resource parameter in both authorization and token requests.", "MCP servers must validate that access tokens were issued specifically for them as the intended audience, and must not accept or transit any other tokens.", "Authorization is optional for MCP implementations; a stdio server is told to take credentials from the environment instead." ], "facets": [ { "key": "identity", "value": "The client is identified to the authorization server by a client id obtained through Client ID Metadata Documents, pre registration or dynamic registration.", "verdict": "verified", "source": 1 }, { "key": "authorization", "value": "Access is an OAuth access token bound by audience to one named MCP server, and a server must reject anything else.", "verdict": "verified", "source": 0 }, { "key": "limits", "value": "Scope is the limit. Servers should name the scopes needed in the WWW-Authenticate challenge and clients should request only those, escalating through a step up flow.", "verdict": "verified", "source": 1 }, { "key": "delegation", "value": "The specification carries a resource owner's authority to one client and one server. It defines no chain, so a sub agent's authority is outside it.", "verdict": "absent", "source": 1 } ], "what_it_changes": "If your agent reaches tools over MCP, this is the clause your security review should cite. Two questions settle most of it: does every token your server accepts name your server in its audience, and does your client request the narrowest scope the server challenged for. A yes to both removes the two failure modes that produced the worst MCP incidents.", "sources": [ { "name": "Model Context Protocol specification 2025-06-18, Authorization", "url": "https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization", "type": "primary", "date": "2025-06-18" }, { "name": "Model Context Protocol specification 2026-07-28, Authorization", "url": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization", "type": "primary", "date": "2026-07-28" } ], "related_ids": [ "AAL-2026-0005", "AAL-2026-0006", "AAL-2026-0008", "AAL-2026-0009" ], "tags": [ "mcp", "oauth", "authorization", "tokens" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0005", "slug": "model-context-protocol-security-best-practices", "title": "Model Context Protocol security best practices", "kind": "guidance", "verdict": "verified", "jurisdiction": "GLOBAL", "answer": "The companion security document names the attacks that break agent authority in practice: the confused deputy, token passthrough, session hijacking, server side request forgery, local server compromise and over broad scopes. Its mitigations are normative. The sharpest is a flat prohibition: an MCP server must not accept any token that was not issued for it.", "key_facts": [ "Token passthrough is an anti pattern where a server accepts a token from a client without validating it was issued to that server, and the document forbids it.", "MCP proxy servers using a static client id must implement per client consent before forwarding a user to a third party authorization server.", "MCP servers that implement authorization must verify all inbound requests, and must not use sessions for authentication.", "Session identifiers must be secure and non deterministic, and should be bound to user specific information.", "The scope minimization section warns that publishing every scope in scopes_supported hands a stolen token the whole surface." ], "facets": [ { "key": "authorization", "value": "Audience validation is the control: a token that does not name this server is refused rather than forwarded.", "verdict": "verified", "source": 0 }, { "key": "human_approval", "value": "A proxy must show its own consent page naming the client, the third party scopes and the redirect URI before any third party authorization begins.", "verdict": "verified", "source": 0 }, { "key": "limits", "value": "Least privilege is spelled out: start from a minimal scope set and elevate through targeted challenges rather than granting a full catalogue up front.", "verdict": "verified", "source": 0 }, { "key": "logging", "value": "The document argues token passthrough destroys the audit trail, because downstream logs then show a different identity from the server that actually forwarded the call.", "verdict": "verified", "source": 0 }, { "key": "accountability", "value": "Identifying which client made which call is named as a reason to refuse opaque upstream tokens.", "verdict": "verified", "source": 0 } ], "what_it_changes": "This is the checklist for anyone standing up an MCP server. Three findings account for most real damage: a server that forwards a token it did not mint, a proxy with no consent screen of its own, and a session id treated as proof of identity. Each has a one line test and each has a named mitigation here.", "sources": [ { "name": "Model Context Protocol, Security Best Practices", "url": "https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices", "type": "primary", "date": "2025-06-18" } ], "related_ids": [ "AAL-2026-0004", "AAL-2026-0006", "AAL-2026-0016" ], "tags": [ "mcp", "security", "confused deputy", "session hijacking" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0006", "slug": "mcp-2026-07-28-authorization-hardening", "title": "MCP 2026-07-28 authorization hardening", "kind": "standard", "verdict": "verified", "jurisdiction": "GLOBAL", "answer": "The July 2026 revision of the Model Context Protocol tightened who a client is and who it is talking to. Clients must validate the issuer returned with an authorization code, credentials are bound to the issuer that minted them, and dynamic client registration is deprecated in favour of Client ID Metadata Documents, an HTTPS URL that serves the client's own metadata.", "key_facts": [ "The release post states that authorization servers should return the iss parameter per RFC 9207, and clients must validate it before redeeming a code.", "It states that client credentials are bound to the issuer that minted them, with no reuse across authorization servers.", "It states that Dynamic Client Registration is now formally deprecated in favor of Client ID Metadata Documents.", "Clients set application_type during dynamic client registration so authorization servers stop rejecting localhost redirects for desktop and command line apps.", "The specification keeps RFC 9728 protected resource metadata as a must for servers and adds OpenID Connect Discovery as an accepted discovery mechanism." ], "facets": [ { "key": "identity", "value": "A client identifies itself by an HTTPS URL that resolves to its own metadata document, so the client's identity is fetched rather than self asserted at registration time.", "verdict": "verified", "source": 1 }, { "key": "authorization", "value": "The issuer of the authorization response must be recorded and compared before the code is redeemed, which closes the mix up attack.", "verdict": "verified", "source": 1 }, { "key": "limits", "value": "Scope challenges are authoritative for the current operation, and clients union previously granted scopes rather than losing them on a step up.", "verdict": "verified", "source": 1 } ], "what_it_changes": "If you pinned an MCP client to the 2025 revision, the upgrade is not cosmetic. Two behaviours are new work: validating the issuer on every authorization response, and moving off dynamic client registration to a metadata document you host. Both reduce the chance that your agent hands a code or a credential to the wrong authorization server.", "sources": [ { "name": "Model Context Protocol blog, 2026-07-28 release", "url": "https://blog.modelcontextprotocol.io/posts/2026-07-28/", "type": "primary", "date": "2026-07-28" }, { "name": "Model Context Protocol specification 2026-07-28, Authorization", "url": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization", "type": "primary", "date": "2026-07-28" } ], "related_ids": [ "AAL-2026-0004", "AAL-2026-0005", "AAL-2026-0011" ], "tags": [ "mcp", "oauth", "client identity", "rfc 9207" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0007", "slug": "rfc-6749-oauth-2-0-authorization-framework", "title": "RFC 6749, the OAuth 2.0 authorization framework", "kind": "standard", "verdict": "verified", "jurisdiction": "GLOBAL", "answer": "Published in October 2012, this is the grammar every agent authority scheme still speaks. It lets a third party application obtain limited access to a service on behalf of a resource owner, by arranging an approval interaction rather than handing over the owner's password. Agent authorization in 2026 is mostly this framework with narrower audiences.", "key_facts": [ "The framework enables a third party application to obtain limited access to an HTTP service on behalf of a resource owner, or on its own behalf.", "It separates the resource owner, the client, the authorization server and the resource server, which is the separation every agent scheme reuses.", "It is a framework rather than a protocol, which is why later documents such as RFC 8707 and the OAuth 2.1 draft exist to close its options.", "The client credentials grant it defines is the path most autonomous agents take when no human is present." ], "facets": [ { "key": "authorization", "value": "Access is a scoped token issued by an authorization server, never the resource owner's own credential.", "verdict": "verified", "source": 0 }, { "key": "delegation", "value": "A resource owner approving a client is delegation, but the framework models one hop only and says nothing about an agent that calls another agent.", "verdict": "absent", "source": 0 } ], "what_it_changes": "Your agent almost certainly holds an OAuth token. That means the questions an auditor will ask are old ones: which grant, which scopes, which audience, how long lived, and who can revoke it. If your team cannot answer those for the agent, the agent has no authorization story at all.", "sources": [ { "name": "RFC Editor, RFC 6749", "url": "https://www.rfc-editor.org/rfc/rfc6749.html", "type": "primary", "date": "2012-10-01" } ], "related_ids": [ "AAL-2026-0008", "AAL-2026-0012", "AAL-2026-0004" ], "tags": [ "oauth", "authorization", "foundation" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0008", "slug": "rfc-8707-resource-indicators-for-oauth-2-0", "title": "RFC 8707, resource indicators for OAuth 2.0", "kind": "standard", "verdict": "verified", "jurisdiction": "GLOBAL", "answer": "Published in February 2020, this short extension is what stops an agent's token from being a skeleton key. It adds a resource parameter so a client says which protected resource it wants access to, letting the authorization server mint a token bound to that audience. The Model Context Protocol makes sending it mandatory.", "key_facts": [ "The document defines request parameters that let a client signal to an authorization server the identity of the protected resources it is requesting access to.", "Binding a token to a named resource is the control that makes token passthrough detectable at the receiving server.", "MCP clients must send the resource parameter in both authorization and token requests, and must send it whether or not the authorization server supports it.", "The canonical value is the resource's own URI, so the audience is a name a server can compare itself against." ], "facets": [ { "key": "authorization", "value": "The token carries the name of the resource it is for, so a second resource can refuse it.", "verdict": "verified", "source": 0 }, { "key": "limits", "value": "Audience is a limit on reach rather than on action: it bounds where a stolen token works, not what it may do there.", "verdict": "verified", "source": 0 } ], "what_it_changes": "One parameter removes a whole class of lateral movement. If your agent obtains one broad token and presents it to several services, any one of those services can replay it against the others. Sending the resource indicator and validating the audience on receipt turns that into a rejected request.", "sources": [ { "name": "RFC Editor, RFC 8707", "url": "https://www.rfc-editor.org/rfc/rfc8707.html", "type": "primary", "date": "2020-02-01" } ], "related_ids": [ "AAL-2026-0004", "AAL-2026-0005", "AAL-2026-0007" ], "tags": [ "oauth", "audience", "tokens" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0009", "slug": "rfc-9728-oauth-2-0-protected-resource-metadata", "title": "RFC 9728, OAuth 2.0 protected resource metadata", "kind": "standard", "verdict": "verified", "jurisdiction": "GLOBAL", "answer": "Published in April 2025, this defines a metadata document a protected resource publishes so a client can discover how to talk to it, including which authorization servers it trusts. It is the discovery leg of agent authorization: an agent meeting an unfamiliar server learns where to get a token instead of guessing.", "key_facts": [ "The specification defines a metadata format an OAuth client or authorization server can use to obtain the information needed to interact with a protected resource.", "MCP servers must implement it, and MCP clients must use it for authorization server discovery.", "The metadata is reached from a WWW-Authenticate header on a 401 response, so discovery starts from a refusal.", "Section 7.7 of the document is the basis for blocking private and reserved address ranges when fetching discovery URLs." ], "facets": [ { "key": "authorization", "value": "It tells a client which authorization servers a resource accepts tokens from, which is the first decision in any agent to tool handshake.", "verdict": "verified", "source": 0 }, { "key": "identity", "value": "The resource names itself in its own metadata, giving the client a canonical identifier to bind a token to.", "verdict": "verified", "source": 0 } ], "what_it_changes": "This is what lets an agent connect to a tool nobody pre configured. It is also a server side request forgery surface, because the agent is fetching URLs a remote server chose. Require HTTPS, block private ranges, and validate redirect targets before your client follows anything it discovered.", "sources": [ { "name": "RFC Editor, RFC 9728", "url": "https://www.rfc-editor.org/rfc/rfc9728.html", "type": "primary", "date": "2025-04-01" } ], "related_ids": [ "AAL-2026-0004", "AAL-2026-0005" ], "tags": [ "oauth", "discovery", "metadata" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0010", "slug": "rfc-8693-oauth-2-0-token-exchange", "title": "RFC 8693, OAuth 2.0 token exchange", "kind": "standard", "verdict": "verified", "jurisdiction": "GLOBAL", "answer": "Published in January 2020, token exchange is the only widely deployed standard that writes down the difference between impersonation and delegation. A service can trade one token for another, and the result can record that one party is acting for another rather than pretending to be them. It is the nearest thing to an agent delegation record.", "key_facts": [ "The specification defines how to request and obtain security tokens from OAuth 2.0 authorization servers, including tokens employing impersonation and delegation.", "Delegation keeps the acting party visible in the token, while impersonation erases it, and the difference decides what a downstream log can show.", "Token exchange is how a service holding a user's token obtains a narrower token for a downstream call, which is the shape of an agent calling a tool.", "It was written for services rather than agents, so nothing in it bounds how many times authority may be exchanged onward." ], "facets": [ { "key": "delegation", "value": "The exchange can record an acting party alongside the subject, so a downstream service can see that software acted for a person.", "verdict": "verified", "source": 0 }, { "key": "accountability", "value": "Because the actor stays in the token, an audit can attribute the call to both the agent and the principal instead of only one.", "verdict": "verified", "source": 0 }, { "key": "limits", "value": "The exchanged token can be narrowed by audience and scope, but the specification does not require narrowing.", "verdict": "verified", "source": 0 } ], "what_it_changes": "If your agent calls downstream services with the same token it received, your logs cannot distinguish the agent from the user. Exchanging for a narrower token that names the agent as the actor costs one round trip and gives you an attributable trail, which is what every incident review will ask for.", "sources": [ { "name": "RFC Editor, RFC 8693", "url": "https://www.rfc-editor.org/rfc/rfc8693.html", "type": "primary", "date": "2020-01-01" } ], "related_ids": [ "AAL-2026-0013", "AAL-2026-0033", "AAL-2026-0007" ], "tags": [ "oauth", "delegation", "impersonation" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0011", "slug": "rfc-7591-oauth-2-0-dynamic-client-registration", "title": "RFC 7591, OAuth 2.0 dynamic client registration", "kind": "standard", "verdict": "verified", "jurisdiction": "GLOBAL", "answer": "Published in July 2015, this lets a client register itself with an authorization server and receive credentials without a human filling in a form. It is how agent tooling connects to servers nobody pre arranged, and it is also the mechanism the confused deputy attack abuses. The July 2026 MCP revision deprecates it.", "key_facts": [ "The specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers.", "MCP originally recommended it so clients could connect to servers they did not know in advance.", "The MCP security guidance shows an attacker registering a client with an attacker controlled redirect URI to harvest an authorization code.", "The MCP specification of 28 July 2026 marks dynamic client registration deprecated and retained only for backwards compatibility." ], "facets": [ { "key": "identity", "value": "A client identity can be created on demand, which means an identifier alone proves nothing about who is behind it.", "verdict": "verified", "source": 0 }, { "key": "human_approval", "value": "The specification does not require a person to approve a new registration, which is why proxies must add their own consent step.", "verdict": "absent", "source": 0 } ], "what_it_changes": "If your authorization server accepts dynamic registration, anyone can mint a client. Pair it with per client consent and exact redirect URI matching, or move to client identity documents as MCP now advises. Treat a self registered client id as an unverified claim, not an identity.", "sources": [ { "name": "RFC Editor, RFC 7591", "url": "https://www.rfc-editor.org/rfc/rfc7591.html", "type": "primary", "date": "2015-07-01" }, { "name": "Model Context Protocol specification 2026-07-28, Authorization", "url": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization", "type": "primary", "date": "2026-07-28" } ], "related_ids": [ "AAL-2026-0005", "AAL-2026-0006" ], "tags": [ "oauth", "registration", "client identity" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0012", "slug": "oauth-2-1-internet-draft", "title": "The OAuth 2.1 Internet-Draft", "kind": "draft", "verdict": "verified", "jurisdiction": "GLOBAL", "answer": "OAuth 2.1 consolidates the framework agent tooling already depends on, replacing RFC 6749 and RFC 6750 and folding in a decade of security practice. It is still an active Internet-Draft. The Model Context Protocol requires authorization servers to implement it, so a large part of agent authorization rests on a document that is not yet an RFC.", "key_facts": [ "The draft states that it replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749 and the Bearer Token Usage in RFC 6750.", "The latest revision at the time of checking is draft-ietf-oauth-v2-1-16, dated 3 September 2026.", "It remains an active Internet-Draft rather than a published RFC.", "MCP authorization requires authorization servers to implement OAuth 2.1 for both confidential and public clients." ], "facets": [ { "key": "authorization", "value": "It is the authorization baseline the agent tooling ecosystem cites, including mandatory PKCE and the removal of the implicit and password grants.", "verdict": "verified", "source": 0 } ], "what_it_changes": "Your agent stack cites a draft. That is normal in this field and not a defect, but it belongs in your risk register: revision numbers move, and a control you wrote against draft 13 may read differently at draft 16. Pin the revision you implemented and re read it when you upgrade.", "sources": [ { "name": "IETF Datatracker, draft-ietf-oauth-v2-1", "url": "https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/", "type": "primary", "date": "2026-09-03" } ], "related_ids": [ "AAL-2026-0007", "AAL-2026-0004" ], "tags": [ "oauth", "draft", "ietf" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0013", "slug": "agent-passport-system-internet-draft", "title": "Agent Passport System, an IETF Internet-Draft", "kind": "draft", "verdict": "verified", "jurisdiction": "GLOBAL", "answer": "This individual Internet-Draft proposes what no adopted standard yet provides: a cryptographic identity for an agent, a signed binding to the principal it acts for, and delegation chains that can only narrow. It defines bindings for Model Context Protocol tool calls. It is an individual submission, not a working group product, so it binds nobody.", "key_facts": [ "The draft defines Ed25519 agent passports and separately signed principal bindings.", "It defines delegation chains that cannot widen across scope, spend, depth, time, reputation, values or reversibility.", "It defines bindings for Model Context Protocol tool calls and imported OAuth identity assertion authorization grants.", "The version checked is draft-pidlisnyi-aps-03, dated 18 July 2026." ], "figures": [ { "label": "Constraint dimensions a delegation chain may not widen across", "value": 7, "unit": "dimensions", "as_of": "2026-07-18", "source": 0 } ], "facets": [ { "key": "identity", "value": "An agent holds its own signing key and a passport, rather than borrowing a user's session.", "verdict": "verified", "source": 0 }, { "key": "delegation", "value": "Authority passes down a chain that may only narrow, which is the attenuation property missing from OAuth.", "verdict": "verified", "source": 0 }, { "key": "limits", "value": "Spend, depth, time and reversibility are first class constraints carried in the chain rather than enforced by each tool separately.", "verdict": "verified", "source": 0 }, { "key": "accountability", "value": "Signed action receipts are proposed as evidence produced at policy enforcement boundaries.", "verdict": "verified", "source": 0 } ], "what_it_changes": "Do not implement this as a standard. Read it as the clearest published statement of what a complete agent authority record would contain, and use its seven dimensions as a checklist against whatever you built. If your agent's authority cannot be narrowed when it hands work to another agent, this draft explains the gap you have.", "sources": [ { "name": "IETF Datatracker, draft-pidlisnyi-aps-03", "url": "https://datatracker.ietf.org/doc/draft-pidlisnyi-aps/03/", "type": "primary", "date": "2026-07-18" } ], "related_ids": [ "AAL-2026-0010", "AAL-2026-0033", "AAL-2026-0031" ], "tags": [ "ietf", "draft", "delegation", "attenuation" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15" }, { "id": "AAL-2026-0014", "slug": "web-bot-auth-architecture-internet-draft", "title": "Web Bot Auth architecture, an IETF Internet-Draft", "kind": "draft", "verdict": "verified", "jurisdiction": "GLOBAL", "answer": "This draft describes how an automated client proves who it is to a website by signing its own requests, replacing user agent strings and address allowlists. It is the identity layer for agents that browse rather than agents that call APIs, and it is the foundation the Visa agent commerce work builds on.", "key_facts": [ "The stated goal is to allow automated HTTP clients to cryptographically sign outbound requests, so servers can verify their identity with confidence.", "The architecture proposes that every request from a bot be signed by a private key owned by its provider, so every origin can validate the service identity.", "It addresses the weakness of identifying automated traffic by user agent string or address range.", "The version checked is draft-meunier-web-bot-auth-architecture-05, dated 2 March 2026." ], "facets": [ { "key": "identity", "value": "The agent's operator signs each request with a key, and the origin verifies it, so identity is proven per request rather than asserted in a header.", "verdict": "verified", "source": 0 }, { "key": "authorization", "value": "The draft establishes who is calling. What that caller may then do is left to the origin's own policy.", "verdict": "absent", "source": 0 } ], "what_it_changes": "If your agent browses the open web, expect origins to start asking it to sign. Getting a key, publishing a directory and signing requests is now the difference between being served and being filtered with the scrapers. If you run a site, this is how you tell a paying customer's agent from a crawler.", "sources": [ { "name": "IETF Datatracker, draft-meunier-web-bot-auth-architecture", "url": "https://datatracker.ietf.org/doc/html/draft-meunier-web-bot-auth-architecture", "type": "primary", "date": "2026-03-02" } ], "related_ids": [ "AAL-2026-0019", "AAL-2026-0013" ], "tags": [ "ietf", "draft", "signatures", "bots" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0015", "slug": "owasp-top-10-for-llm-applications-2025", "title": "OWASP Top 10 for LLM Applications 2025", "kind": "guidance", "verdict": "verified", "jurisdiction": "GLOBAL", "answer": "The security profession's shared vocabulary for language model risk. Two entries decide agent authority: LLM01 prompt injection, because an agent reads untrusted text and then acts, and LLM06 excessive agency, which is the failure of giving a system more functionality, permissions or autonomy than its task requires.", "key_facts": [ "LLM01:2025 is Prompt Injection, where user prompts alter the behaviour or output of the model in unintended ways.", "LLM06:2025 is Excessive Agency, which OWASP introduces with the observation that an LLM based system is often granted a degree of agency.", "Excessive agency is the entry that maps directly onto tool permissions, so it is the one a deployment review should evidence.", "The list is the 2025 edition of the Top 10 for Large Language Model Applications, published by the OWASP Gen AI Security Project." ], "figures": [ { "label": "Risks named in the list", "value": 10, "unit": "risks", "as_of": "2026-09-15", "source": 0 } ], "facets": [ { "key": "limits", "value": "Excessive agency names the control: limit the functions, the permissions and the autonomy an agent's tools grant it.", "verdict": "verified", "source": 0 }, { "key": "human_approval", "value": "The mitigation for high impact actions is a human in the loop rather than tighter prompting.", "verdict": "verified", "source": 0 } ], "what_it_changes": "These two entries are the ones your risk register needs. Prompt injection means an agent that reads a web page has read an instruction from a stranger, so authority must be enforced outside the model. Excessive agency means the tool list is the blast radius: cut it to the task and the injection matters less.", "sources": [ { "name": "OWASP Gen AI Security Project, Top 10 for LLM Applications", "url": "https://genai.owasp.org/llm-top-10/", "type": "primary", "date": "2026-09-15" } ], "related_ids": [ "AAL-2026-0016", "AAL-2026-0005" ], "tags": [ "owasp", "prompt injection", "excessive agency" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15" }, { "id": "AAL-2026-0016", "slug": "owasp-top-10-for-agentic-applications-2026", "title": "OWASP Top 10 for Agentic Applications 2026", "kind": "guidance", "verdict": "verified", "jurisdiction": "GLOBAL", "answer": "Published on 9 December 2025 by the OWASP Agentic Security Initiative, this is the first Top 10 written for systems that plan and act rather than systems that answer. Its stated purpose is practical, actionable guidance for securing agents that plan, act and make decisions across complex workflows.", "key_facts": [ "OWASP describes the list as providing practical, actionable guidance to help organisations secure AI agents that plan, act, and make decisions across complex workflows.", "It sits alongside the Agentic Security Initiative's other outputs, including a practical guide for secure MCP server development.", "It is a community list, not a certification scheme or a control catalogue an auditor can test against.", "It gives security teams a shared vocabulary for classifying and reporting agentic threats." ], "figures": [ { "label": "Risks named in the list", "value": 10, "unit": "risks", "as_of": "2025-12-09", "source": 0 } ], "facets": [ { "key": "limits", "value": "The list is organised around what an agent can reach and do, which makes the tool and permission inventory the first artefact a review needs.", "verdict": "verified", "source": 0 }, { "key": "accountability", "value": "It gives a shared vocabulary for reporting agentic incidents, which is the precondition for anyone being answerable for one.", "verdict": "verified", "source": 0 } ], "what_it_changes": "Use this as the threat model your agent design review runs against, the way web teams use the web Top 10. It will not satisfy a regulator on its own, but a review that cannot name which of these risks apply to your agent has not been a review.", "sources": [ { "name": "OWASP Gen AI Security Project", "url": "https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/", "type": "primary", "date": "2025-12-09" }, { "name": "OWASP Agentic Security Initiative", "url": "https://genai.owasp.org/initiatives/agentic-security-initiative/", "type": "primary", "date": "2026-09-15" } ], "related_ids": [ "AAL-2026-0015", "AAL-2026-0005" ], "tags": [ "owasp", "agentic", "threat model" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15" }, { "id": "AAL-2026-0017", "slug": "a2a-protocol-enterprise-authentication", "title": "A2A protocol, agent to agent authentication", "kind": "standard", "verdict": "verified", "jurisdiction": "GLOBAL", "answer": "The agent to agent protocol deliberately keeps identity out of its messages. Its own documentation states that A2A payloads do not carry user or client identity directly, and pushes authentication down to the transport. Authorization is left to each agent, which must enforce it before performing sensitive actions.", "key_facts": [ "The documentation states that A2A protocol payloads, such as JSON-RPC messages, do not carry user or client identity information directly.", "Identity is handled at the HTTP layer with standard web authentication rather than inside the protocol.", "Agents that interact with backend systems, databases or tools must enforce appropriate authorization before performing sensitive actions.", "Because identity is not in the payload, an agent receiving a delegated task cannot read the original principal out of the message itself." ], "facets": [ { "key": "identity", "value": "The protocol carries no identity claim; the calling agent is whoever the transport authenticated.", "verdict": "verified", "source": 0 }, { "key": "authorization", "value": "Each agent is told to enforce authorization itself before any sensitive action, so the protocol sets a duty rather than a mechanism.", "verdict": "verified", "source": 0 }, { "key": "delegation", "value": "Nothing in the payload records that one agent is acting for another agent's principal, so a delegation chain has to be carried outside A2A.", "verdict": "absent", "source": 0 } ], "what_it_changes": "If you connect agents with A2A, you own the identity problem. The protocol will not tell a receiving agent whose authority is behind a request, so decide now whether you carry that in a token audience, a token exchange actor claim, or an out of band record, and write it down before the second agent is added.", "sources": [ { "name": "A2A Protocol documentation, Enterprise Ready", "url": "https://a2a-protocol.org/latest/topics/enterprise-ready/", "type": "primary", "date": "2026-09-15" } ], "related_ids": [ "AAL-2026-0010", "AAL-2026-0033" ], "tags": [ "a2a", "multi agent", "authentication" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0018", "slug": "spiffe-workload-identity", "title": "SPIFFE workload identity", "kind": "standard", "verdict": "verified", "jurisdiction": "GLOBAL", "answer": "SPIFFE is a set of open standards for identifying software rather than people. A workload receives a short lived cryptographic identity document through a simple interface and uses it to authenticate to other workloads. It is the existing answer to non human identity, and NIST's concept paper names it among the standards agents might reuse.", "key_facts": [ "SPIFFE is described by its maintainers as a set of open source standards for securely identifying software systems in dynamic and heterogeneous environments.", "Workloads receive short lived cryptographic identity documents, called SVIDs, through a simple interface.", "Identity is proven with mutual TLS or signed tokens rather than with network position or a shared secret.", "Short lifetimes are the revocation mechanism in practice: an identity that is not renewed stops working." ], "facets": [ { "key": "identity", "value": "A running workload gets a verifiable name of its own, which is the closest deployed analogue to an agent identity.", "verdict": "verified", "source": 0 }, { "key": "revocation", "value": "Documents are short lived and continuously reissued, so withdrawal is expiry rather than an explicit revocation call.", "verdict": "verified", "source": 0 }, { "key": "authorization", "value": "SPIFFE names the workload. What that name is permitted to do is decided by the policy system consuming it.", "verdict": "absent", "source": 0 } ], "what_it_changes": "If your agents run as workloads you control, you may already have the identity layer and not be using it. Giving each agent its own SPIFFE identity rather than a shared service account is the single change that makes agent activity attributable in existing logs.", "sources": [ { "name": "SPIFFE documentation", "url": "https://spiffe.io/docs/latest/spiffe-about/overview/", "type": "primary", "date": "2026-09-15" } ], "related_ids": [ "AAL-2026-0001", "AAL-2026-0003", "AAL-2026-0033" ], "tags": [ "spiffe", "workload identity", "non human identity" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0019", "slug": "visa-trusted-agent-protocol", "title": "Visa Trusted Agent Protocol", "kind": "standard", "verdict": "verified", "jurisdiction": "GLOBAL", "answer": "Announced on 14 October 2025, Visa's protocol lets a merchant recognise an approved shopping agent and read its intent, using HTTP Message Signatures. It is the first card network attempt to answer know your agent at the point of sale, and it verifies the agent rather than authorising a payment.", "key_facts": [ "Visa describes the specification as the official rulebook detailing the technical processes for recognizing a Visa approved agent, including the cryptographic standards in RFC 9421.", "A merchant validates the signature by reconstructing the signature base string from the request and verifying it with the agent's public key.", "The protocol defines agent intent, an indication that a trusted agent intends to retrieve details about, or purchase, a specific product from a merchant.", "Visa says the protocol aims to let AI search, compare and pay on behalf of consumers while ensuring trust between merchants and AI agents." ], "facets": [ { "key": "identity", "value": "The agent signs its requests and the merchant verifies the signature, so a legitimate agent is distinguishable from an unapproved bot.", "verdict": "verified", "source": 0 }, { "key": "authorization", "value": "Recognition is separate from payment authorization, which still runs through the existing card rails.", "verdict": "verified", "source": 1 }, { "key": "limits", "value": "Agent intent tells a merchant what the agent is there to do, but the protocol does not itself carry a spending ceiling.", "verdict": "absent", "source": 0 } ], "what_it_changes": "If you build a shopping agent, plan to sign. If you run a merchant site, this is the first credible way to let an agent through the bot defences you already run, and it arrives on the same signature machinery as Web Bot Auth, so the two are one implementation rather than two.", "sources": [ { "name": "Visa Developer Center, Trusted Agent Protocol", "url": "https://developer.visa.com/capabilities/trusted-agent-protocol/docs-getting-started", "type": "primary", "date": "2026-09-15" }, { "name": "Visa newsroom", "url": "https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21716.html", "type": "primary", "date": "2025-10-14" } ], "related_ids": [ "AAL-2026-0014", "AAL-2026-0020", "AAL-2026-0034" ], "tags": [ "visa", "agentic commerce", "signatures", "payments" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0020", "slug": "mastercard-agent-pay", "title": "Mastercard Agent Pay", "kind": "standard", "verdict": "reported", "jurisdiction": "GLOBAL", "answer": "Mastercard's agentic payments programme lets a verified agent transact for a consumer using tokenised credentials rather than a raw card number. The ledger could not reach Mastercard's own pages, which refused automated requests, so this row rests on a partner announcement and is recorded as reported rather than verified.", "key_facts": [ "A partner announcement states that Mastercard Agent Pay will integrate with PayPal's wallet to allow AI agents to simply and securely complete transactions on behalf of PayPal users.", "The same announcement says the work will ensure compatibility and interoperability with Mastercard and common agentic protocols, and enable AI agent verification and data exchange.", "Mastercard's own product and press pages returned an HTTP 403 refusal to this ledger's requests, so no primary source is listed.", "Nothing here is a published specification the ledger has read, so the technical claims circulating about agentic tokens are not repeated as fact." ], "facets": [ { "key": "identity", "value": "The programme is described as working only with verified agents, with agent verification named as part of the partner integration.", "verdict": "reported", "source": 0 }, { "key": "authorization", "value": "Payment authority is described as reaching the agent through a tokenised credential rather than the consumer's card number.", "verdict": "reported", "source": 0 } ], "what_it_changes": "Treat vendor claims about agentic payment controls as unverified until you read the specification yourself. If a payments provider tells you their agent tokens carry consent and spending policy, ask for the document, because at the time of this check the network's own pages could not be read from outside a browser.", "sources": [ { "name": "PayPal newsroom, Mastercard and PayPal agentic commerce announcement", "url": "https://newsroom.paypal-corp.com/2025-10-27-Mastercard-and-PayPal-Join-Forces-To-Accelerate-Secure-Global-Agentic-Commerce", "type": "secondary", "date": "2025-10-27" } ], "related_ids": [ "AAL-2026-0019", "AAL-2026-0034" ], "tags": [ "mastercard", "payments", "agentic commerce" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0021", "slug": "eu-ai-act-article-12-record-keeping", "title": "EU AI Act Article 12, record keeping", "kind": "law", "verdict": "verified", "jurisdiction": "EU", "answer": "Article 12 of Regulation (EU) 2024/1689 requires that high risk AI systems technically allow the automatic recording of events over the lifetime of the system. For an agent, this is the binding source of the logging requirement: the capability has to be built in, not bolted on by whoever deploys it.", "key_facts": [ "Article 12(1) states that high risk AI systems shall technically allow for the automatic recording of events, or logs, over the lifetime of the system.", "The logging capability must support identifying situations that may result in risk, and post market monitoring.", "The duty falls on the provider to build the capability, while Article 26 places the duty to keep the resulting logs on the deployer.", "Regulation (EU) 2024/1689 was published in the Official Journal on 12 July 2024." ], "facets": [ { "key": "logging", "value": "Automatic event recording over the lifetime of the system is a design requirement, not an operational option.", "verdict": "verified", "source": 1 }, { "key": "accountability", "value": "Logs are the evidence that makes post market monitoring and incident investigation possible, which is how responsibility is traced back.", "verdict": "verified", "source": 1 } ], "what_it_changes": "If your agent falls in a high risk use, the log is not a debugging convenience. Ask your provider where the event log is, what it records, and whether it covers tool calls and not only model outputs, because an agent that logs its answers and not its actions cannot evidence anything.", "sources": [ { "name": "EUR-Lex, Regulation (EU) 2024/1689", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401689", "type": "primary", "date": "2024-07-12" }, { "name": "AI Act Explorer, Article 12", "url": "https://artificialintelligenceact.eu/article/12/", "type": "secondary", "date": "2026-09-15" } ], "related_ids": [ "AAL-2026-0022", "AAL-2026-0023", "AAL-2026-0029" ], "tags": [ "eu ai act", "logging", "high risk" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0022", "slug": "eu-ai-act-article-14-human-oversight", "title": "EU AI Act Article 14, human oversight", "kind": "law", "verdict": "verified", "jurisdiction": "EU", "answer": "Article 14 requires high risk AI systems to be designed so that natural persons can effectively oversee them while they are in use, including the ability to intervene or interrupt the system through a stop button or comparable procedure. For an autonomous agent, that is the legal floor under the phrase human in the loop.", "key_facts": [ "Article 14(1) requires high risk AI systems to be designed and developed so they can be effectively overseen by natural persons during the period in which they are in use, including through appropriate human machine interface tools.", "Article 14(4)(e) requires that the overseer be able to intervene in the operation of the system or interrupt it through a stop button or a comparable procedure that allows the system to halt in a safe state.", "Oversight has to be built into the system, so an agent with no interruption path fails the article regardless of how careful its operator is.", "Regulation (EU) 2024/1689 was published in the Official Journal on 12 July 2024." ], "facets": [ { "key": "human_approval", "value": "Effective oversight by a natural person during use is mandatory for high risk systems, which is stronger than a review after the fact.", "verdict": "verified", "source": 1 }, { "key": "limits", "value": "The stop capability is a hard bound on autonomy: the system must be able to be halted safely by the person overseeing it.", "verdict": "verified", "source": 1 } ], "what_it_changes": "Find your stop button before a regulator asks. For an agent this means a real answer to three questions: who is watching, how do they interrupt a run in progress, and what state is the work left in when they do. If interruption only kills a process and leaves half finished writes, you do not have one.", "sources": [ { "name": "EUR-Lex, Regulation (EU) 2024/1689", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401689", "type": "primary", "date": "2024-07-12" }, { "name": "AI Act Explorer, Article 14", "url": "https://artificialintelligenceact.eu/article/14/", "type": "secondary", "date": "2026-09-15" } ], "related_ids": [ "AAL-2026-0021", "AAL-2026-0023", "AAL-2026-0025" ], "tags": [ "eu ai act", "human oversight", "stop button" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0023", "slug": "eu-ai-act-article-26-deployer-obligations", "title": "EU AI Act Article 26, deployer obligations", "kind": "law", "verdict": "verified", "jurisdiction": "EU", "answer": "Article 26 is the clause that binds the organisation running an agent rather than the one that built it. Deployers must use a high risk system according to its instructions, assign human oversight to competent and supported natural persons, and keep the logs the system generates for at least six months.", "key_facts": [ "Deployers must take appropriate technical and organisational measures to ensure they use high risk systems in accordance with the instructions for use.", "Deployers must assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support.", "Deployers must keep the logs automatically generated by the high risk system for a period appropriate to the intended purpose, of at least six months, unless other Union or national law provides otherwise.", "Financial institutions may keep those logs as part of the documentation they already maintain under financial services law." ], "figures": [ { "label": "Minimum period a deployer keeps a high risk system's logs", "value": 6, "unit": "months", "as_of": "2024-07-12", "source": 1 } ], "facets": [ { "key": "accountability", "value": "The deploying organisation carries named duties of its own, so running somebody else's agent does not move responsibility to the vendor.", "verdict": "verified", "source": 1 }, { "key": "logging", "value": "Logs must be retained for at least six months where the deployer controls them.", "verdict": "verified", "source": 1 }, { "key": "human_approval", "value": "Oversight must be assigned to a competent, trained and authorised person, which makes it a staffing obligation rather than a design claim.", "verdict": "verified", "source": 1 } ], "what_it_changes": "If you deploy an agent built by somebody else in a high risk use, three things become yours: staying inside the instructions for use, naming the person who oversees it and giving them real authority, and retaining the logs for at least six months. All three are cheap to arrange in advance and impossible to reconstruct later.", "sources": [ { "name": "EUR-Lex, Regulation (EU) 2024/1689", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401689", "type": "primary", "date": "2024-07-12" }, { "name": "AI Act Explorer, Article 26", "url": "https://artificialintelligenceact.eu/article/26/", "type": "secondary", "date": "2026-09-15" } ], "related_ids": [ "AAL-2026-0021", "AAL-2026-0022", "AAL-2026-0031" ], "tags": [ "eu ai act", "deployer", "retention", "oversight" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15" }, { "id": "AAL-2026-0024", "slug": "imda-model-ai-governance-framework-for-agentic-ai", "title": "IMDA Model AI Governance Framework for Agentic AI", "kind": "guidance", "verdict": "verified", "jurisdiction": "SG", "answer": "Singapore's framework is the first national governance model written specifically for agents. Version 1.5 was published on 20 May 2026 and updated on 5 June 2026. It is organised around four dimensions: bound the risks upfront, make humans meaningfully accountable, implement technical controls and processes, and enable end user responsibility.", "key_facts": [ "The framework opens by saying there is no consensus on what defines an AI agent, but that agents usually possess some degree of independent planning, decision making and action taking over multiple steps to achieve a user defined goal.", "It states that humans must remain accountable and properly manage the risks of agentic AI.", "It lists controls and logging among the core components of an agent, naming access controls, guardrails and human approvals, and logging that records agent actions, decisions and interactions.", "It describes itself as a living document written for organisations deploying agentic AI, whether built in house or sourced from a third party.", "The version checked is version 1.5, published 20 May 2026 and updated 5 June 2026." ], "figures": [ { "label": "Dimensions in the framework", "value": 4, "unit": "dimensions", "as_of": "2026-05-20", "source": 0 } ], "facets": [ { "key": "limits", "value": "Organisations are told to bound an agent's scope of impact by design, limiting access to tools and external systems at the planning stage.", "verdict": "verified", "source": 0 }, { "key": "human_approval", "value": "Significant checkpoints in the agentic workflow should require human approval, in particular for high stakes or irreversible actions.", "verdict": "verified", "source": 0 }, { "key": "logging", "value": "Logging and monitoring is named as a core component of an agent, recording actions, decisions and interactions to enable accountability.", "verdict": "verified", "source": 0 }, { "key": "accountability", "value": "The framework warns that agent autonomy complicates responsibility assignments tied to static workflows and that multiple actors diffuse accountability, so responsibilities must be defined explicitly.", "verdict": "verified", "source": 0 }, { "key": "identity", "value": "Identity management and access controls for agents are named as measures that make an agent's actions traceable and controllable.", "verdict": "verified", "source": 0 } ], "what_it_changes": "This is the most usable checklist a deploying team can pick up today, and it is free. Work through its four dimensions in order: decide which use cases an agent may take, bound its permissions before writing code, name the humans who are answerable, and tell your end users what the agent can reach.", "sources": [ { "name": "IMDA, Model AI Governance Framework for Agentic AI", "url": "https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/mgf-for-agentic-ai.pdf", "type": "primary", "date": "2026-05-20" }, { "name": "IMDA press release", "url": "https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2026/new-model-ai-governance-framework-for-agentic-ai", "type": "primary", "date": "2026-01-22" } ], "related_ids": [ "AAL-2026-0025", "AAL-2026-0031", "AAL-2026-0033" ], "tags": [ "singapore", "imda", "governance", "accountability" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15" }, { "id": "AAL-2026-0025", "slug": "ico-tech-futures-agentic-ai", "title": "ICO tech futures report on agentic AI", "kind": "guidance", "verdict": "verified", "jurisdiction": "UK", "answer": "The United Kingdom's data protection regulator published an assessment of agentic AI rather than formal guidance. Its central message is that automation does not move responsibility: organisations remain responsible for data protection compliance of the agentic AI they develop, deploy or integrate. It also warns about systems with no way to monitor or stop activity.", "key_facts": [ "The ICO states that as developing agentic AI increases the potential for automation, organisations remain responsible for data protection compliance of the agentic AI they develop, deploy or integrate in their systems and processes.", "It states that the specific design and architecture of agentic systems impact how data protection law applies and how people exercise their data protection rights.", "It flags implementations with no measures in place to secure access, monitor or stop activity, or control the further sharing of information.", "The report is part of the ICO's tech futures series and is not formal statutory guidance." ], "facets": [ { "key": "accountability", "value": "Organisational responsibility survives the agent's autonomy, for systems the organisation develops, deploys or integrates.", "verdict": "verified", "source": 0 }, { "key": "revocation", "value": "The regulator names the absence of a way to stop an agent's activity as a risk, without prescribing a mechanism.", "verdict": "verified", "source": 0 }, { "key": "limits", "value": "Securing access and controlling onward sharing of information are named as the measures whose absence creates risk.", "verdict": "verified", "source": 0 } ], "what_it_changes": "In the United Kingdom your existing data protection accountability already covers the agent. The practical consequence is a design question the ICO asks directly: can you secure what the agent reaches, see what it did, stop it, and control what it passed on. Four yes answers, written down, is the record to keep.", "sources": [ { "name": "Information Commissioner's Office, ICO tech futures: agentic AI", "url": "https://ico.org.uk/about-the-ico/research-reports-impact-and-evaluation/research-and-reports/technology-and-innovation/tech-horizons-and-ico-tech-futures/ico-tech-futures-agentic-ai/", "type": "primary", "date": "2026-09-15" } ], "related_ids": [ "AAL-2026-0024", "AAL-2026-0031" ], "tags": [ "uk", "ico", "data protection", "accountability" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0026", "slug": "sbi-chairman-know-your-agent", "title": "State Bank of India chairman calls for know your agent", "kind": "guidance", "verdict": "reported", "jurisdiction": "IN", "answer": "At the Global Fintech Fest on 10 September 2026, the chairman of the State Bank of India argued that as agents begin to take part in financial transactions, banks will need a know your agent discipline alongside know your customer. The remark is carried by press reports; no bank or regulator document was published, so this is reported.", "key_facts": [ "Press reports quote the chairman saying that as agents begin to participate in financial transactions, we will increasingly need to think about know your agent.", "Reports name the dimensions he raised as agent identity, customer consent, transaction limits and audit trails.", "The remarks were made at the Global Fintech Fest in Mumbai on 10 September 2026.", "No published bank policy, circular or regulatory instrument accompanies the remark, so the ledger lists no primary source." ], "facets": [ { "key": "identity", "value": "Establishing the identity of the agent acting in a transaction is the first of the four dimensions the reports attribute to him.", "verdict": "reported", "source": 0 }, { "key": "limits", "value": "Transaction limits are named as part of the proposed discipline, bounding what an agent may move.", "verdict": "reported", "source": 0 }, { "key": "logging", "value": "Audit trails are named as part of the proposed discipline.", "verdict": "reported", "source": 0 }, { "key": "human_approval", "value": "Customer consent is named as a condition of an agent acting on an account.", "verdict": "reported", "source": 1 } ], "what_it_changes": "This is where the phrase in this ledger's title comes from, and it is an intention rather than a rule. If you operate in Indian financial services, read it as a signal that the four dimensions named will be the ones you are eventually asked to evidence, and start recording them now while it is cheap.", "sources": [ { "name": "The Tribune", "url": "https://www.tribuneindia.com/news/business/customer-engagement-productivity-and-risk-sbi-chair-details-three-focus-areas-for-agentic-ai-rollout/", "type": "secondary", "date": "2026-09-10" }, { "name": "Retail Intel", "url": "https://retailintel.in/signal/sbi-calls-for-know-your-agent-rules-as-ai-moves-into-banking-6916cf8b", "type": "secondary", "date": "2026-09-10" } ], "related_ids": [ "AAL-2026-0034", "AAL-2026-0019" ], "tags": [ "india", "banking", "know your agent" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0027", "slug": "iso-iec-42001-ai-management-system", "title": "ISO/IEC 42001, AI management system", "kind": "standard", "verdict": "verified", "jurisdiction": "GLOBAL", "answer": "Published on 18 December 2023, ISO/IEC 42001 specifies the requirements for establishing, implementing, maintaining and continually improving an AI management system. It is the certifiable management wrapper around everything else in this ledger: it does not tell you how to authorise an agent, it tells you to decide, document and review how you do.", "key_facts": [ "The standard states that it specifies the requirements and provides guidance for establishing, implementing, maintaining and continually improving an AI management system.", "Its full title is Information technology, Artificial intelligence, Management system, and the edition checked is the first.", "It is a management system standard, so organisations are certified against their own documented system rather than against any agent control.", "It names no agent specific control, which is why it pairs with rather than replaces the technical rows in this ledger." ], "facets": [ { "key": "accountability", "value": "The standard puts named roles, objectives and review cycles around AI use, which is how an organisation stays answerable as systems change.", "verdict": "verified", "source": 0 }, { "key": "authorization", "value": "No clause addresses how an agent obtains or presents authority; that is left to the controls the organisation chooses.", "verdict": "absent", "source": 0 } ], "what_it_changes": "If a buyer asks whether your agent programme is governed, this certificate is the shortest credible answer. It proves you run a system, not that the agent is safe, so do not let it stand in for the technical evidence: the authorization, logging and stop path still have to exist underneath it.", "sources": [ { "name": "IEC Webstore, ISO/IEC 42001:2023", "url": "https://webstore.iec.ch/en/publication/90574", "type": "primary", "date": "2023-12-18" } ], "related_ids": [ "AAL-2026-0024", "AAL-2026-0023" ], "tags": [ "iso", "management system", "certification" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0028", "slug": "no-us-federal-law-defines-agent-identity-or-authorization", "title": "No binding United States federal law defines an AI agent's identity or authorization", "kind": "law", "verdict": "absent", "jurisdiction": "US", "answer": "There is no United States federal statute that says what an AI agent's identity is, who may authorise one, or what it may be permitted to do. The federal activity is at the standards stage: a NIST concept paper, a request for information and an initiative page, none of which bind anyone. Bills have been introduced and none has become law.", "search": "Checked on 15 September 2026. Searched the NIST AI Agent Standards Initiative page and the NCCoE concept paper on software and AI agent identity and authorization, both of which describe proposed voluntary work rather than a rule. Searched for federal statutes and introduced bills defining AI agent identity, delegation or authorization; the results name introduced legislation that would direct NIST to develop standards, and none that has been enacted. The federal identity baseline, NIST SP 800-63-4, states in terms that person refers only to natural persons and excludes machine to machine authentication from its scope.", "key_facts": [ "The federal work on agent identity sits in NIST's voluntary standards programme, not in statute.", "The NCCoE concept paper of 5 February 2026 proposes a demonstration project and invited comment; it creates no obligation.", "NIST SP 800-63-4, the federal digital identity baseline, applies to natural persons and excludes machine to machine authentication.", "Sector regulators apply existing law to AI use, but no federal instrument defines the identity or authority of an agent as such." ], "facets": [ { "key": "identity", "value": "No federal definition of an agent's identity exists, so an organisation's own directory naming is the only record that an agent is a distinct actor.", "verdict": "absent", "source": 0 }, { "key": "authorization", "value": "No federal rule states who may grant an agent authority or what the grant must contain.", "verdict": "absent", "source": 1 } ], "what_it_changes": "Do not wait for a rule. In the United States the only authority record your agent has is the one you write, so the practical move is to adopt the dimensions NIST is collecting evidence on and keep your own register of every agent, its principal, its permissions and who can switch it off.", "sources": [ { "name": "NIST AI Agent Standards Initiative", "url": "https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative", "type": "primary", "date": "2026-08-14" }, { "name": "NIST Computer Security Resource Center, concept paper", "url": "https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd", "type": "primary", "date": "2026-02-05" }, { "name": "NIST SP 800-63-4", "url": "https://pages.nist.gov/800-63-4/sp800-63.html", "type": "primary", "date": "2025-08-26" } ], "related_ids": [ "AAL-2026-0001", "AAL-2026-0002", "AAL-2026-0003" ], "tags": [ "united states", "gap", "federal law" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0029", "slug": "no-eu-instrument-defines-an-ai-agent", "title": "No EU instrument defines an AI agent", "kind": "law", "verdict": "absent", "jurisdiction": "EU", "answer": "The European Commission says plainly that the term AI agent is not legally defined and that agents are not a separate category under the AI Act. Agents are regulated through the existing definitions of an AI system and a general purpose AI model, so the obligations that reach them depend on what the agent is used for, not on what it is called.", "search": "Checked on 15 September 2026 at the Commission's own AI Act Service Desk, which answers the question of how AI agents are addressed within the AI Act, and against the text of Regulation (EU) 2024/1689 at EUR-Lex. The Service Desk states the term is not legally defined and that agents are not a separate category of AI under the Act. No definition of AI agent appears in the Act's definitions article, and no separate Union instrument on agent identity or authorisation was found.", "key_facts": [ "The Commission states that the term AI agent is not legally defined and is used colloquially for different kinds of artefacts.", "It states that AI agents are not a separate category of AI under the AI Act, and are covered by the definitions of AI systems and general purpose AI models.", "Agents therefore meet the Act through the prohibitions, the transparency duties of Article 50 and the high risk requirements where they apply.", "The Commission says it will consider strategies to address the potential risks posed by AI agents, which is an intention rather than an instrument." ], "facets": [ { "key": "identity", "value": "Union law gives an agent no identity of its own; the provider and the deployer are the legal persons in view.", "verdict": "absent", "source": 0 }, { "key": "accountability", "value": "Responsibility is allocated through the existing provider and deployer roles rather than through anything agent specific.", "verdict": "verified", "source": 0 } ], "what_it_changes": "Stop asking whether your agent is covered by the AI Act and ask what it does. Classification follows the use case, so an agent in a high risk domain carries the full Chapter III weight while the same code in a low risk workflow carries the transparency duty and little else.", "sources": [ { "name": "European Commission, AI Act Service Desk", "url": "https://ai-act-service-desk.ec.europa.eu/en/ai-act/faq/how-are-ai-agents-addressed-within-ai-act-0", "type": "primary", "date": "2026-09-15" }, { "name": "EUR-Lex, Regulation (EU) 2024/1689", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401689", "type": "primary", "date": "2024-07-12" } ], "related_ids": [ "AAL-2026-0021", "AAL-2026-0022", "AAL-2026-0023" ], "tags": [ "european union", "gap", "definition" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0030", "slug": "no-international-standard-for-agent-revocation", "title": "No international standard governs revoking an agent's authority", "kind": "standard", "verdict": "absent", "jurisdiction": "GLOBAL", "answer": "Nothing published as a standard says how to withdraw an agent's authority once it has been granted, or how a withdrawal propagates to work the agent has already handed on. What exists is expiry, token lifetimes and certificate revocation lists, all of which were designed for services rather than for a chain of delegated agents.", "search": "Checked on 15 September 2026. Read the Model Context Protocol authorization sections of 18 June 2025 and 28 July 2026, which require token validation and short lifetimes but define no revocation endpoint or propagation rule for agents. Read the OAuth 2.1 Internet-Draft and RFC 8693 token exchange, neither of which defines withdrawal of a delegated actor's authority. Read the SPIFFE overview, where withdrawal is expiry of a short lived document. Searched the IETF Datatracker for agent revocation work and found only individual Internet-Drafts, no working group output. ISO's own catalogue pages refused automated requests, so ISO material was checked through the IEC catalogue entry for ISO/IEC 42001, which is a management system standard and names no agent revocation control.", "key_facts": [ "The Model Context Protocol relies on short lived access tokens and audience validation rather than on any revocation mechanism for an agent.", "SPIFFE withdraws authority by letting a short lived identity document expire, which cannot stop work already delegated onward.", "RFC 8693 defines how authority is exchanged but not how an exchanged authority is withdrawn.", "The Agent Passport System Internet-Draft is an individual submission and not an adopted standard, so its chain semantics bind nobody.", "Regulators name stopping an agent as a control, but none points at a standard that implements it." ], "facets": [ { "key": "revocation", "value": "No published standard defines how an agent's authority is withdrawn, or how a withdrawal reaches sub agents and tools that already hold a delegated grant.", "verdict": "absent", "source": 0 }, { "key": "delegation", "value": "Delegation is standardised in one hop only, which is why revocation across a chain has nothing to attach to.", "verdict": "absent", "source": 1 } ], "what_it_changes": "Assume you cannot recall an agent's authority and design so you do not need to. Short token lifetimes, narrow audiences and a kill path you have actually tested are the whole answer today, and any vendor claiming standards based agent revocation should be asked which standard, by number.", "sources": [ { "name": "Model Context Protocol specification 2026-07-28, Authorization", "url": "https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization", "type": "primary", "date": "2026-07-28" }, { "name": "RFC Editor, RFC 8693", "url": "https://www.rfc-editor.org/rfc/rfc8693.html", "type": "primary", "date": "2020-01-01" }, { "name": "SPIFFE documentation", "url": "https://spiffe.io/docs/latest/spiffe-about/overview/", "type": "primary", "date": "2026-09-15" } ], "related_ids": [ "AAL-2026-0013", "AAL-2026-0018", "AAL-2026-0025" ], "tags": [ "gap", "revocation", "delegation" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0031", "slug": "who-is-liable-when-a-delegated-agent-exceeds-its-mandate", "title": "Who is liable when a delegated agent exceeds its mandate", "kind": "question", "verdict": "open", "jurisdiction": "GLOBAL", "answer": "Every instrument in this ledger places responsibility on a human or an organisation, and none says what happens when an agent acts outside the authority it was given. Regulators say the deployer stays accountable. No published rule divides that between the deployer, the provider of the model and the operator of the tool the agent reached.", "key_facts": [ "The EU AI Act allocates duties to providers and deployers, and does not address an agent acting beyond its instructions.", "The ICO states that organisations remain responsible for the agentic AI they develop, deploy or integrate, without dividing responsibility between them.", "Singapore's framework warns that agent autonomy complicates responsibility assignments tied to static workflows and that multiple actors diffuse accountability.", "No instrument found defines what counts as exceeding a mandate, which is the prior question liability depends on." ], "facets": [ { "key": "accountability", "value": "Responsibility is stated in general terms and not apportioned when an agent exceeds what it was authorised to do.", "verdict": "open", "source": 1 } ], "what_it_changes": "Write the mandate down. If your contracts and your runbooks do not state what the agent was permitted to do, no later analysis can say it exceeded anything. A recorded mandate, a log of actions and a named owner are what turn this open question into a manageable dispute rather than an unanswerable one.", "sources": [ { "name": "AI Act Explorer, Article 26", "url": "https://artificialintelligenceact.eu/article/26/", "type": "secondary", "date": "2026-09-15" }, { "name": "Information Commissioner's Office, ICO tech futures: agentic AI", "url": "https://ico.org.uk/about-the-ico/research-reports-impact-and-evaluation/research-and-reports/technology-and-innovation/tech-horizons-and-ico-tech-futures/ico-tech-futures-agentic-ai/", "type": "primary", "date": "2026-09-15" }, { "name": "IMDA, Model AI Governance Framework for Agentic AI", "url": "https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/mgf-for-agentic-ai.pdf", "type": "primary", "date": "2026-05-20" } ], "related_ids": [ "AAL-2026-0023", "AAL-2026-0024", "AAL-2026-0025" ], "tags": [ "open question", "liability", "mandate" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0032", "slug": "can-an-agent-hold-a-credential-of-its-own", "title": "Can an agent hold a credential of its own", "kind": "question", "verdict": "open", "jurisdiction": "GLOBAL", "answer": "Workload identity gives software a name, and one Internet-Draft proposes agent passports with their own keys. Neither answers whether an agent may hold a credential in the way a person does, with rights attached to it. The United States identity baseline forecloses the question by saying person means only natural persons.", "key_facts": [ "NIST SP 800-63-4 states that for that publication, person refers only to natural persons.", "SPIFFE gives a workload a verifiable name, but that name carries no rights of its own.", "The Agent Passport System Internet-Draft proposes agent held signing keys bound to a principal, and it is an individual submission.", "No adopted standard states whether an agent's credential is its own or merely a container for a principal's authority." ], "facets": [ { "key": "identity", "value": "An agent can be named and can hold keys, but whether that constitutes a credential of its own is unsettled.", "verdict": "open", "source": 2 } ], "what_it_changes": "In practice, treat every agent credential as borrowed. Bind it to a named human or team, give it the shortest life your workflow tolerates, and never let it be the only thing that authorises a consequential action. The question is open, so the safe reading is the narrow one.", "sources": [ { "name": "NIST SP 800-63-4", "url": "https://pages.nist.gov/800-63-4/sp800-63.html", "type": "primary", "date": "2025-08-26" }, { "name": "SPIFFE documentation", "url": "https://spiffe.io/docs/latest/spiffe-about/overview/", "type": "primary", "date": "2026-09-15" }, { "name": "IETF Datatracker, draft-pidlisnyi-aps-03", "url": "https://datatracker.ietf.org/doc/draft-pidlisnyi-aps/03/", "type": "primary", "date": "2026-07-18" } ], "related_ids": [ "AAL-2026-0003", "AAL-2026-0013", "AAL-2026-0018" ], "tags": [ "open question", "identity", "credential" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0033", "slug": "how-does-a-sub-agents-authority-attenuate", "title": "How does a sub agent's authority attenuate", "kind": "question", "verdict": "open", "jurisdiction": "GLOBAL", "answer": "When one agent hands work to another, no adopted standard says the second may receive less authority than the first, or how a resource server at the end of the chain could check. Token exchange can record an actor, an Internet-Draft proposes chains that may only narrow, and the agent to agent protocol carries no identity at all.", "key_facts": [ "RFC 8693 lets a token record that one party is acting for another, but does not require the exchanged token to be narrower.", "The A2A documentation states that its payloads do not carry user or client identity information directly.", "The Agent Passport System Internet-Draft proposes delegation chains that cannot widen across seven constraint dimensions, and it is not an adopted standard.", "Singapore's framework notes that multi agent setups let each agent's tools and permissions be scoped separately, which is guidance rather than a mechanism." ], "facets": [ { "key": "delegation", "value": "No adopted standard requires that authority narrow as it passes from one agent to the next, and no resource server can verify a chain it cannot see.", "verdict": "open", "source": 0 } ], "what_it_changes": "If your design has one agent calling another, do the attenuation yourself. Mint a separate, narrower credential for each hop rather than passing the first one along, and record which principal each hop is acting for, because no protocol in production will do that for you today.", "sources": [ { "name": "RFC Editor, RFC 8693", "url": "https://www.rfc-editor.org/rfc/rfc8693.html", "type": "primary", "date": "2020-01-01" }, { "name": "A2A Protocol documentation, Enterprise Ready", "url": "https://a2a-protocol.org/latest/topics/enterprise-ready/", "type": "primary", "date": "2026-09-15" }, { "name": "IETF Datatracker, draft-pidlisnyi-aps-03", "url": "https://datatracker.ietf.org/doc/draft-pidlisnyi-aps/03/", "type": "primary", "date": "2026-07-18" } ], "related_ids": [ "AAL-2026-0010", "AAL-2026-0013", "AAL-2026-0017" ], "tags": [ "open question", "delegation", "multi agent" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] }, { "id": "AAL-2026-0034", "slug": "whose-spending-limit-is-it", "title": "Does a spending limit belong to the agent or to the principal", "kind": "question", "verdict": "open", "jurisdiction": "GLOBAL", "answer": "Card networks are building ways for a merchant to recognise an agent, and bankers are calling for transaction limits on agents. Nobody has settled whether a limit attaches to the agent, so it holds across every account it touches, or to the principal's account, so a second agent can spend the same money again.", "key_facts": [ "The Visa Trusted Agent Protocol addresses recognising an approved agent and its intent, and does not itself carry a spending ceiling.", "Press reports attribute to the State Bank of India's chairman a call for transaction limits as part of a know your agent discipline.", "The Agent Passport System Internet-Draft treats spend as one of the constraint dimensions a delegation chain may not widen, and it is not an adopted standard.", "No published rule states whether two agents acting for the same person share one limit or hold one each." ], "facets": [ { "key": "limits", "value": "Whether a spending ceiling is a property of the agent or of the account it draws on is unsettled, and the two answers give very different exposures.", "verdict": "open", "source": 2 } ], "what_it_changes": "Until this settles, set the limit in both places. Cap the agent in its own configuration and cap the account or card it draws on, because a control that exists only inside the agent is a control the agent can be talked out of by text it reads on a web page.", "sources": [ { "name": "Visa newsroom", "url": "https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21716.html", "type": "primary", "date": "2025-10-14" }, { "name": "The Tribune", "url": "https://www.tribuneindia.com/news/business/customer-engagement-productivity-and-risk-sbi-chair-details-three-focus-areas-for-agentic-ai-rollout/", "type": "secondary", "date": "2026-09-10" }, { "name": "IETF Datatracker, draft-pidlisnyi-aps-03", "url": "https://datatracker.ietf.org/doc/draft-pidlisnyi-aps/03/", "type": "primary", "date": "2026-07-18" } ], "related_ids": [ "AAL-2026-0019", "AAL-2026-0020", "AAL-2026-0026" ], "tags": [ "open question", "spending", "payments", "limits" ], "date_added": "2026-09-15", "last_verified": "2026-09-15", "last_modified": "2026-09-15", "figures": [] } ] }