AAuth shows why agent identity needs native approval controls

At a glance

What this is: AAuth is a draft protocol for AI agent authentication and authorization that adds agent identity, delegated access, and optional human approval to agentic workflows.

Why it matters: It matters because IAM teams need patterns that govern agent actions without forcing humans to babysit every request, especially where delegated access and approval thresholds determine risk.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Aembit's guide to AAuth for AI agent identity and approval flows

Context

Agentic identity governance is the discipline of deciding how software entities authenticate, request access, and are approved to act when the actor is not a person. This article argues that OAuth and OIDC are not sufficient for that job because they were not built for AI agents that can request scope, trigger actions, and continue operating with a different risk profile than human users.

The practical gap is not just technical authentication. Teams need a way to represent agent identity, delegated user context, and approval state in one flow so that access is neither permanently overpermissive nor trapped in manual review loops that people eventually ignore.

AAuth is presented as a draft response to that problem, and the starting position it assumes is typical of many current agentic deployments: human review is bolted on after the fact rather than designed into the authorization path.

Key questions

Q: How do teams decide whether an AI agent needs human approval?

A: Use the sensitivity of the action, not the cleverness of the model, as the decision point. If the agent can change records, move funds, send external messages, or access regulated data, human approval or an independent policy engine should remain in the path. The more irreversible the action, the less autonomy the agent should have.

Q: Why do AI agents complicate OAuth and OIDC-based access models?

A: Because those models were built around user sessions, not software entities that can request, combine, and act on delegated permissions. When the agent and the human are separate actors, the policy engine must understand both identities and the action being authorised, otherwise access becomes overpermissive or opaque.

Q: What breaks when delegated access is not visible at the resource boundary?

A: Auditability breaks first, followed by policy enforcement. If the resource cannot see which agent acted, who it represented, and what scope was requested, reviewers cannot reliably explain or contain the action later. That gap makes incident response and access review much weaker than the authentication flow appears to suggest.

Q: What is the difference between approval built into authorization and manual review after the fact?

A: Approval built into authorization blocks credential issuance until the checkpoint is passed, so the action never starts without consent. Manual review after the fact only tells you what happened, which may be too late when the action is privileged, irreversible, or time-sensitive.

Technical breakdown

Agent identity in AAuth versus user identity in OAuth

AAuth extends familiar token-based identity patterns by giving the agent its own verifiable identity, rather than treating the agent as a proxy for a human session. That matters because access decisions become a three-part question: who the agent is, who it is acting for, and what the requested scope allows. Public keys, signed requests, and discoverable metadata make the agent cryptographically inspectable, while delegated context preserves the relationship to the user without collapsing the two identities into one.

Practical implication: identity teams need policies that bind agent identity and delegated user context together, rather than reusing user-session controls for autonomous software.

How human approval fits into the authorization flow

In this model, human approval is not a separate side process. It is part of the authorization path, which means the agent can request access but does not receive credentials until the approval step completes. That design reduces the chance that a high-risk action proceeds on default permissions alone. It also creates a policy boundary that can vary by scope, resource, or delegated user, rather than forcing a universal yes or no for every action.

Practical implication: approval controls should be tied to specific scopes and actions, not applied as a blanket manual checkpoint for all agent activity.

Combined tokens and delegated access visibility

AAuth combines access and identity claims in a single JWT so the resource can evaluate both authorization and attribution in one step. That is useful for auditability because the resource can see the agent, the user context, and the scope without stitching together separate lookups. The architectural tradeoff is that token design now carries governance meaning, not just transport convenience. If the claims model is weak, the control model becomes weak with it.

Practical implication: security architects should treat token claim design as a governance control, not just an implementation detail.

NHI Mgmt Group analysis

Agent identity cannot be governed as if it were a user session. AAuth makes that distinction explicit by separating agent identity from the person on whose behalf it acts. That matters because current IAM patterns often assume the authenticating principal and the operating principal are the same. Practitioner conclusion: the control model for agentic workloads must account for two identities in one transaction.

