TL;DR: AAuth proposes draft authentication and authorization patterns for AI agents that combine verifiable agent identity, delegated access, and optional human approval, according to Aembit, highlighting why OAuth and OIDC alone leave agentic workloads overpermissive. The deeper issue is that approval fatigue and scope ambiguity expose a governance model built for human-paced access decisions, not runtime agent behaviour.
NHIMG editorial — based on content published by Aembit: AAuth and human approval for AI agents
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.
- 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.
Questions worth separating out
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.
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.
Q: What breaks when delegated access is not visible at the resource boundary?
A: Auditability breaks first, followed by policy enforcement.
Practitioner guidance
- Define approval thresholds by action risk Map which agent actions require human review based on blast radius, reversibility, and scope expansion.
- Separate agent identity from delegated user context Make sure your authorization design records both the agent principal and the human context it represents.
- Treat token claims as governance inputs Review JWT claim sets, scopes, and resource metadata as control surfaces.
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
👉 Read Aembit's guide to AAuth for AI agent identity and approval flows →
AAuth and human approval for AI agents: what changes now?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AAuth shows why agent identity needs native approval controls