AIM vs Keycloak for AI agent identity
Keycloak is an open source identity and access management server. It signs people in, issues OAuth tokens to clients, including machine clients through service accounts, and documents its use as an authorization server for MCP servers. AIM (Agent Identity Management) is an open source platform for AI agent identity. It keeps a registry of agents: each agent has an Ed25519 key, a trust score and a list of capabilities checked through an SDK, and MCP servers are attested by the agents that use them.
The two cover different layers. The open source build of AIM has no built-in integration with Keycloak or any other identity provider, and it does not replace one. The hosted AIM Cloud adds Google sign-in.
Checked on against Keycloak 26.8.0 documentation and AIM at commit 3ab8285e, opens in a new tab. Where a Keycloak page has no versioned address, its link opens the current release, which can be newer. To report a line that is wrong, use the contact page.
Capability by capability
Signing people in
Keycloak 26.8.0
Documented. "Keycloak is a single sign on solution for web apps and RESTful web services." The Server Administration Guide covers single sign-on, user management, user federation and identity brokering.
AIM
The dashboard has local email and password sign-in. No single sign-on, OpenID Connect or SAML login is wired in the open source build: the repository contains Google, Microsoft and Okta provider code, but no login route calls it.
Machine clients
Keycloak 26.8.0
Documented. "Each client has a built-in service account which allows it to obtain an access token." The client credentials grant is for clients that "want to obtain access on behalf of themselves rather than on behalf of a user".
Source: Server Administration Guide, opens in a new tab, OIDC layers guide, opens in a new tab
AIM
Each agent is registered with its own Ed25519 public key. The token endpoint accepts one grant: a JWT-bearer assertion signed with that key, in exchange for a bearer token for AIM's own agent API. AIM does not implement the client credentials grant: the token endpoint refuses it.
Source: agent_service.go, opens in a new tab, oauth_token_handler.go, opens in a new tab
Client authentication with keys
Keycloak 26.8.0
Supported: signed JWT client authentication (RFC 7523) and mutual TLS (RFC 8705). EdDSA keys can be used for signed JWT client authentication since 24.0.0.
Source: Specifications implemented, opens in a new tab, 24.0.0 release, opens in a new tab
AIM
An agent can sign each request with its Ed25519 key. On routes behind the request-signature check, the server verifies the signature over the method, path, timestamp and body, and rejects a timestamp more than 30 seconds from its own clock. The action-check request is signed over the action's fields (agent, capability, resource, context and timestamp) and verified against the agent's registered key. Agent routes also accept an API key or a bearer token in place of a signature.
Token exchange and delegation
Keycloak 26.8.0
Standard token exchange (RFC 8693) is supported since 26.2.0, for internal-to-internal exchange. Token exchange delegation with consent is a preview feature in 26.8.0. The token exchange guide says client delegation lets a user delegate their token to a client application, "such as an AI agent or automated service".
Source: Token exchange guide, opens in a new tab, 26.2.0 release, opens in a new tab, 26.8.0 release, opens in a new tab
AIM
OAuth token exchange (RFC 8693) is not implemented: the agent token endpoint accepts the JWT-bearer grant only. Delegation exists outside OAuth, in the TypeScript SDK, which creates and verifies Ed25519-signed delegation chains between keys. The AIM server does not issue or check them.
Source: oauth_token_handler.go, opens in a new tab, delegation.ts, opens in a new tab
Proof of possession
AIM
DPoP is not found in the AIM repository at this commit. Tokens from the token endpoint are plain bearer tokens. Requests authenticated by signature are signed per call, as in the row on client authentication.
Authorization
Keycloak 26.8.0
Authorization Services: fine-grained policies (attribute, role, user and context based) and User-Managed Access.
AIM
Each agent has a list of granted capabilities. The SDK, running inside the agent process, sends each wrapped action to the server, which compares the capability name with that list. In the default mode (monitoring) a capability outside the list is allowed and, under the default policy, raises an alert. The Python SDK's decorator also registers a capability on first use, and in this mode the server grants it automatically. In strict mode a capability outside the list is denied under the default policy, and the SDK blocks the call.
Source: agent_service.go, opens in a new tab, enforcement.py, opens in a new tab
MCP servers
Keycloak 26.8.0
Documented as an authorization server for MCP servers. MCP specification 2025-03-26 is listed as Supported; later revisions as Experimental.
Source: MCP guide, opens in a new tab
AIM
AIM is not an OAuth authorization server for MCP. Agents submit signed attestations of the MCP servers they connect to, and the server checks each signature against the agent's registered key. A drift alert is raised when a capability detection run finds that a server's manifest has changed since the last run.
Source: mcp_attestation_service.go, opens in a new tab, mcp_manifest_service.go, opens in a new tab
Workload identity
Keycloak 26.8.0
Federated client authentication with Kubernetes service account tokens and external OpenID Connect issuers is supported since 26.6.0. SPIFFE is a preview feature.
Source: 26.6.0 release, opens in a new tab, Features, opens in a new tab
AIM
Not implemented for agents at this commit: AIM accepts no SPIFFE identity, Kubernetes service account token or external OpenID Connect issuer as an agent credential.
Source: oauth_token_handler.go, opens in a new tab, pqc_agent_auth.go, opens in a new tab
Registry of agents with a trust score
Keycloak 26.8.0
Not found in Keycloak's documentation as of 26.8.0, checked 2026-10-02. Nearest documented capability: clients and their service accounts.
AIM
Each agent has a trust score calculated from nine weighted factors; a factor with no data is left out of the weighted sum. It is recalculated on events such as registration, verification by an administrator, capability changes and capability reports from the SDK. A capability violation also lowers the stored score directly. Each action check reads the stored score.
Audit
Keycloak 26.8.0
Login events and admin events, covered under auditing in the Server Administration Guide.
AIM
An action check that passes its signature check is written to the audit log as a row with the agent, the capability, the resource, the stored trust score and whether it was allowed. The write is best effort: if it fails, the check still returns its decision. The log is not append-only at the database layer and is not signed.
Source: verification_handler.go, opens in a new tab, audit_log_repository.go, opens in a new tab, SECURITY.md, opens in a new tab
License and hosting
Keycloak 26.8.0
Open source under the Apache License 2.0. The downloads page lists a server distribution, a container image and an operator for Kubernetes and OpenShift.
Source: LICENSE.txt, opens in a new tab, Downloads, opens in a new tab
AIM
The repository is Apache-2.0. Self-hosted with Docker Compose. Also offered as a hosted service, AIM Cloud, which is built from a private mirror of the repository with cloud-only additions.
Source: LICENSE, opens in a new tab, docs/DEPLOYMENT.md, opens in a new tab, docker-compose.quickstart.yml, opens in a new tab
Which layer each one covers
Keycloak
- Signing people in and managing their accounts.
- Issuing OAuth tokens to applications and services.
- Acting as the authorization server in front of MCP servers.
- Policy-based authorization for protected resources.
AIM
- Keeping a registry of agents, each with its own key.
- Scoring each agent and recording the action checks it submits.
- Checking each action an agent submits against its granted capabilities.
- Recording which MCP servers agents attest to, and alerting when a detection run finds a server's manifest changed.
A team can run both: Keycloak for sign-in and OAuth tokens, AIM for its registry of agents and their action checks. AIM has no integration with Keycloak at this commit. Agents authenticate to AIM with their own keys or an AIM API key, and in the open source build people sign in to the AIM dashboard with a local account.
Registering an agent with AIM
In the Python SDK, secure() registers an agent and perform_action wraps the actions to be checked. secure() needs credentials first, from aim-sdk login or an SDK downloaded from the dashboard. For a self-hosted server, AIM's README at this commit says to create the agent in the dashboard first. The capability name on the decorator is what the server compares with the agent's grants. The resource is recorded with the check and is not compared.
from aim_sdk import secure
agent = secure("my-agent")
@agent.perform_action("db:read", resource="users_table")
def get_user_data(user_id):
...