KeyConf26 turns Keycloak’s next operator questions toward scale, signals and AI authorization

The KeyConf26 programme is less a list of product announcements than a map of the identity problems Keycloak users are trying to solve next: larger estates, faster security-event exchange, workload identity without stored secrets, and authorization across applications and AI agents.

That distinction matters. The event is scheduled for October 8 in Prague, and its session abstracts describe techniques, experiments and production experiences. They should not be read as commitments that every capability is generally available in Keycloak.

Scale changes the operating model

CERN’s session is the clearest production-scale marker. Its abstract describes a Kubernetes-hosted Keycloak deployment serving more than 14,000 clients and about 140,000 login events per day, with a focus on performance, reliability and operational security. A second session describes a migration in which a Keycloak-based platform is taking over applications one by one while coexisting with a legacy identity system across more than 20 million identities.

For operators, those talks move the useful questions beyond replica count. Teams evaluating Keycloak at this scale should ask how they will preserve authorization equivalence during migration, test failure modes, control extension debt and decide which gaps belong in local code versus upstream contributions. The agenda does not supply universal sizing guidance; it offers case studies from which those questions can be tested.

Shared signals shorten the response loop

The OpenID Shared Signals Framework session proposes event-driven exchange between identity providers and relying parties for events such as session revocation and credential compromise. Its abstract also names CAEP and RISC and discusses possible Keycloak support.

The practical consequence is architectural: an application estate that relies only on token expiry can leave a gap between discovering risk and withdrawing access. Shared signals could give platform teams a standard channel for acting sooner, but adopting one would also require decisions about event authenticity, delivery failure, replay handling and which relying parties may consume which signals. The session is an introduction and exploration, not evidence that production-ready Keycloak support has shipped.

AI integration is becoming an identity deployment question

Two sessions connect Keycloak directly to agent systems. The first says the presenters will cover Client ID Metadata Document support for newer Model Context Protocol client onboarding, experimental Identity Assertion JWT Authorization Grant support, and Enterprise-Managed Authorization patterns for centrally controlling access to MCP servers. A separate IBM session addresses identity propagation across trust domains using token exchange and assertion grants for applications and AI agents.

For application teams, that shifts the design decision away from simply placing an API key in an agent runtime. The agenda’s proposed pattern keeps Keycloak in the authorization path, preserves user context across domains and issues access scoped for the target service. Before adopting it, teams will need to verify the status of each experimental feature, establish trust between issuers, constrain token audiences and test what happens when an asynchronous chain is retried or partially fails.

What teams can do before October

The programme gives platform teams three useful preparation tasks: inventory oversized or over-privileged access tokens; identify applications where revocation waits on token expiry; and map agent-to-tool calls that currently depend on static credentials or lose the originating user’s identity.

That work does not depend on a conference promise. It gives operators a concrete baseline against which to evaluate the KeyConf26 demonstrations—and helps separate deployable Keycloak capabilities from emerging standards that still need implementation and hardening.