Human approval is a policy boundary, not a comfort blanket. The article shows why approval is only useful when it is reserved for actions with real reversibility or blast radius. If every request needs approval, people stop paying attention and the checkpoint loses value. Practitioner conclusion: approval thresholds should be based on action impact, not on discomfort with automation.

Scoped delegation is the named concept this article surfaces. AAuth points to a model where an agent acts with explicit user context and bounded permissions, rather than broad inherited authority. That is a stronger governance pattern than simply giving the agent a token and hoping downstream services infer intent. Practitioner conclusion: delegated access must be observable, bounded, and reviewable at the resource boundary.

OAuth and OIDC can be reused, but not unchanged, for agentic workloads. The article’s real signal is that familiar building blocks are not enough if the policy layer still assumes human-paced approval and static trust. The identity model survives, but the control assumptions do not. Practitioner conclusion: teams should expect extension points, not a straight transplant of user authentication patterns.

The governance question is shifting from whether agents can authenticate to when they should be allowed to proceed. That is a meaningful change for IAM and IGA teams because the policy decision now depends on task risk, scope drift potential, and the reversibility of the action. Practitioner conclusion: agent authorization needs a lifecycle view, not just a login view.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That is why OWASP NHI Top 10 remains relevant: the next step is controlling agent scope, not assuming the token model is enough.

What this signals

Scoped delegation: agentic identity programmes will increasingly be judged on whether they can separate actor identity, delegated authority, and approval state in one control path. That is the governance gap AAuth points toward, and it becomes more visible as teams connect agent workflows to higher-value systems.

With 96% of technology professionals already identifying AI agents as a growing security threat, per the AI Agents: The New Attack Surface report, the operational question is no longer whether to add human checkpoints. It is where those checkpoints still produce signal instead of fatigue.

Teams should expect agent authorization patterns to move closer to policy-based, resource-aware controls rather than static permit lists. That shift will pressure IAM, IGA, and PAM teams to define action-level thresholds, not just account-level access.

For practitioners

• Define approval thresholds by action risk Map which agent actions require human review based on blast radius, reversibility, and scope expansion. Start with privileged access, production changes, and bulk data operations, then document why each threshold exists so reviewers can apply it consistently.
• Separate agent identity from delegated user context Make sure your authorization design records both the agent principal and the human context it represents. This prevents audit logs from collapsing distinct actors into one session and helps downstream resources apply different policies to agents than to users.
• Treat token claims as governance inputs Review JWT claim sets, scopes, and resource metadata as control surfaces. If the resource cannot tell which agent is acting, on whose behalf, and under what scope, the policy model is incomplete.
• Limit approval fatigue with narrow checkpoints Reserve human-in-the-loop gating for the few actions that genuinely need it, and automate the rest. If every request becomes a review event, the approval process loses signal and operators begin to override it by habit.

Key takeaways

• AAuth reflects a real IAM gap: AI agents need identity and authorization models that distinguish them from the humans they represent.
• The hardest operational problem is not authentication, but deciding when human approval is worth the latency and when it just creates review fatigue.
• Practitioners should treat delegated access, token claims, and approval thresholds as governance controls, not implementation details.

Key terms

• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Human-in-the-Loop Approval: A review step where a person explicitly approves a high-risk access request before it is granted. It is most useful for exceptional privilege expansion, not for routine automation, because the goal is to catch unusual requests without turning every machine action into a manual process.
• Scoped Delegation: Scoped delegation is the practice of giving an agent time-bound authority limited to a specific task, resource, or condition. It prevents inherited access from becoming permanent and preserves accountability by recording who granted authority, what was granted, and when it expires.

What's in the full article

Aembit's full article covers the protocol mechanics and walkthrough details this post intentionally leaves for the source:

• Step-by-step AAuth bootstrap and key-publishing workflow for an agent identity
• The full three-party authorization flow, including the person server and resource token exchange
• Message-level examples of the pending approval state and how the agent polls for consent
• Implementation notes on GitHub Pages hosting, JWK publishing, and the local CLI demo

👉 Aembit's full article walks through the protocol flow, token exchange, and consent mechanics in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.