OIDC federates human identity across applications. AIM provides cryptographic identity for autonomous AI agents. Understand why AI agents need a fundamentally different identity model.
Agent Identity Management
Identity purpose-built for AI agents. Ed25519 cryptographic keypairs per agent, capability-based access control, 8-factor continuous trust scoring, and MCP server attestation.
Identity Layer on OAuth 2.0
Identity federation layer built on OAuth 2.0. Provides standardized ID tokens, user profile claims, and single sign-on (SSO) for human users across web and mobile applications.
OIDC answers “who is this person?” by providing standardized ID tokens with claims like name, email, and profile. AIM answers “which agent is this, what is it allowed to do, and can it be trusted?” with cryptographic identity, declared capabilities, and real-time behavioral trust evaluation. OIDC assumes a human behind a browser; AIM is built for autonomous software agents that operate without human interaction.
OIDC ID tokens carry human-oriented claims: name, email, picture, locale. AI agents don't have emails or profile photos—they need capabilities, trust scores, and attestation records.
OIDC relies on browser redirects, consent screens, and user interaction. Autonomous AI agents running as background processes have no browser and no human to click “Allow.”
OIDC identifies the human who authenticated. Ten different agents acting on behalf of the same user look identical to the identity provider—there is no way to distinguish or audit them individually.
OIDC verifies identity at authentication time and assumes continued trust. It has no mechanism for continuously monitoring agent behavior, detecting anomalies, or dynamically restricting a misbehaving agent's access.
OIDC scopes define what user data a client can access, not what actions an agent can perform. Runtime capability enforcement—blocking an agent from exceeding declared permissions—is outside OIDC's scope.
OIDC has no concept of MCP servers, tool attestation, agent bills of materials, or AI supply chain verification. These are critical for securing agentic AI deployments.
| Feature | AIM | OIDC |
|---|---|---|
| Designed For | Autonomous AI agents | Human identity federation |
| Identity Model | Ed25519 keypair per agent | ID token with human claims (sub, email, name) |
| Identity Subject | Individual AI agent | Human user |
| Authentication Flow | Programmatic (no browser) | Browser redirect + user consent |
| Trust Evaluation | 8-factor continuous scoring | Authentication-time only |
| Capability Enforcement | Runtime, per-action | Scopes (data access, not action control) |
| Claims / Attributes | Capabilities, trust score, attestation | Name, email, picture, locale |
| MCP Server Attestation | Native support | Not applicable |
| AI Framework Integration | LangChain, CrewAI, LangChain4j | No AI-specific support |
| Non-Repudiation | Ed25519 signed actions | ID tokens are verifiable but bearer-based |
| SSO / Federation | Not the focus (agent registration) | Core strength |
| Discovery | MCP server auto-discovery | .well-known/openid-configuration |
| Setup | One line: secure("my-agent") | IdP configuration + client registration |
Compare what each system knows about its identity subject.
{
"agent_id": "research-agent-7b",
"public_key": "ed25519:MCow...",
"capabilities": [
"database:read",
"api:call"
],
"trust_score": 0.94,
"mcp_servers": [
"db-query-server (attested)"
],
"registered_by": "admin@corp.com",
"framework": "langchain"
}{
"sub": "user-123456",
"name": "Jane Smith",
"email": "jane@example.com",
"picture": "https://...photo.jpg",
"locale": "en-US",
"iss": "https://idp.example.com",
"aud": "client-app-id",
"iat": 1700000000,
"exp": 1700003600
}AIM and OIDC are complementary—they manage identity for different subjects:
Human identity (OIDC) + Agent identity (AIM) = Full identity governance for AI-powered organizations.
OIDC can authenticate the human who deploys or manages an AI agent, but it cannot authenticate the agent itself. OIDC's identity model is built around human claims (name, email, profile) and browser-based authentication flows. AI agents need per-agent cryptographic identity, capability enforcement, and continuous trust evaluation—none of which are part of the OIDC specification.
OIDC is a human identity federation protocol that tells you “this person is Jane Smith from Corp Inc.” AIM is an agent identity management platform that tells you “this is research-agent-7b, it can read databases and call APIs, its trust score is 0.94, and its MCP servers are attested.” They solve fundamentally different identity problems for different types of subjects.
Yes. AIM's dashboard and admin interfaces can use OIDC providers (like Okta, Azure AD, or Google) for human admin authentication. This means your team can log into AIM via your existing SSO infrastructure. However, the agents themselves use AIM's cryptographic identity system, not OIDC tokens.
Yes. AIM is fully open source under the Apache-2.0 license. You can self-host it, inspect the code, and contribute to the project. There are no per-agent fees or vendor lock-in.
OIDC federates human identity. AIM provides cryptographic agent identity with continuous trust scoring, capability enforcement, and MCP attestation.
Apache-2.0 license • Self-hosted • Works alongside your OIDC provider