TL;DR: AI agents are gaining autonomy and acting on behalf of users, but most identity and authentication systems were built around a human at the keyboard, according to Stytch. Extending OAuth-style delegation, auditable consent, and ephemeral credentials becomes a governance problem, not just an integration choice, because existing trust models assume direct user interaction and stable approval flows.
NHIMG editorial — based on content published by Stytch: Agent ready episode 4 on identity, auth, and consent for AI agents
Questions worth separating out
Q: How should security teams govern AI agent access without relying on human-centric approval flows?
A: Security teams should treat AI agents as delegated actors with explicit scopes, short-lived credentials, and auditable consent records.
Q: Why do existing IAM models struggle with AI agent identity?
A: Existing IAM models struggle because they assume a human is directly present to approve access, understand the risk, and carry the accountability.
Q: What should organisations do with consent when agents can act across multiple tool calls?
A: Organisations should store consent as a durable record that survives beyond a single session and describes the exact scopes, resources, and expiration conditions granted to the agent.
Practitioner guidance
- Separate human approval from agent execution Design flows so the approval event and the agent’s runtime actions are distinct, with explicit records of what was approved and what was actually executed.
- Bound MCP tool exposure to specific trust zones Classify every MCP server and exposed tool by data sensitivity, identity boundary, and allowed actor type.
- Issue short-lived credentials for agent sessions Use ephemeral credentials that expire before broad reuse is possible, and tie them to a narrowly defined task scope.
What's in the full article
Stytch's full video covers the implementation detail this post intentionally leaves for the source:
- Walkthroughs of the OAuth-style delegation flow for agent access and consent handling
- A live demo of how agent-ready authentication behaves in practice inside an application
- Discussion of where current standards are sufficient and where new primitives may still be needed
- Examples of how to expose application data to agents without coupling security to the UI
👉 Read Stytch's analysis of identity, auth, and consent for AI agents →
AI agent identity and consent for agents: what IAM teams need?
Explore further
AI agent consent is now an identity governance problem, not just an auth pattern. The article shows that once software can act on a user’s behalf, the core issue becomes whether that action is still tied to a defensible consent record and a bounded delegation scope. That changes the governance burden for IAM, IGA, and PAM teams because approval is no longer a one-time login event. Practitioners should treat agent consent as an access lifecycle control, not a UI flow.
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 (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), 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: Who is accountable when an AI agent accesses data outside the intended scope?
A: Accountability should rest with the organisation that granted the delegation and with the control owners who defined the access boundaries. If scopes are too broad, consent is unclear, or revocation is weak, the failure is a governance one, not just a user mistake. Agent access needs explicit ownership in IAM and IGA.
👉 Read our full editorial: AI agent identity and consent expose gaps in existing auth models