Architecture
A detailed look at the architectural components and interactions within the MCP-I framework
Overview
Architectural Foundation
MCP-I extends the core Model Context Protocol with identity and delegation layers, enabling secure verification of agent identities and authorities while maintaining compatibility with existing MCP implementations.
Built on the Model Context Protocol
MCP-I is an extension of the Model Context Protocol, providing delegated identity to AI agents, enforced through verifiable credentials and a tamper-evident audit chain. This allows agents to act on behalf of users while still operating under secure, accountable identity boundaries. It retains full interoperability with existing MCP-compatible agents and services, while enabling a higher trust model for agent actions.
Core Services
MCP-I is composed of modular components that align with decentralized identity and secure delegation:
- DID Service – Issues and resolves Decentralized Identifiers (DIDs)
- Credential Service – Issues Verifiable Credentials (e.g. delegation)
- Delegation Service – Verifies and chains authority credentials
- Edge Verifier – Enforces identity + delegation checks before request passes to backend
- Audit Service – Tracks identity, credential, and delegation events
- Core Service – Orchestrates events, registry, crypto utilities
Component Roles
Core Components
- Principal/User: The entity delegating authority to the agent
- Agent: Software component acting on behalf of the principal
- Service/Resource: System providing resources or tools via MCP
- Edge Proxy/Verifier: Validates agent identities and delegations
Infrastructure Components
- DID Resolver: Resolves decentralized identifiers to DID documents
- Revocation Service: Checks credential revocation status
- Reputation Service: Provides agent reputation information
Security Boundary
The Edge Proxy forms a critical security boundary in the MCP-I architecture. In Level 1 implementations, all verification occurs at this layer, while in Levels 2 and 3, services may perform additional verification.
Integration with Core MCP
MCP-I extends the Model Context Protocol with identity and delegation capabilities while maintaining full compatibility:
- Transport Layer: Reuses MCP transports (HTTP/SSE, stdio)
- Message Format: Extends MCP message format with identity headers
- Tools & Resources: Compatible with existing tool and resource definitions
- Client-Server Model: Maintains the same client-server architecture
Data Flow in MCP-I
Registration Flow
Request Verification Flow (Level 1)
Direct Service Authentication (Level 2+)
Flexible Integration
MCP-I allows for incremental adoption. Services can start with Level 1 (Edge Proxy handling all verification) before implementing direct Level 2+ verification.
Trust Boundaries
MCP-I establishes clear trust boundaries between components:
Trust Model
Component | Trusts | Verification Responsibility |
---|---|---|
Agent | None | Proves identity and delegation |
Edge Proxy | DID infrastructure | Verifies agent credentials |
Service (L1) | Edge Proxy | Accepts proxy assertions |
Service (L2+) | DID infrastructure | Verifies credentials directly |
User | Identity/credential provider | Issues valid delegations |
Security Assumptions
- Agents are untrusted until proven otherwise through cryptographic verification
- DID resolution infrastructure is reliable and trustworthy
- Private keys are properly secured by their respective owners
- Edge Proxy is a trusted component for Level 1 implementations
Orchestration & Extensibility
All services can be deployed independently or managed centrally. The Core Service:
- Dynamically activates and deactivates services needed for identity, credential issuance, and delegation pipelines
- Maintains a live directory of all available MCP-I service endpoints and capabilities
- Hosts event bus for system-wide communication
You can plug in capabilities such as:
- DID Methods — Choose how your agents and users are identified.
did:key
offers simplicity,did:web
supports domain-based trust, anddid:ion
anchors identifiers to public blockchains. - Credential Schemas — Tailor what your credentials assert: permissions, roles, identity metadata, or custom business rules.
- Revocation Strategies — Use privacy-preserving Bitstring Status Lists or integrate your own backend revocation system.
- SDKs & Runtimes — Bring identity-native behaviors into frontends, mobile agents, or cloud services with supported SDKs like KYA-OS.