Identity for MCP

The Problem

Model Context Protocol (MCP) is Anthropic’s open standard for connecting AI models to external tools and data sources. It’s exploding in adoption—developers are building MCP servers for databases, APIs, file systems, search engines, code repositories.

But MCP has no identity layer:

• Who called the tool? Logs show “claude-desktop” acted, not which user or which specific client instance
• Which server provided it? When multiple MCP servers run, audit trails can’t distinguish “DB-Server-Prod” from “DB-Server-Dev”
• Is this server authorized? No cryptographic proof that an MCP server is allowed to provide sensitive tools (e.g., delete records, transfer funds)
• Can we revoke access instantly? If a server is compromised, there’s no real-time way to block it—only manual config changes

This isn’t theoretical. Enterprise AI platforms are deploying MCP at scale, and compliance teams are blocking rollouts because audit logs can’t prove attribution. Security teams see MCP tools as “API keys with no rotation policy.” Platform teams see cross-tenant tool namespace collisions with no isolation.

Why It Matters Now

• MCP adoption growing 40% month-over-month (Anthropic, 2026) — every new server without identity is a future audit gap
• 80% of security incidents involve compromised credentials (Verizon DBIR, 2026) — MCP tools face the same risk
• No attribution = no compliance — Enterprise AI governance frameworks demand proof of which server + which client + which user authorized each tool call

The MCP spec is maturing, but identity is still an open question. The platforms that solve this first will win enterprise deployments.

---

How Affinidi Enables Identity for MCP

The key shift: Instead of MCP servers and clients being anonymous participants in a tool-calling dance, each gets a Decentralized Identifier (DID). Every tool call includes a signed mandate proving:

1. Client identity - Which AI agent or user is calling the tool
2. Server identity - Which MCP server is providing the tool
3. Authorization - What the client is allowed to do (read-only, write, delete, etc.)
4. Validity - That authorization is still valid right now (not revoked, not expired)

All of this happens transparently—MCP clients and servers continue using standard MCP protocol, but every message now carries cryptographic identity.

Technical Foundation

• Agent Gateway intercepts MCP messages, assigns DIDs to servers + clients, attaches signed mandates
• Trust Registry (TRQP) enforces policies: “Is Client A allowed to call Tool X on Server B right now?”
• Verifiable Credentials encode server capabilities (e.g., “This server provides database read tools”) and client permissions (e.g., “This client can query production DB”)
• DIDComm transport wraps MCP messages with end-to-end encryption + sender verification
• did:webvh identifiers for tamper-evident server identity (audit trails can time-travel: “Was this server authorized when the call was made?”)

Example Flow

[User Alice in Claude Desktop]
  ↓
Client assigned DID: did:webvh:alice-client-prod
  ↓
User requests: "Query customer database"
  ↓
[Agent Gateway intercepts MCP tool call]
  ↓
Checks Trust Registry: "Can alice-client-prod call db.query on DB-Server-Prod?"
  ✓ Client authorized
  ✓ Server registered
  ✓ Tool matches policy (read-only allowed)
  ↓
[MCP server executes tool call]
  ↓
Result logged with proof:
  - Client DID: did:webvh:alice-client-prod
  - Server DID: did:webvh:db-server-prod
  - Tool: db.query
  - Mandate: signed by Alice's organization
  - Timestamp: 2026-07-22T14:32:00Z

What this means:

• Audit trail proves attribution: Not “claude-desktop queried database,” but “User Alice’s client (did:webvh:alice-client-prod) called db.query on DB-Server-Prod (did:webvh:db-server-prod) under read-only mandate signed by Org Admin Bob”
• Real-time revocation: If a server is compromised, update Trust Registry—next tool call blocked instantly
• Cross-tenant isolation: Trust Registry enforces “Customer A’s clients can only call Customer A’s servers”
• Federated MCP: Two organizations run MCP ecosystems; their agents can call each other’s tools with cryptographic proof of authorization

---

Real-World Applications

Enterprise AI Platforms: Audit-Ready Tool Calls

Problem: Claude Desktop calls MCP server for database query. Audit log shows “claude-desktop” acted—not which user, not which client instance, not which server.

Solution: Agent Gateway assigns DIDs to client + server. Every tool call includes signed mandate. Audit log records: “Client did:webvh:alice-client-prod (User: Alice) called db.query on Server did:webvh:db-server-prod (Tool: read-only).”

Outcome:

• Compliance teams can prove who authorized what for SOC 2, ISO 27001 audits
• Security teams can trace incidents: “This tool call came from Alice’s client, not Bob’s”
• Platform teams can debug: “Why did this query fail? Check which server it hit.”

---

