Skip to main content

OpenA2A AIM (Agent Identity Management) architecture

How AIM registers agents, checks the actions they submit, scores them and records the MCP servers they attest to. Each figure restates the statement printed under it, and each statement links to the lines of the AIM source it comes from.

Correction (2026-10-10): The six diagram images this page offered for download since December 2025 have been withdrawn, and their files are no longer served. They stated things the AIM source does not support: for example, one gave a different number of trust score factors, under different names, than the server uses, and one stated a verification latency for which this site holds no measurement. The figures below replace them.

Identity and keys

  1. 1Register

    The agent is registered with its own Ed25519 public key.

  2. 2Get a token

    The agent signs a JWT-bearer assertion with that key and exchanges it at the token endpoint for a bearer token.

  3. 3Call the agent API

    The agent calls AIM's agent API with the bearer token, with an API key, or with a signature on each request.

How an agent gets from a registered key to an authenticated call.

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

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.

Source: pqc_agent_auth.go, opens in a new tab

Action check

  1. 1Sign

    The SDK, running inside the agent process, signs the fields of a wrapped action with the agent's key and sends them to the server.

  2. 2Verify

    The server refuses the check if the agent's status, the public key sent or the signature fails.

  3. 3Compare

    The server compares the capability name with the agent's list of granted capabilities.

  4. 4Apply policies

    When the capability check passes, the organization's security policies are evaluated. One policy type acts on the stored trust score.

  5. 5Record

    The check is written to the audit log with the stored trust score and whether it was allowed.

Monitoring mode (the default)

A capability outside the granted list is allowed and, under the default policy, raises an alert.

Strict mode

A capability outside the granted list is denied under the default policy, and the SDK blocks the call.

The path of one action check, and what the two enforcement modes do with a capability the agent was not granted. AIM checks the actions the SDK submits to it.

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

The server refuses an action check when the agent's status is neither verified nor pending, when the public key sent with the check is not the one registered for the agent, or when the signature does not verify. The decision then comes from the capability check and, when that passes, from the organization's security policies. One policy type acts on the stored trust score: when an enabled policy of that type applies to the agent and the score is below the policy's threshold, the policy can raise an alert and, in strict mode, block the action. With no such policy, the score is recorded with the check and does not change its result. In monitoring mode a policy that would block is overridden and the action is allowed.

Source: verification_handler.go, opens in a new tab, agent_service.go, opens in a new tab, security_policy_service.go, opens in a new tab

Trust score

  1. Verification status25%
  2. Uptime and availability15%
  3. Action success rate15%
  4. Security alerts15%
  5. Compliance10%
  6. Agent age5%
  7. Drift detection3%
  8. User feedback2%
  9. Execution isolation10%
The 9 factors of the trust score and the weight of each. A bar's length is the factor's weight relative to the largest. What each factor measures is described in the trust scoring docs.

The factors, their order and their weights are generated from trust_calculator.go, opens in a new tab in the AIM server source (commit 156e355).

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.

Source: trust_calculator.go, opens in a new tab

MCP attestation

  1. 1Attest

    An agent signs an attestation of an MCP server it connects to and submits it.

  2. 2Check

    The AIM server checks the signature against the agent's registered key.

  3. 3Detect

    A capability detection run compares the MCP server's manifest with the one recorded on the last run.

  4. 4Alert

    A changed manifest raises a drift alert.

The attestation is signed by the agent and the signature is checked by AIM. Drift is reported when a detection run finds a changed manifest.

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

Audit log

  • Agent
  • Capability
  • Resource
  • Stored trust score
  • Allowed or not
What one audit log row records about an action check.

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

Licence and deployment

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

Checked on against AIM at commit 3ab8285e, opens in a new tab. To report a line that is wrong, use the contact page.