Architecture

System Overview

Agent Identity Lab is a monorepo with two layers: packages (shared logic) and apps (deployable services). Five services form the control plane, all running locally via Docker Compose.

Agent Identity Lab Architecture

Service Boundaries

ServicePortResponsibility
identity_api8000Blueprints, agents, sessions, delegation, authorization, audit
token_broker8001Downstream credential issuance — agents never see raw API keys
mcp_gateway8002AuthN/Z proxy between agents and MCP servers
mock_mcp_server8003Test MCP server for development
admin_ui3000Next.js dashboard (planned post-MVP)

Data Flow

Agent → mcp_gateway → (auth check) → identity_api → policy_engine → token_broker → mcp_gateway → mock_mcp_server
                                                                                              ↓
                                                                                        audit log

Every request flows through the gateway, which authenticates the session token, calls the identity API for authorization, obtains downstream credentials from the token broker if allowed, and injects them server-side before forwarding to the tool.

Policy Engine

The policy engine supports two adapters:

  • OPA (Open Policy Agent): Production-grade Rego policy evaluation via REST API. Fail-closed — if OPA is unreachable, access is denied.
  • Python fallback: Local policy evaluator implementing scope intersection. Used when OPA is unavailable or for testing.

Authorization Model

Effective Scopes = User Scopes ∩ Agent Scopes ∩ Blueprint Scopes ∩ Tool Required Scopes ∩ Environment Policy

Policy Decisions

DecisionMeaning
allowAll checks passed, effective scopes computed
allow with reduced scopesSome requested scopes removed by intersection
denyAny check failed — deny by default

Token Model

Agent Session Tokens are signed JWTs with the following claims:

ClaimDescription
subAgent principal URI (agent:uuid)
audmcp-gateway
agent_idAgent UUID
blueprint_idBlueprint slug + version
acting_userHuman user ID (null for machine-only)
scopesEffective scopes after intersection
runtime_digestContainer image SHA
trace_idRequest trace identifier
expExpiration (max 30 minutes)

Asymmetric RS256 signing. Tokens are validated on every gateway request.

Security Architecture

Attestation

Runtime attestation binds agent sessions to execution context:

  1. Runtime generates claims (container digest, git commit, environment, framework, model)
  2. Claims are signed with the agent’s registered private key
  3. Identity service verifies: signature, timestamp freshness (5 min window), nonce uniqueness

Credential Isolation

Agents never receive raw downstream credentials:

  1. Agent requests a tool via the MCP Gateway
  2. Gateway authenticates the session and authorizes the action
  3. Token Broker issues a short-lived downstream credential
  4. Gateway injects the credential server-side in the forwarded request
  5. Only credential lease metadata is logged — no raw secrets

Audit Chain

Every decision is recorded in a tamper-evident append-only chain:

record_hash = SHA256(previous_hash + canonical_event_json)

The chain can be verified via POST /v1/audit/verify-chain. Any tampering is detected as a hash mismatch.

Key Design Decisions

ADR-001
Agents as First-Class Principals

Agents are uniquely identifiable security principals, not shared service accounts or personal credentials.

ADR-003
Permission Intersection Model

Effective permissions are the intersection of user, agent, blueprint, tool, and environment constraints — never the union.

ADR-004
Server-Side Credential Injection

Downstream credentials are injected by the gateway, not exposed to agent runtimes.

ADR-007
Gateway as Enforcement Boundary

All agent-to-tool traffic flows through the MCP Gateway. No direct agent access to tools.

← Back to home