Authorization and traceability for the actions of non-human identities in regulated organizations — settled ground, open drafts, and a sequencing heuristic
Organizations in regulated sectors, such as insurers, banks and public agencies, are starting to let AI agents act routinely: read documents, invoke tools, update records, hand tasks over to other agents, execute transactions. Each such action is taken on someone's behalf — a human's or another agent's — across heterogeneous systems that were not built to share identity models or policies.
The identities and credentials these agents need — ideally per task rather than per deployment — belong to a category the identity discipline already names: non-human identities (NHI). The term covers the service accounts, API keys, tokens, workload certificates and CI/CD pipeline credentials that systems use to authenticate and authorize. What is new is not that such credentials are issued to software. It is that the software holding them now decides by itself what to do next — partly on the basis of content it has just acquired or generated, sometimes moments before the decision.
This raises three questions, which the present document addresses:
(1.1) At the end of a workflow in which agents and tools branch and merge, how can an organization establish who or what authorized an action, and on whose behalf it was performed?
(1.2) How can confidence in the input that led to the action be evaluated and accounted for?
(1.3) Which parts of the relevant standards are currently settled enough to build on?
Out of scope here, among other topics: (a) consumer-facing agents and customer IAM; (b) model safety and content filtering, except where they become authorization questions.
A system that can answer (1.1) and (1.2) needs the following properties.
2.1 Attribution. Every action an agent takes is traceable to a human or organizational principal and to the chain of actors in between. A downstream system that sees only “the agent's service account” has lost the answer.
2.2 Delegation without shared secrets. The component that acts never holds the user's password or long-lived credential. It holds a delegated, narrowed, short-lived token.
2.3 Decisions outside the interpreting component. The policy decision is not made by the component that reads untrusted input. The subsection “Where the analogies break” below explains why this is the one genuinely new requirement.
2.4 Approval that says what is approved. For consequential actions, a human confirms on a channel the agent does not control — and the approval names the specific action, not merely a sign-in.
2.5 Lifecycle. Agents have owners, joiner/mover/leaver events, recertification and an end date. An agent whose owner has left is an orphaned identity and needs cleanup, just like a stale user account.
2.6 Replaceability. Wherever the governing standard is still a draft, the design isolates it behind a seam that can be swapped without redesigning the rest.
Several older patterns cover most of these requirements.
Delegated credentials down a chain. Grid computing
faced multi-hop delegation for unattended processes twenty years ago. A
user created a short-lived proxy certificate carrying virtual-organization
attributes — in gLite, with voms-proxy-init — and the job
system passed it onward to act on the user's behalf. Its failure modes are
today's: proxies stolen from shared nodes, lifetimes stretched for
convenience, credential repositories that became high-value targets. Today
these are called persistent blast radius, token sprawl, and credential
vaults for agents.
A gate at the source. Identity management fed by HR systems has always received input of differing quality from systems that share no data model. The working answer is a canonical model, an explicit tolerance for lower-quality sources, and an automated gate that rejects what cannot be attributed. An agent's delegation chain needs the same three things.
Controls that do not depend on the application. Data-centric security encrypts sensitive fields under identity-bound keys, so that access is decided at key release, outside the application. Whoever cannot obtain the key cannot read the field — whatever the application does.
An HR feed does not take instructions from its own records, and a grid job does not rewrite its plan because of the data it processes. An agent does: a document it reads can redirect it. That is prompt injection, and in authorization terms it is the confused deputy in new form — a component with legitimate rights persuaded to use them for someone else. Hence requirement 2.3: the gate must sit outside the component that interprets the input. A model cannot be its own policy decision point.
| Building block | Status | Serves |
|---|---|---|
| Authorization Code with PKCE (RFC 7636), native-app pattern (RFC 8252) | Settled; PKCE required by OAuth 2.1 and by MCP | 2.2 — the client obtains a delegated token through the system browser and never sees the user's secret |
| Device Authorization Grant (RFC 8628) | Settled | 2.1, 2.2 — delegated, decoupled sign-in for clients without a usable browser. Phishable: the user approves a sign-in whose initiator they cannot verify |
Token Exchange (RFC 8693), act
claim |
RFC; adoption immature | 2.1 — records nested delegation: who authorized, which actors acted |
| AuthZEN Authorization API 1.0 (OpenID Foundation) | Final, January 2026 | 2.3 — a standard interface between enforcement points and an external decision point; what policy-based access control has lacked |
| CIBA Core 1.0 with Rich Authorization Requests (RFC 9396) | Final; RFC | 2.4 — approval pushed to a separate channel, scoped to a precisely described action |
| MCP, revision 2026-07-28 | Published | Agent-to-tool access over OAuth: PKCE required, token passthrough forbidden, dynamic client registration deprecated in favor of client ID metadata documents |
| A2A 1.0 | Published; authentication only partly specified | Agent-to-agent delegation — the layer where identity is least settled |
| OAuth 2.1 | Draft | Consolidates current practice; build to it, cite the RFCs |
| Identity Chaining Across Domains; Transaction Tokens | Drafts (the first in the RFC Editor queue) | 2.1 across organizational and service boundaries — open questions |
| SCIM extensions for agents | Individual drafts only; not adopted by the working group | 2.5 — lifecycle provisioning for agents — open question |
Settled versus draft. The pattern is plain: one final specification for authorization decisions, two published agent protocols, a set of established RFCs repurposed — and nearly everything agent-specific still in draft.
Governance of the standardization initiatives is part of the assessment. MCP began as one vendor's protocol, which is a procurement risk. It has sat with the Agentic AI Foundation under the Linux Foundation since December 2025, and A2A has joined it since August 2026; the foundation's members include the major cloud and model providers. That makes building on them a governance decision an architecture board can defend, even while their authorization profiles are still moving.
The EU AI Act requires high-risk AI systems to record events automatically, to the extent needed for a level of traceability of their functioning appropriate to their purpose (Article 12). Its Annex III counts risk assessment and pricing in relation to natural persons in life and health insurance among the high-risk uses. Since the Digital Omnibus on AI (Regulation (EU) 2026/1744, in force 27 July 2026), the obligations for Annex III systems apply from 2 December 2027.
The conformity machinery has started, but only just. Commission Implementing Decision (EU) 2026/2274 cited the first harmonised standard, EN 18286, in the Official Journal on 14 October 2026. It covers quality management (Article 17). No harmonised standard yet covers logging, human oversight or cybersecurity; providers must demonstrate those by their own means.
An agent is not high-risk because it is an agent; it becomes so through its use. But where it is, the reading offered here is this: for an agent acting on someone's behalf, a log that records what the system did — but not on whose behalf, under which delegation and which policy decision — offers little traceability. Protocol design and regulation are arriving at the same requirement, attributable action, from opposite directions, and neither yet supplies a finished answer. The months until December 2027 are the window to build one.
act claim where the identity provider
supports it.The patterns in Section 2 are not borrowed. I worked with gLite middleware and VOMS proxy certificates, which carry virtual-organization attributes, in grid computing between 2006 and 2010.
In a cross-agency federal identity management project, I co-designed a core and a relaxed schema for HR data of differing quality, with automated quality measures that rejected input batches below a defined threshold, and built the ingestion pipeline myself.
At proof-of-concept level, I encrypted database columns under separate identity-based keys, with user access orchestrated through roles. The encryption was format-preserving and targeted the common relational databases as well as Hadoop.
In another proof of concept, I replaced the password dialogue of an unmodifiable legacy application with an authorization code flow with PKCE over a loopback redirect. That application was later brought under Entra ID single sign-on, in an integration that now runs in production at two customers, with a third in testing; on-premises Keycloak-based SSO was built alongside it as proofs of concept. Ongoing work includes Entra ID tenant administration over Microsoft Graph with the device authorization grant.
None of the examples here amounts to agentic IAM at enterprise scale, and no comprehensive implementation can be completed before the standards are. But regulated organizations are designing for it now, and that design can draw on experience that already exists. What carries over are the problems — and the discipline of knowing which parts are settled enough to build on.