AI agents authenticating on behalf of customers.
Who feels it
engineeringsecuritylegal
What triggers the evaluation
an AI agent begins acting for users · an MCP integration · a consent review for agent access
The newest operational pressure is AI agents authenticating on behalf of customers. Current CIAM consent and session models were not designed for a third principal: until recently you modeled users, tenants, and machine-to-machine clients, and an agent acting for a user fits none of them cleanly. The failure mode is reuse: the agent rides the user's own session or a shared service token, which means it can do anything the user can, with no way to scope it and no way to tell its actions apart from the human's in the audit log.
Treating the agent as a first-class principal is the fix. It needs a scoped, attenuated token distinct from the user's session, so it can be granted exactly the permissions the task requires and no more, and the audit trail has to separate agent actions from human ones so an incident can be reasoned about. Consent has to evolve too: purpose-specific consent that expresses what an agent is permitted to do for a user, not a blanket grant.
This is the axis the market is moving on fastest, and it is where CIAM Compass scores vendors ahead of the rest of the field. Probe MCP support, agent-versus- human token separation, OAuth 2.1 patterns, and purpose-specific consent directly. See authentication for AI agents and the agentic-identity axis on every vendor profile.
How teams recognize it
- Agents reuse a user's own session or a shared service token
- There is no way to scope or attenuate what an agent may do on a user's behalf
- Audit logs cannot distinguish an agent action from a human one
- Consent models never contemplated a third party acting for the user
How to evaluate vendors for this
The exact questions to put to vendors. Match each answer against the capabilities in the comparison below.
- 01Can you issue scoped, attenuated tokens for an agent acting on a user's behalf?
- 02Do you separate agent identity from human identity in tokens and audit logs?
- 03Do you support MCP and OAuth 2.1 patterns for agent authorization?
- 04How does consent express what an agent is permitted to do for a user?
Capabilities that solve this
The vendors that cover the capabilities this pain maps to, scored on just those axes. See the full matrix on each vendor profile.
| Capability | Curity75% covered | Descope75% covered | Ping Identity75% covered | Ory63% covered | Akamai Identity Cloud50% covered | ForgeRock50% covered | IBM Verify50% covered | Microsoft Entra External ID50% covered |
|---|---|---|---|---|---|---|---|---|
| MCP support | ~ Partial | ✓ Yes | ~ Partial | ~ Partial | ✕ No | ✕ No | ✕ No | ~ Partial |
| Agent vs human token separation | ~ Partial | ~ Partial | ~ Partial | ~ Partial | ✕ No | ✕ No | ✕ No | ~ Partial |
| OAuth 2.1 | ✓ Yes | ✓ Yes | ✓ Yes | ✓ Yes | ✓ Yes | ✓ Yes | ✓ Yes | ✓ Yes |
| Purpose-specific consent | ✓ Yes | ~ Partial | ✓ Yes | ~ Partial | ✓ Yes | ✓ Yes | ✓ Yes | ✕ No |