« Blog Home

What’s New in Keycloak in 2026? Stronger Security for Users, Applications and AI Agents

Keycloak’s 2026 releases introduce new capabilities for securing applications, managing identities and controlling access across organizational systems.
They also provide useful building blocks for organizations adopting AI assistants and AI agents.

keycloak logo

For customers already using Keycloak for Single Sign-On (SSO), the updates offer opportunities to reduce reliance on static credentials, automate identity administration, strengthen authentication and simplify maintenance.

For organizations deploying AI agents, the central question is becoming more important:
How do we identify an agent, limit its permissions and understand whose behalf it is acting on?

Several Keycloak updates help address these requirements, and we (ALM Toolbox) are experienced in help you plan and deploy it.

This article reviews the features and enhancements announced between January and October, 2026, covering Keycloak 26.5 through 26.8 and relevant security patches. At this cutoff, the latest upstream release is Keycloak 26.8.1.

A note about availability: Some capabilities are Supported, while others remain Preview or Experimental. These distinctions matter when planning production deployments. A supported feature may still require configuration, and upstream feature support is separate from a commercial support agreement.

Fewer Static Secrets for Applications and AI Agents

One of the most useful developments is the maturation of Federated Client Authentication.

Following enhancements in Keycloak 26.5, authentication using external OpenID Connect issuers and Kubernetes service accounts became Supported in 26.6. SPIFFE integration remains Preview.

Applications can use credentials issued by a trusted identity provider to authenticate to Keycloak, reducing the need to maintain separate, long-lived client secrets.

How does this improve security?

Every static secret creates another credential that must be stored, protected, rotated and eventually removed. Secrets can accidentally appear in repositories, configuration files, troubleshooting output or application logs.

Federated authentication can reduce this exposure by using short-lived credentials from an established workload identity system.

For example, an AI worker running in Kubernetes could authenticate using a dedicated service account instead of sharing a permanent client secret with other applications. Its permissions would still need to be restricted to the APIs and operations it requires.

Keycloak 26.8 also improves issuer discovery for managed Kubernetes environments such as Amazon EKS, Google GKE and Microsoft AKS.

For technical details, see Keycloak’s explanation of Federated Client Authentication.

More Control Over Tokens and Client Credentials

Keycloak 26.5 introduces JWT Authorization Grant as Preview, and 26.6 promotes it to Supported.

This allows Keycloak to accept signed JWT assertions from a trusted external provider and issue local access tokens. It can help integrate applications operating across identity domains without passing a user’s password between systems.

Security depends on correctly configuring the trust relationship, validating the assertion and limiting the resulting token’s permissions.

Two additional changes help organizations manage application credentials:

  • Client-secret lookup through the Vault SPI, added in 26.6, allows client secrets to be resolved through Keycloak’s vault extension interface.
  • Client Secret Rotation, promoted to Supported in 26.8, allows an overlap between the old and new secrets while applications transition.

The practical benefit is more manageable credential replacement with less disruption. Organizations should validate how their chosen secret-storage integration interacts with rotation; Vault SPI does not mean that every secrets manager has a bundled connector.

Better Authorization for MCP Servers and AI Tools

The Model Context Protocol (MCP) allows AI applications to connect to external tools and data sources. These connections need enforceable access controls, particularly when tools expose internal systems.

Keycloak’s MCP-related work progresses throughout 2026:

  • 26.5: A dedicated MCP authorization-server integration guide.
  • 26.6: Experimental support for OAuth Client ID Metadata Documents, or CIMD.
  • 26.7: Expanded integration guidance for clients such as Claude Code and Visual Studio Code.
  • Current documentation: Additional guidance covering Claude Desktop and Experimental Resource Indicators.

CIMD allows Keycloak to retrieve client metadata from a controlled URL. Resource Indicators help associate an access token with its intended resource server.

Why does this matter for AI security?

Consider an assistant that connects to both a documentation service and a deployment service.

A token intended for the documentation service should not automatically work against the deployment service. Binding tokens to the intended audience, combined with validation by each server, helps maintain that separation.

The MCP server must also enforce the permissions associated with the request. Authentication alone does not determine which tools or actions an agent may use.

The maturity distinction is important: Keycloak’s current guide classifies conformance with the newer MCP specifications – including 2025-06-18, 2025-11-25 and 2026-07-28 – as Experimental.

See the official Keycloak MCP integration guide for the version-specific requirements.

