AI Agents Get Their Own Keys to the Kingdom
Keycloak · release
Keycloak is the front desk of the open-source identity world. It is the one system that checks IDs, hands out wristbands, and remembers who is allowed where — so your fifty applications do not each have to build their own sketchy door policy. One login server, every app onboard.
The pain it removes is real: passwords everywhere, forgotten reset flows, and that one legacy app still authenticating against a spreadsheet. Teams self-host it for single sign-on, wire it to Google and Microsoft logins, and lean on it whenever something needs to speak OIDC or SAML. If you have ever logged into a company portal, decent odds Keycloak was involved.
Version 26.8.0 is a big one. This release gives AI agents their own scoped, consent-based credentials, lets users log in by showing a credential from a digital wallet, and moves multi-cluster session storage into the database. Think of a hotel that issues key cards instead of room keys, gives each robot assistant its own limited card, and finally remembers who was locked out — even after a power cut.
What Is New
AI agents finally get their own hall pass
The problem: you want an AI agent or automation tool to act on your behalf, but your options were handing over your password (no), giving it admin rights (please no), or building custom plumbing (expensive). Keycloak 26.8.0 adds token exchange delegation, now in preview, where a user explicitly delegates scoped access to a client through plain OAuth consent.
The mechanics are refreshingly paranoid. The user consents to the new delegation:client:<client-id> parameterized scope, and the resulting token carries an act claim naming the client as the actor. Authorization runs exclusively through Fine-Grained Admin Permissions V2, every delegation emits audit events with the client identity, and a leaked delegation token cannot escalate into the Admin API even if the client holds service-account credentials.
# the scope a user consents to when delegating to a client
delegation:client:<client-id>
# the token then carries an act claim identifying the client as the actorAdmins keep the last word: a new client policy executor restricts which clients may appear in the may_act claim, so delegation participants are controlled per client. Delegation for clients ships in issue #51305, with the dedicated delegation permission in issue #51481.
Log in with your wallet, not your password
Verifiable credentials are the “show, do not tell” of identity. Instead of typing a password, your phone holds a cryptographically signed credential and presents it. Keycloak 26.8.0 now plays both sides of that exchange.
Issuing side: OID4VCI — OpenID for Verifiable Credential Issuance — is promoted from experimental to preview, enabled with --features=preview or --features=oid4vc-vci. It gains full credential lifecycle management: revocation when refresh tokens are revoked, an in-session action for users to request credential issuance, hardened key attestation following the HAIP profile, and experimental mdoc support — the format used by mobile driver’s licenses.
# enable verifiable credential issuance (now preview)
--features=oid4vc-vciVerifying side: a new experimental OID4VP verifier lets users log in by presenting a credential from their wallet, no password involved. It supports cross-device flows and the direct_post.jwt encrypted response mode, with SD-JWT mappers to lift claims out of presented credentials. Encrypted response support landed in issue #50644, and there is a quickstart deployment if you want to poke at it today.
The session cache moves into the database
Running Keycloak across sites used to require an external Infinispan cluster — a second distributed system whose only job was remembering who logged in. That is two stateful things to operate, monitor, and panic about at 3 a.m.
Multi-cluster v2 drops the external cache entirely. Session data lives in the database, the feature is now supported, and you enable it with a single flag. The old multi-cluster v1 (multi-site) approach is deprecated and will be removed in a future major release, and there is a published migration guide.
# before: multi-cluster v1 (deprecated)
--features=multi-site
# after: multi-cluster v2 (supported)
--features=statelessOne flag deletes an entire distributed system from your architecture diagram. That is the best kind of feature.
Small print worth knowing: login failures are now persisted in the database by default, so brute-force lockouts survive restarts (the in-memory variant is deprecated — see issue #52126). Index creation for large tables also runs automatically in the background after startup on PostgreSQL, Oracle, MySQL/MariaDB, and supported SQL Server editions.
The quiet enterprise wins
Three more promotions make life noticeably easier for anyone running Keycloak at work:
- SCIM API is now supported. The standards-based interface for provisioning users and groups gained multivalued attributes, User Profile permissions, and serious performance work for large user bases — the serialization path alone stopped creating ~200x more UserProfile objects than necessary (issue #51400).
- Client Secret Rotation is now supported. Confidential clients keep up to two concurrently active secrets, so quarterly rotation no longer requires a maintenance window and a prayer (issue #16738).
- Admin API v2 hits preview with strict validation, declarative configuration, and an accurate OpenAPI spec — and the Keycloak Operator can now manage clients declaratively through KeycloakOIDCClient and KeycloakSAMLClient custom resources, enabled with
--features=client-admin-api:v2. GitOps people, enjoy (Admin API v2 guide).
Security Fixes
This release also patches seven assigned vulnerabilities. None are listed as actively exploited, but if you run Keycloak in production, this week is a good week to upgrade:
- CVE-2026-12388 — IdP mapper admin role escalation in identity brokering (issue #50444)
- CVE-2026-14781 — OIDC broker applied the id_token’s email_verified to the userinfo email, marking unverified addresses as verified (issue #50618)
- CVE-2026-19608 — name-only group claims let same-name groups satisfy path-specific group policies (issue #51865)
- CVE-2026-54515 and CVE-2026-59889 — jackson-databind upgraded to 2.22.0 (issue #52168)
- CVE-2026-59903 — netty-codec-http upgraded to 4.1.136.Final (issue #52169)
- CVE-2026-4633 — user enumeration via identity-first login when the Organizations feature is enabled (issue #52676)
On top of those sit roughly eighty hardening fixes — SCIM validation gaps closed, OID4VCI attestation tightened, SSRF guards for cluster node registration, and several fine-grained permission bypasses shut. If you are upgrading, read the upgrading guide first; multi-cluster v1 users in particular have a migration ahead of them.