Multi-Tenant SaaS: Cross-Tenant Isolation

Problem: Customer A’s agent calls Customer B’s MCP tool by mistake—no isolation, tools share namespace. Customer B’s sensitive data exposed.

Solution: Trust Registry enforces: “Customer A’s agent (identified by DID) can only call tools from Customer A’s registered MCP servers.” Calls to Customer B’s servers blocked at Agent Gateway before execution.

Outcome:

• Zero cross-tenant leaks—Trust Registry enforces tenant boundaries cryptographically
• Compliance teams can prove isolation to auditors
• Customers trust multi-tenant SaaS: “Our MCP tools can’t be called by other tenants”

---

Open-Source MCP Ecosystem: Verifiable Authorship

Problem: Developer publishes MCP server to public registry (e.g., npm, GitHub). Users can’t verify it’s authentic—could be malicious fork with identical name.

Solution: Developer signs MCP server manifest with their DID (did:webvh:devname-github). Manifest includes: server name, version, capabilities, signature. Clients verify signature before connecting.

Outcome:

• Users trust open-source MCP servers with cryptographic proof of authorship
• Malicious forks can’t impersonate legitimate servers (signature won’t match)
• Package registries can display “Verified by did:webvh:devname-github” badge

---

Regulated Industries (Healthcare, Finance): HIPAA/SOC 2 Compliance

Problem: MCP server accesses PHI (Protected Health Information) or PII (Personally Identifiable Information). Regulators demand attribution: which server, which client, which user authorized it, when.

Solution: Every tool call logs: client DID + server DID + signed mandate + timestamp. Trust Registry confirms authorization was valid at the time of the call (not revoked, not expired).

Outcome:

• Auditors get cryptographic proof of who authorized what, when
• HIPAA compliance: prove PHI access was authorized by specific clinician via specific client
• SOC 2 compliance: prove no unauthorized tool calls, with tamper-evident logs

---

Why Affinidi

	Affinidi Identity for MCP	No Identity (Status Quo)	API Keys per Server	OAuth for MCP
Per-server attribution	✓ DIDs for every server + client	✗ Generic logs	⚠ Keys rotate, no history	⚠ OAuth tokens, no server identity
Runtime authorization	✓ Trust Registry enforces policies	✗ Post-hoc logs only	✗ Static allowlists	⚠ Token scopes, no dynamic policy
Cross-org trust	✓ DIDComm + TRQP	✗ Same-org only	✗ Custom integrations	✗ OAuth per-org, no federation
Revocation	✓ Real-time TRQP, instant	✗ No revocation	⚠ Manual key rotation	⚠ Token expiry, not instant
Standards-based	✓ W3C DIDs + VCs	N/A	✗ Proprietary	⚠ OAuth not designed for MCP

What this means:

• No identity (status quo) leaves audit trails incomplete—can’t prove which server or client acted
• API keys per server solve authentication but not attribution (keys rotate, logs show key ID, not user)
• OAuth for MCP adds complexity (authorization servers, token refresh) without solving cross-org trust or real-time revocation

Affinidi provides per-server DIDs + runtime policy enforcement + cross-org trust—the only architecture that scales MCP to enterprise compliance requirements without breaking the protocol’s simplicity.

Proof It Works

• DIDComm v2.1 - Production-ready encrypted messaging (already wraps other protocols)
• TRQP Integration - Real-time authorization queries for MCP tool calls
• Agent Gateway - Drop-in proxy that adds identity to any MCP client/server without code changes
• Self-hostable - Deploy Agent Gateway on your infrastructure, connect to your Trust Registry

---

Get Started

For Developers

Add identity to your MCP server in under an hour

Wrap your existing MCP server with Agent Gateway, assign it a DID, register capabilities in Trust Registry.

Start building →

---

For Platform Teams

See a live demo of MCP with identity

Watch a client call an MCP tool, see the DID-signed audit trail, revoke access in real-time.

Schedule demo →

---

For Enterprises

Custom deployment consultation

Integrate Agent Gateway into your AI platform, configure Trust Registry policies for multi-tenant isolation, set up federated MCP across organizations.

Talk to an expert →

---

Related Resources

Technical Deep Dives

• Decentralized Identifiers (DIDs) - How MCP servers and clients get cryptographic identities
• DIDComm Messaging - How identity wraps MCP protocol messages
• Trust Registries & TRQP - Real-time authorization for tool calls

Related Solutions

• Cross-Org Agent Trust - How agents prove identity across organizations
• Per-Agent Attribution - Audit trails that prove which agent did what
• Runtime Agent Governance - Control before action, not logs after

Case Studies

(Coming soon: Enterprise AI platform MCP deployment)