Delegating Access Without Losing the Agent’s Identity

Token Exchange Delegation is particularly relevant to AI agents.

Introduced as Experimental in 26.7 and promoted to Preview in 26.8, it allows a user to authorize another actor to act on their behalf. The 26.8 implementation adds client delegation, user consent and authorization through Fine-Grained Admin Permissions V2.

Delegated tokens identify both the user and the actor.

For example, an engineering assistant could act for a developer when interacting with an internal service. The service could record that the assistant performed the action for that developer, rather than attributing everything directly to the human.

This creates a stronger basis for auditing and restricting automated activity.

However, the client’s scopes and audiences still require careful configuration, and the receiving API must enforce them. Client delegation does not grant access to the Keycloak Admin API.

Version 26.8 also improves impersonation auditing by adding actor information to tokens and related events.

Parameterized scopes

Parameterized scopes advance to Preview in 26.8, following typed parameter validation in 26.7.

A scope such as project:12345 can carry a resource context without requiring administrators to create a separate scope definition for every project.

This can be useful for agent integrations operating across many resources. The application must still check that the caller is authorized to access the specified project.

More information is available in the token exchange and delegation documentation.

Automated Onboarding, Offboarding and Account Maintenance

Keycloak’s Workflows capability moves from Preview in 26.5 to Supported in 26.6, building on an experimental implementation introduced in 2025.

Workflows allow administrators to define processes triggered by events, conditions and schedules. They can help standardize identity administration and reduce dependence on manual tasks.

Version 26.8 adds an invite-user step that sends an invitation with required actions, such as verifying an email address or setting a password.

From a security perspective, these capabilities can help organizations:

  • Follow up on inactive accounts.
  • Apply consistent onboarding procedures.
  • Remove access when responsibilities change.
  • Reduce the time between an organizational change and its implementation in identity systems.

Workflows are privileged automation. Conditions that grant access should rely on information users cannot manipulate themselves.

SCIM becomes Supported

Keycloak adds Preview SCIM capabilities in 26.7 and promotes them to Supported in 26.8.

**SCIM – System for Cross-domain Identity Management – **provides a standard interface for external systems to manage users and groups in Keycloak.

Capabilities include user and group operations, filtering, pagination, PATCH requests and schema extensions. Version 26.8 improves attribute handling, permission enforcement and performance.

This can simplify integration with identity governance systems and provisioning platforms. It is an inbound provisioning API, rather than a universal connector that automatically provisions every downstream SaaS application.

For AI-enabled applications, consistent offboarding helps remove the human access on which delegated activity depends. Application sessions, existing tokens and independent agent credentials must also be considered.

More Precise Administration for Organizations and Customers

Keycloak’s organization capabilities expand across several releases:

  • 26.6: Organization-specific group hierarchies and identity-provider mapping.
  • 26.7: Organization administration roles, finer administrative permissions and role inheritance through organization groups.
  • 26.8: Shared identity providers across organizations, with separate membership settings and domain-based routing.

These improvements are useful for B2B applications, customer portals and organizations serving multiple business units.

For example, a customer administrator can be given authority over their own organization without receiving broad realm-management privileges.

This supports the principle of least privilege and can reduce the impact of an administrator account being compromised. Applications must still enforce their own tenant boundaries.

Safer access to external identity-provider tokens

Identity Brokering API V2 becomes Preview in 26.6 and Supported in 26.7.

It introduces client-specific authorization for retrieving external identity-provider tokens, requires confidential clients and supports storing external tokens in user sessions.

This matters when an application or agent backend needs credentials to call another service. Access to those credentials can be restricted to the relevant integration.

V2 is disabled by default, so an upgrade alone does not migrate an existing deployment.

Stronger Authentication and Session Management

Several updates strengthen everyday authentication and account controls.

SAML step-up authentication becomes Supported in 26.7 after its Preview introduction in 26.6. A SAML application can request a stronger authentication context for sensitive operations.

For example, an organization could design an approval process that requires stronger human authentication before an agent-requested production change proceeds. The approval workflow must be implemented by the application; Keycloak does not add it automatically.

Other improvements include:

  • Better passkey compatibility: New discoverable-credential policy options in 26.7 provide more flexibility across authenticators.
  • LDAP password-change enforcement: An optional setting introduced in 26.6 allows Keycloak to honor a directory’s mandatory password-change indication.
  • Automatic password deny-list reload: Updated lists can take effect without restarting the server.
  • Persistent login-failure data: In 26.8, temporary lockouts normally survive cluster restarts through database persistence, with exceptions for certain external-cache deployment modes.
  • Per-application session termination: The Account Console gains more granular session control in 26.8.

