Introduction — Three Tectonic Shifts in the 2026 IAM Landscape

IAM (Identity and Access Management) is a conservative field. Protocols a decade and a half old are still on active duty, and change is slow. Yet across 2025 and 2026, three tectonic plates moved at once.

1. **Passwordless became the default**: Passkeys went from "an option" to "the default." For new services, starting without passwords is now the more natural design, and identity-first security — the core Zero Trust proposition that identity, not the network perimeter, is the primary security boundary — has become the practical standard.

2. **The explosion of non-human identity**: Machine accounts have outnumbered human accounts for a long time, but with the arrival of AI agents the ratio is widening not by single digits but by orders of tens. What matters more than the quantity is the quality — agents act autonomously, receive delegated authority, and call other agents.

3. **Standardization of agent-to-tool connectivity**: As MCP (Model Context Protocol) became the de facto standard linking AI agents to tools and data sources, the question "how does an agent authenticate to my API" finally got an official, OAuth 2.1-based answer.

This post cuts across these three currents: the hard problems of AI agent authentication, the details of the [MCP authorization spec](https://modelcontextprotocol.io/specification/draft/basic/authorization), what the experimental CIMD support in Keycloak 26.6 signifies, implementing delegation chains with token exchange and transaction tokens, and verifiable credentials — a map for the IAM practitioner of 2026.

Non-human Identity — From Service Accounts to AI Agents

Traditional non-human identity (NHI) was comparatively easy to manage. Service accounts, API keys, and workload certificates have **deterministic behavior**. A batch job calls fixed APIs at fixed times. Workload identity standards like SPIFFE/SPIRE have tidied up this space well.

AI agents break that premise.

| Aspect | Traditional NHI (service account) | AI agent |

| --- | --- | --- |

| Behavior pattern | Deterministic, predictable | Non-deterministic, varies with the prompt |

| Permission scope | Fixed, narrow scopes | Dynamically needed per task |

| Delegation structure | Almost none (acts on its own authority) | Acts on behalf of users (on-behalf-of) |

| Lifetime | Long (months to years) | Short (per session/task) |

| Audit unit | Per service | Per user x agent x task |

| Attack surface | Key leakage | Key leakage + prompt injection + tool misuse |

In the workload space, [SPIFFE/SPIRE](https://spiffe.io/docs/) established the model answer of "secretless identity bootstrapping." Instead of having secrets injected at deployment, a workload goes through attestation based on runtime properties (Kubernetes ServiceAccount, node identity, etc.) and receives a short-lived SVID (X.509 or JWT).

Example SPIFFE ID:

spiffe://example.com/ns/payments/sa/payment-processor

Issuance flow:

workload ──(attestation: k8s SA, node)──> SPIRE Agent ──> SPIRE Server

^ │

└────────── short-lived SVID (auto-rotated) ───────────────┘

Agent identity should be built on the same principle — **short-lived credentials based on verifiable properties, instead of long-lived static secrets**. But unlike workloads, agents add the delegation dimension of "on whose behalf am I acting," so SPIFFE alone is not enough; it must be combined with the delegation mechanisms of OAuth.

Three hard problems follow.

Hard Problem 1 — The on-behalf-of Delegation Chain

In the chain "user jane instructed agent A, A called tool server B, and B called internal API C," on whose authority should C decide? Jane? A? Both?

The answer is "both." **You must track both the actor and the delegating subject.** If the agent inherits all of jane's permissions wholesale, that is over-privilege; if it uses only its own permissions, the audit trail breaks. The standard device for this is the act claim of token exchange (RFC 8693), covered below.

Hard Problem 2 — Dynamically Applying Least Privilege

Agent tasks are dynamic, so it is hard to pre-freeze "the list of permissions this agent needs." But handing out broad scopes means one successful prompt injection exfiltrates everything. The practical direction is a combination of **short-lived per-task tokens + fine-grained authorization (ReBAC/ABAC) evaluated in real time + human-in-the-loop approval**.

Hard Problem 3 — Audit and Attribution

From a regulatory standpoint, "the agent did it" is not an acceptable answer to "who performed this action." Every agent action must be attributable to (the delegating human, the agent identifier, the task context, the token chain used). If you do not design the log schema now, you cannot retrofit it later.

MCP Authorization — The OAuth 2.1-based Standard in Detail

[MCP (Model Context Protocol)](https://modelcontextprotocol.io/) is an open protocol connecting AI applications to tools and data sources. Through 2025 the MCP authorization spec was consolidated on an OAuth 2.1 foundation, and this became the de facto standard track for agent authentication.

The core structure: **the MCP server is an OAuth 2.1 resource server (RS), the MCP client is an OAuth client, and token issuance is handled by a separate authorization server (AS).** The fact that an MCP server does not mint tokens itself but can delegate to an existing IdP (e.g., Keycloak) is the key to enterprise integration.

The full flow:

MCP Client MCP Server (RS) Authorization Server

| | |

| 1. MCP request (no token)| |

|------------------------->| |

| 2. 401 + WWW-Authenticate| |

| (resource_metadata URL) |

|<-------------------------| |

| 3. GET /.well-known/oauth-protected-resource |

|------------------------->| |

| (returns authorization_servers list) |

| 4. GET /.well-known/oauth-authorization-server |

|---------------------------------------------------->|

| (AS metadata: endpoints, PKCE support, ...) |

| 5. Authorization Code + PKCE flow |

|---------------------------------------------------->|

| (resource parameter names the target MCP server) |

| 6. access_token (aud = MCP server) |

|<----------------------------------------------------|

| 7. MCP request + Bearer token |

|------------------------->| |

| token validation (aud, signature) |

Let us take the components apart.

Authorization Server Discovery

An MCP client has no prior knowledge of which AS to use, so it goes through two discovery steps.

1. **Protected Resource Metadata ([RFC 9728](https://datatracker.ietf.org/doc/html/rfc9728))**: The MCP server advertises its resource metadata URL via the WWW-Authenticate header of the 401 response; the client fetches it to learn the list of authorization servers protecting that resource.

{

"resource": "https://mcp.example.com",

"authorization_servers": ["https://sso.example.com/realms/agents"],

"bearer_methods_supported": ["header"],

"scopes_supported": ["mcp:tools:read", "mcp:tools:execute"]

}

2. **Authorization Server Metadata (RFC 8414)**: The client then fetches the well-known endpoint of the AS to obtain the authorization/token endpoints and supported features (PKCE, DCR, and so on).

Resource Indicators — Preventing Token Misuse

The MCP spec mandates [RFC 8707 Resource Indicators](https://datatracker.ietf.org/doc/html/rfc8707). When requesting a token, the client states "this token is for this MCP server" via the resource parameter, and the AS confines the aud (audience) of the token to that server.

POST /realms/agents/protocol/openid-connect/token HTTP/1.1

Host: sso.example.com

Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code

&code=AUTH-CODE-VALUE

&code_verifier=PKCE-VERIFIER-VALUE

&client_id=my-agent

&resource=https://mcp.example.com

What this blocks is the **confused deputy / token replay** class of attacks. Without resource confinement, a malicious MCP server could re-present a received token to a different MCP server. On the MCP server side, you must also **reject any token whose aud is not yourself**, and passing a received token through to upstream APIs (token passthrough) is explicitly forbidden.

OAuth 2.1 as the Foundation

That MCP chose the [OAuth 2.1 draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/) over OAuth 2.0 is significant. OAuth 2.1 consolidates RFC 6749 + PKCE (RFC 7636) + the Security BCP (RFC 9700), removes the Implicit and ROPC grants, and **mandates PKCE for every client**. In an environment where automated clients like agents appear at scale, the unsafe options were removed outright.

CIMD — Client ID Metadata Document and Keycloak 26.6

There is one point where the MCP ecosystem collides with a classic OAuth assumption: **client pre-registration**. With tens of thousands of MCP clients (agents, IDEs, desktop apps) meeting arbitrary MCP servers/ASes for the first time, a model where an administrator registers each client by hand cannot scale. Dynamic Client Registration (RFC 7591) exists, but opening anonymous registration creates the operational burden of garbage client registrations piling up.

The new answer to this is **CIMD (OAuth Client ID Metadata Document)**. The idea is simple — **use an HTTPS URL as the client ID** and host a client metadata document at that URL.

{

"client_id": "https://agent.example.dev/oauth/client-metadata.json",

"client_name": "Example Coding Agent",

"client_uri": "https://agent.example.dev",

"redirect_uris": ["https://agent.example.dev/oauth/callback"],

"grant_types": ["authorization_code"],

"response_types": ["code"],

"token_endpoint_auth_method": "none"

}

When the AS encounters a client_id (URL) it has never seen, it fetches the metadata from that URL, validates, and caches it. Even without pre-registration, you get client identity (anchored in domain ownership) and integrity of the redirect URIs.

That [Keycloak 26.6](https://www.keycloak.org/docs/latest/release_notes/index.html) began experimentally supporting CIMD is a strong signal. Unpacking the meaning:

- Keycloak has officially started targeting **the authorization server role in the MCP ecosystem**. Enterprises can extend the Keycloak realms they already operate into the authentication backbone for agents/MCP.

- Viewed together with the other 26.6 features — JWT Authorization Grant, Federated client authentication, FAPI 2.0 final support — you can read a course change from "an IdP for human logins" to "a unified trust anchor for humans + workloads + agents."

- It is a preview feature, so before production use you must review the feature flag and its limits (metadata caching policy, trust policy configuration).

Enabling preview features in Keycloak 26.6

/opt/keycloak/bin/kc.sh start \

--features=preview \

--hostname=sso.example.com

Hands-on — Protecting an MCP Server with Keycloak

Let us turn the concepts into code. Here is a minimal setup protecting an internal MCP server (say, an internal wiki search tool server) with a Keycloak realm.

First, prepare a client scope and audience for the MCP server.

1. Create a client scope representing the MCP server

/opt/keycloak/bin/kcadm.sh create client-scopes -r agents \

-s name=mcp-wiki \

-s protocol=openid-connect

2. Add an audience mapper — confine the token aud to the MCP server

/opt/keycloak/bin/kcadm.sh create \

client-scopes/SCOPE-ID/protocol-mappers/models -r agents \

-s name=mcp-wiki-audience \

-s protocol=openid-connect \

-s protocolMapper=oidc-audience-mapper \

-s 'config."included.custom.audience"=https://mcp-wiki.internal.example.com' \

-s 'config."access.token.claim"=true'

The MCP server side is an ordinary OAuth resource server. With Spring, the configuration looks familiar.

application.yaml — resource server settings of the MCP server

spring:

security:

oauth2:

resourceserver:

jwt:

issuer-uri: https://sso.example.com/realms/agents

audiences:

- https://mcp-wiki.internal.example.com

// Security config making aud validation + no-token-passthrough explicit

@Configuration

@EnableWebSecurity

public class McpSecurityConfig {

@Bean

SecurityFilterChain filterChain(HttpSecurity http) throws Exception {

http

.authorizeHttpRequests(auth -> auth

.requestMatchers("/.well-known/**").permitAll() // RFC 9728 metadata

.anyRequest().authenticated())

.oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()));

return http.build();

}

// Important: never forward the Bearer token this server received

// to upstream API calls. If upstream authority is needed,

// obtain a separate aud-confined token via token exchange.

}

And attach the header enabling RFC 9728 discovery to 401 responses.

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Bearer resource_metadata=

"https://mcp-wiki.internal.example.com/.well-known/oauth-protected-resource"

These four pieces — audience-confined issuance, issuer/aud validation, metadata publication, and no passthrough — are the skeleton of MCP server security.

Token Exchange and Transaction Tokens — Implementing the Delegation Chain

The tool for implementing agent delegation chains with standard tokens is [RFC 8693 Token Exchange](https://datatracker.ietf.org/doc/html/rfc8693). The agent takes the user token and exchanges it for a downstream-API token that is **scope-narrowed and actor-explicit (the act claim)**.

POST /realms/agents/protocol/openid-connect/token HTTP/1.1

Host: sso.example.com

Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange

&subject_token=USER-ACCESS-TOKEN

&subject_token_type=urn:ietf:params:oauth:token-type:access_token

&requested_token_type=urn:ietf:params:oauth:token-type:access_token

&audience=internal-api

&scope=tickets:read

The payload of the exchanged token spells out the delegation structure.

{

"iss": "https://sso.example.com/realms/agents",

"sub": "user:jane",

"aud": "internal-api",

"scope": "tickets:read",

"act": {

"sub": "agent:support-bot"

},

"exp": 1781234567

}

The sub remains jane (the delegator), while act.sub is the actual actor (the agent). As the chain deepens, act claims nest, preserving the entire delegation path inside the token. Audit logs simply record both values. Keycloak has officially supported standard token exchange (V2) since 26.2.

One step further is **Transaction Tokens (draft)**, under discussion in the IETF OAuth WG. At the gateway, the externally-presented token is exchanged for a **short-lived (minutes) internal token scoped to a single transaction**, preventing external tokens from circulating inside the microservice chain and propagating the user/agent context immutably along the entire call path. Particularly noteworthy for architectures where agents chain-call multiple internal services.

external gateway internal services

user/agent token ──────> exchanged at Token ──> txn-token (5 min TTL,

(1 h TTL, broad) Service (RFC 8693 style) transaction-scoped,

delegation chain claims)

A conceptual transaction token payload. The transaction identifier (txn), request context, and delegation chain are frozen immutably.

{

"iss": "https://txn-token-service.internal.example.com",

"aud": "internal-services.example.com",

"txn": "97f2dbd1-2275-4f4c-a8b3-1e9d2c4f5a6b",

"sub": "user:jane",

"exp": 1781234867,

"purp": "ticket-escalation",

"azd": {

"actor_chain": ["agent:support-bot", "svc:ticket-api"],

"client_ip": "203.0.113.10"

}

}

Verifiable Credentials — Decentralizing Identity

The other major current is **Verifiable Credentials (VC)**. The [W3C VC Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/) became an official Recommendation in 2025, and the EU [eIDAS 2.0](https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation) regulation obliges every member state to provide an EU Digital Identity Wallet, creating an enormous real-world use case.

The VC triangle:

Issuer Verifier

e.g., government, university, e.g., bank, service provider

employer

\ /

\ issues VC (signed) presents VP /

\ /

v v

Holder — the wallet app

stores credentials, presents selectively

The decisive difference from OIDC is that **the issuer does not need to be online at presentation time, and the issuer cannot track usage**. With selective disclosure (SD-JWT VC), minimal disclosure becomes possible — proving "is an adult" while hiding the birthdate. A simplified illustration of the SD-JWT concept:

{

"iss": "https://issuer.gov.example",

"vct": "https://credentials.example/identity_credential",

"cnf": {

"jwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." }

},

"_sd": [

"hash-of-given-name-disclosure",

"hash-of-family-name-disclosure",

"hash-of-birthdate-disclosure",

"hash-of-age-over-18-disclosure"

],

"_sd_alg": "sha-256"

}

The credential body contains only hashes of each attribute; at presentation time the holder encloses only the disclosures (plaintext + salt) of the attributes they choose to reveal. The verifier confirms integrity by hash comparison but learns nothing about undisclosed attributes. Holder binding is proven via the key in the cnf claim, blocking replay of stolen credentials as well.

The OpenID Foundation OID4VCI/OID4VP protocols are standardizing the issuance/presentation flows, and Keycloak is also growing experimental OID4VCI issuer functionality.

Near-term enterprise applications: B2C identity proofing (KYC reuse), employee onboarding (degree/employment verification), and B2B partner credentialing.

Identity Proofing in the Deepfake Era

Even if passkeys protect authentication, the whole edifice collapses if **identity proofing** — verifying "is this person really that person" at account opening or recovery — is weak. And identity proofing in 2026 sits in the middle of an arms race with generative AI.

- Video-call-based verification has been bypassed by real-time deepfakes in numerous reported cases. The social engineering that tricks helpdesks into resetting MFA (the pattern of the 2023 MGM incident) is now armed with voice/video synthesis.

- Countermeasures: document + biometric + **active liveness checks** (instruction-responsive), cross-checks against device signals, tiered procedures by NIST SP 800-63A IAL level, and multi-channel confirmation for high-risk operations (recovery, privilege elevation).

- The structural remedy is the VC stack discussed above. Accepting government-issued digital credentials presented from a wallet reduces the reliance on video-based verification altogether.

Redesigning helpdesk account-recovery procedures under the deepfake assumption — this may be the most underrated security task of 2026.

Agent IAM Anti-patterns — What to Stop Now

The newer the territory, the faster bad practice hardens. Anti-patterns already observed in the field:

1. **Sharing human accounts**: Handing an agent an employee username/password or a personal API token. The audit trail vanishes, the agent dies when the employee leaves, and a token leak exposes the full authority of a human. Agents must have independent identity + delegated tokens.

2. **The do-everything service account**: An entire agent platform calling every downstream system through one super service account. It becomes impossible to tell which agent ran which task, and least privilege is broken at the root.

3. **Long-lived static API keys**: A never-expiring key baked into an agent config file is game over the moment prompt injection leaks it. Short-lived tokens + automatic rotation is the baseline.

4. **Broad scopeless tokens**: Granting agents admin-scope tokens "just to make it work." Agent malfunction or misuse translates directly into whole-system damage.

5. **Trusting tool responses inside the boundary**: Indirect prompt injection — where the agent obeys instructions embedded in content returned by an MCP tool — is a new path to authorization bypass. Treat tool responses as external input, and gate permission-changing actions behind separate approval.

6. **MCP token passthrough**: An MCP server forwarding the token it received to upstream services violates the spec and is the shortcut to confused deputy. Always re-issue via token exchange.

What Practitioners Should Prepare Now — A Checklist

Finally, the currents above condensed into an actionable checklist.

**Inventory and governance**

1. Build an NHI inventory — service accounts, API keys, workload certificates, and agents. If you cannot answer "how many agent identities exist in our organization," that is task number one.

2. Define lifecycle policy (creation/entitlement/expiry/decommission) for agent identities separately from human accounts.

3. Add delegation chain fields (subject, actor, task context) to your audit log schema.

**Protocols and infrastructure**

4. Audit existing clients against OAuth 2.1 — remaining Implicit/ROPC usage, clients without PKCE.

5. Validate token exchange support in your IdP (Keycloak etc.) and turn the scope-down exchange pattern into a standard library.

6. If you operate MCP servers, implement RFC 9728 metadata, aud validation, and the token passthrough ban.

7. Evaluate experimental features like CIMD in Keycloak 26.6 in staging, and decide your agent client onboarding model (DCR vs CIMD).

**Security operations**

8. Keep agent token lifetimes short — per task, in minutes — and set refresh policies conservatively.

9. Put human-in-the-loop approval gates on high-risk tool invocations.

10. Threat-model your account recovery/helpdesk procedures against deepfake scenarios.

11. Track VC/digital wallet regulation (eIDAS 2.0, national digital ID schemes) quarterly, and assess VC acceptance in your KYC flows.

Closing Thoughts

IAM in 2026 is migrating from "a system where humans log in with passwords" to "a system where humans, workloads, and agents interact through verifiable identities and delegation chains." The good news is that this transition is happening not on brand-new technology but as **an extension of existing standards** — OAuth 2.1, token exchange, WebAuthn, VC.

So the best preparation is not flashy new tech adoption but fundamentals: confine tokens with aud, make delegation explicit with act, issue permissions short and narrow, and keep every decision auditable. Even in the age of agents, the principles of good IAM do not change — only the number of subjects they apply to explodes.

References

- [MCP Authorization Specification](https://modelcontextprotocol.io/specification/draft/basic/authorization) — the MCP authorization spec

- [OAuth 2.1 draft (draft-ietf-oauth-v2-1)](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/) — the OAuth 2.1 draft

- [RFC 8693 — OAuth 2.0 Token Exchange](https://datatracker.ietf.org/doc/html/rfc8693) — token exchange and the act claim

- [RFC 8707 — Resource Indicators for OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc8707) — the resource parameter

- [RFC 9728 — OAuth 2.0 Protected Resource Metadata](https://datatracker.ietf.org/doc/html/rfc9728) — protected resource metadata

- [RFC 9700 — Best Current Practice for OAuth 2.0 Security](https://datatracker.ietf.org/doc/html/rfc9700) — the OAuth Security BCP

- [Keycloak Release Notes](https://www.keycloak.org/docs/latest/release_notes/index.html) — 26.6 changes including CIMD

- [W3C Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/) — the VC 2.0 standard

- [EU Digital Identity Regulation (eIDAS 2.0)](https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation) — the EU digital identity regulation

- [NIST SP 800-63A — Enrollment and Identity Proofing](https://pages.nist.gov/800-63-3/sp800-63a.html) — identity proofing guidelines

- [SPIFFE Documentation](https://spiffe.io/docs/) — the workload identity standard

- [FIDO Alliance — Passkeys](https://fidoalliance.org/passkeys/) — passwordless transition resources