Application logout behavior still depends on the integration. Removing a Keycloak client session does not guarantee immediate rejection of every previously issued access token.

Passkeys themselves were available before 2026; this year’s changes improve their configuration and compatibility.

New Security Signals and Authorization Interfaces

Keycloak 26.7 introduces several Experimental capabilities that are relevant to future security architectures.

Shared Signals Framework

Shared Signals Framework (SSF) allows Keycloak to send signed security events to registered receivers. These can communicate session, credential and account-state changes.

Version 26.8 expands the available account signals and improves event handling.

An integrated application or agent gateway could use these signals to respond sooner when access should end. The receiver must validate the signal and implement the response.

SSF is therefore a building block for coordinated access changes – not an automatic mechanism that stops every running agent.

AuthZEN

AuthZEN provides a standard interface through which applications can request authorization decisions.

An API or gateway can ask whether a particular subject may perform an action on a resource.

For AI integrations, this could help centralize permission decisions outside the agent itself. The gateway or application must enforce the result using trustworthy request context.

Identity Assertion JWT Grant

Identity Assertion JWT Grant (ID-JAG) adds an Experimental receiving-server implementation in 26.7.

It is relevant to access across authorization domains, but Keycloak does not yet implement the complete end-to-end flow.

These capabilities should be evaluated according to their documented maturity and deployment limitations.

Digital Wallets and Verifiable Credentials

Keycloak also advances its support for digital credentials.

OpenID for Verifiable Credential Issuance (OID4VCI) reaches Preview in 26.8, alongside improvements to credential management, revocation, issuance actions and attestation handling.

OpenID for Verifiable Presentations (OID4VP) verification remains Experimental, as do mdoc and several related capabilities.

These features create opportunities to evaluate wallet-based authentication and cryptographically signed credentials. Their security value depends on the credential format, trust model and verification process.

They should not be interpreted as automatically establishing whether an AI agent is trustworthy.

Easier Operations Can Help Teams Maintain a More Secure Deployment

Operational complexity can delay security updates and encourage configuration shortcuts. Several 2026 improvements make Keycloak easier to operate.

Rolling updates for patch releases become Supported in 26.6. They apply within the same major/minor release stream and require a suitable deployment configuration. They do not guarantee uninterrupted upgrades between arbitrary versions.

Multi-cluster v2 becomes Supported in 26.8 after its Preview introduction in 26.7. Its stateless mode removes the need for an external Infinispan cluster, simplifying the architecture.

The deployment still requires a suitable database, synchronous replication, low latency, synchronized clocks and load balancing.

Client Admin API v2 and Operator client resources progress from Experimental in 26.7 to Preview in 26.8. Declarative OIDC and SAML client management can help teams review configuration changes and reproduce deployments.

Additional security-related operational improvements include encrypted PEM private-key support, simpler database TLS configuration and an opt-in hostname-validation policy for legacy client node registration.

Logging also improves through contextual MDC information, additional OpenTelemetry options, separate access-log files and configurable rotation. Redaction of specific sensitive headers and cookies reduces some credential exposure, although logs still require careful handling.

Additional Features and Enhancements by Release

The releases also include smaller integration, administration and usability improvements.

Keycloak 26.5

Alongside the identity and automation features described above:

  • Configurable CORS headers and client-registration policies.
  • An optional logout confirmation page.
  • Controls for advertising scopes through discovery metadata.
  • Persistent organization invitations with filtering, resend and deletion.
  • A new expired-session deletion event, USER_SESSION_DELETED.
  • PowerPC ppc64le container images.
  • Session-cache locality and expired-session cleanup improvements.
  • Preview optimized HTTP JSON serialization.
  • Configurable retries for outgoing HTTP requests.
  • Individual feature-enablement options.
  • RFC 9440 client-certificate forwarding.
  • Windows-service installation.
  • Preview OpenTelemetry log export, Experimental metrics export and custom trace-export headers.
  • Promotion of MDC logging to Supported.

Keycloak 26.6

Additional changes include:

  • A new DPoP implementation guide; DPoP itself predates 2026.
  • A more specific administrative scope for group-membership management.
  • Java 25 support.
  • CloudNativePG deployment instructions.
  • Database timeout settings, encoding checks and migration-probe improvements.
  • Graceful HTTP shutdown.
  • The KCRAW_ environment-variable prefix for preserving literal values, including secrets containing special characters.
  • Automatic Kubernetes and OpenShift truststore initialization.
  • Client-certificate lookup for Traefik and Envoy.
  • Configurable Kubernetes Service names and ports.
  • JSON log service fields and Operator telemetry configuration.
  • Configurable telemetry exporter headers and ServiceMonitor metadata.
  • Additional translations and initial Account UI support for right-to-left languages.
  • A Supported JUnit-based Keycloak Test Framework.

Keycloak 26.7

Additional changes include:

  • Verifiable-credential administration, refresh and interoperability improvements.
  • Experimental attestation-based client authentication and separately controlled pre-authorized-code functionality.
  • Realm search by display name.
  • Optional exclusion of additional datasources from health checks.
  • Generated BCFKS truststores in strict FIPS mode.
  • Expanded reverse-proxy guidance for HAProxy and Traefik.
  • Kustomize-based Operator installation.
  • Preview cluster-wide Operator deployment.

Keycloak 26.8

Additional changes include:

  • Stronger protocol-mapper allow-list enforcement through the Admin REST API.
  • Configurable cluster and node naming.
  • Automatic non-blocking database index creation where supported.
  • An Experimental Vert.x outbound HTTP client.
  • Experimental Helm-based Operator installation.
  • Updated identity-provider buttons on the login page.
  • Application sorting and password-hashing memory improvements.
  • Deprecation of multi-cluster v1 in favor of the newer architecture.

The official release announcements provide the detailed engineering changelogs, and a link is available below.

Security Patches Remain Essential

New features are only part of the security picture.

Patch releases during 2026 include changes to access-log redaction, token-endpoint parameter limits, redirect-URI validation and management of disabled clients.

Keycloak 26.8.1 also fixes issues affecting authentication, administrative permissions, identity brokering and token exchange.

Organizations should review the upgrade guide and test integrations before deployment, including when a security fix changes previously accepted behavior.

What Does This Mean for Organizations Using AI Agents?

Our recommendation is to start with a clear access model for each agent integration:

  1. Assign a distinct identity and owner. Know which application or workload is acting.
  2. Limit permissions to the required task. Avoid giving agents broad administrative credentials.
  3. Reduce permanent secrets. Evaluate federated authentication and short-lived credentials.
  4. Enforce authorization in APIs and gateways. Validate tokens and permissions outside the model.
  5. Record the user and the actor. Correlate identity events with application and tool activity.
  6. Test offboarding and revocation. Verify what happens to existing sessions and tokens.
  7. Keep sensitive operations behind appropriate approvals. Authentication and consent do not replace business-level approval.

Keycloak can provide the identity and access-control foundation for these designs. It does not inspect prompts, detect prompt injection, sandbox an agent or determine whether an authorized action is sensible.

A manipulated agent may still misuse its legitimate permissions. Runtime restrictions, tool-level controls and human oversight remain important.

How ALM Toolbox Can Help You?

ALM Toolbox provides Keycloak planning, implementation, SSO integration, maintenance and support.
We can help assess your current deployment, identify which updates are relevant, plan an upgrade and review the identity and access requirements of your applications and automation.
If you are introducing AI agents or expanding access to internal tools, this is also a good opportunity to review workload identities, credential management, permissions and auditing.

Contact to discuss your Keycloak environment and security requirements: keycloak@almtoolbox.com or call us: 866-503-1471 (USA / Canada ) or +31 85 064 4633 (international)

Related Links:

    * Full Name

    * Work Email

    * Are you using any AI tools today? What tools?

    Your information will be securely sent to and stored in Google Sheets for the purpose of processing your form submission.

      * Full Name

      * Work Email

      Are you using any SCA solution? Which one?

      Your information will be securely sent to and stored in Google Sheets for the purpose of processing your form submission.

        * Full Name

        * Work Email

        * Are you using OpenProject?

        Do you have any questions you'd like to ask before the webinar?

        Your information will be securely sent to and stored in Google Sheets for the purpose of processing your form submission.

          * Full Name

          * Work Email

          * Are you using any Secrets Management solution? Which one?

          Your information will be securely sent to and stored in Google Sheets for the purpose of processing your form submission.