FAQ
Common questions and answers about MCP-I implementation, security, and best practices
Frequently Asked Questions
Common Questions
This page addresses frequently asked questions about the Model Context Protocol - Identity (MCP-I) specification, implementation, security, and integration.
General Questions
What is MCP-Identity (MCP-I)?
MCP-I (Model Context Protocol - Identity) is an extension to the Model Context Protocol that provides a standardized framework for secure, verifiable identity and delegation for AI agents. It enables cryptographically verifiable proof that an agent is acting with appropriate authorization from a human or organization.
How does MCP-I relate to the core Model Context Protocol?
MCP-I extends the core Model Context Protocol by adding identity, delegation, and verification layers. While the core MCP defines how agents interact with services, MCP-I ensures that these interactions have proper identity verification and authorization.
What problem does MCP-I solve?
MCP-I addresses the "Know Your Agent" (KYA) problem by providing a standardized way to:
- Verify the identity of AI agents
- Validate their delegation authority from users
- Enforce scope-limited permissions
- Create auditable records of agent actions
- Manage agent reputation and trustworthiness
What are the conformance levels in MCP-I?
MCP-I defines three conformance levels:
Level 1 (Agent):
- The agent has a stable DID, registered during initialization.
- It may include a verifiable credential, but no user identity is required.
- Delegation is optional and can use legacy identifiers (e.g., OAuth JWTs).
Suitable for: lightweight integrations, non-sensitive workflows, local MCP Servers.
Level 2 (Agent + User):
- Both agent and user have DIDs, and the user issues a Verifiable Credential to the agent.
- The credential is verified at the edge per request.
- Supports revocation, expiration, and scoped access.
- Audit logs, delegation chain resolution, and credential verification are enforced.
Suitable for: real-world apps, sensitive data access, identity-backed transactions, regulatory compliance for Agentic services.
Level 3 (Agent + User + Service):
- All parties (agent, user, and recipient service) have DIDs and are MCP-I aware.
- Full VC lifecycle management, including issuance, revocation, and selective disclosure.
- Recipient services may enforce fine-grained policies based on delegation metadata.
- Supports credential-to-token bridging for OAuth 2.1 compatibility.
- Immutable audit trails, providing anomaly detection and reputation-aware access control.
Suitable for: regulated sectors (finance, healthcare), zero-trust architectures, interoperable agent ecosystems, service providers.
Who should implement MCP-I?
MCP-I is relevant for:
- Developers building AI agent systems
- Service providers offering resources to AI agents
- Organizations deploying or integrating with AI agents
- Security teams responsible for AI governance
- Anyone concerned with the security and accountability of autonomous AI systems
Implementation Questions
What technical components do I need to implement MCP-I?
A complete MCP-I implementation typically includes:
- DID management system
- Credential issuance and verification components
- Delegation flow handling
- Verification service or edge proxy
- Audit logging system
- Revocation management
Which DID methods should I use?
The recommended DID methods depend on your use case:
- For ephemeral agents:
did:key
(simple, self-contained) - For persistent agents:
did:web
(domain-bound, easy to manage) - For high-security applications:
did:ion
or similar (blockchain-anchored)
How do I integrate MCP-I with existing identity systems?
MCP-I can integrate with existing identity systems through:
- Mapping existing identifiers to DIDs
- Converting tokens (OAuth, SAML) to verifiable credentials
- Implementing an Edge Proxy for credential verification
- Using credential bridges for legacy systems
See the Compatibility & Legacy page for detailed guidance.
What libraries can I use to implement MCP-I?
Several libraries can help implement MCP-I components:
For JavaScript/TypeScript:
did-resolver
and method-specific resolvers@transmute/vc.js
or@digitalbazaar/vc-js
@veramo/core
and related packages
For Python:
didkit
pyld
for JSON-LD processingpy-multibase
for DID encoding/decoding
For Java:
uniresolver-client
verifiable-credentials-java
did-auth-java
How do I handle key management?
Key management depends on your conformance level:
- Level 1: Use standard secure storage with encryption
- Level 2: Implement hardware-backed key storage when available
- Level 3: Use HSMs or TEEs for critical keys
In all cases, implement proper key rotation, access controls, and auditing.
Security Questions
How secure is MCP-I compared to traditional authentication?
MCP-I offers several security advantages over traditional authentication:
- Cryptographic verification instead of token checking
- Explicit delegation with fine-grained scope
- Comprehensive audit trails
- Delegation chains with transitive verification
- Verification without central authorities (in some configurations)
What happens if a private key is compromised?
If a private key is compromised:
- Immediately revoke all credentials signed with that key
- Generate a new key pair and update the DID Document
- Issue new credentials with the new key
- Audit all actions performed during the potential compromise period
- Notify affected parties as appropriate
How do I securely deploy an MCP-I system?
Secure deployment practices include:
- Following the principle of least privilege
- Implementing proper network segmentation
- Using TLS for all communications
- Implementing secure key storage
- Regularly auditing and monitoring system activities
- Keeping dependencies updated
- Conducting regular security assessments
What are the common security pitfalls?
Common security pitfalls include:
- Inadequate key protection
- Insufficient verification of credential chains
- Missing revocation checks
- Poor scope validation logic
- Inadequate audit logging
- Insecure handling of cryptographic material
- Vulnerabilities in DID resolution processes
Operational Questions
How do I handle credential revocation?
For credential revocation:
- Implement a revocation service using StatusList2021 or a similar mechanism
- Ensure verifiers check credential status at appropriate intervals
- Consider notification mechanisms for urgent revocations
- Implement proper access controls for revocation operations
- Maintain audit trails of revocation events
How do I scale an MCP-I implementation?
Scaling strategies include:
- Caching DID documents and verification results
- Implementing efficient credential verification
- Using distributed verification services
- Optimizing revocation checking with batching and caching
- Implementing asynchronous audit logging
- Using load balancing for verification services
What monitoring should I put in place?
Effective monitoring includes:
- Credential verification metrics (success/failure rates)
- Revocation service availability
- Verification latency measurements
- Audit logging performance
- DID resolution performance
- Security-related events (e.g., multiple failed verifications)
- System resource utilization
How do I troubleshoot verification failures?
When troubleshooting verification failures:
- Check the specific error returned by the verifier
- Verify credential structure and format
- Confirm the DID can be resolved
- Validate the signature using the correct verification method
- Check for credential expiration
- Verify revocation status
- Confirm scope permissions match the requested action
Integration Questions
Can MCP-I work with OAuth/OIDC?
Yes, MCP-I can integrate with OAuth/OIDC in several ways:
- Mapping OAuth tokens to MCP-I credentials
- Using OAuth for principal authentication while using MCP-I for agent delegation
- Implementing credential-to-token bridges for legacy services
- Supporting legacy identity in Level 1 implementations
How do I migrate from a traditional system to MCP-I?
Migration typically follows these steps:
- Start with a Level 1 implementation alongside existing systems
- Map existing identities to DIDs
- Convert existing permissions to delegation credentials
- Implement an Edge Proxy for credential verification
- Gradually transition services to native MCP-I verification
- Phase out legacy systems as adoption increases
Does MCP-I work with WebAuthn/FIDO2?
Yes, MCP-I can integrate with WebAuthn/FIDO2:
- WebAuthn can be used for secure principal authentication
- FIDO2 keys can be used for credential signing
- WebAuthn attestations can be incorporated into the identity verification process
- FIDO2 can provide the hardware-backed key protection required for Level 2+
Can I use MCP-I in a multi-tenant environment?
Yes, MCP-I works well in multi-tenant environments:
- Each tenant can have separate issuer DIDs
- Tenant-specific credential schemas can be defined
- Verification policies can be tenant-specific
- Audit logs can be segregated by tenant
- Revocation services can be tenant-aware
Technical Details
How are DIDs resolved in MCP-I?
DIDs are resolved according to their specific method specifications:
did:key
resolution is typically done locally by parsing the encoded public keydid:web
resolution involves an HTTP(S) request to fetch the DID documentdid:ion
and other methods may require specialized resolvers- Universal resolvers can be used for multiple method support
- Resolution results are often cached for performance
What is the structure of a delegation credential?
A delegation credential follows the W3C Verifiable Credential format with these key components:
@context
array with required context URLstype
array including "VerifiableCredential" and a delegation-specific typeissuer
field with the principal's DIDcredentialSubject
object with:id
field containing the agent's DIDscope
array defining permitted actions- Optional
constraints
object with additional limitations
issuanceDate
andexpirationDate
fieldscredentialStatus
object for revocation informationproof
object containing cryptographic proof of authenticity
How do I define appropriate scopes?
Effective scope definition follows these principles:
- Use the
action:resource
format (e.g.,read:email
) - Follow the principle of least privilege
- Be as specific as possible while remaining manageable
- Consider resource hierarchies (e.g.,
read:calendar/events
) - Use wildcards sparingly and only when appropriate
- Include constraints for additional limitations
How does verification performance impact my system?
Verification performance considerations include:
- DID resolution can be computationally expensive
- Signature verification requires cryptographic operations
- Revocation checking may involve network requests
- Caching strategies are essential for production systems
- Hardware acceleration can help with cryptographic operations
- Performance requirements increase with request volume
Regulatory and Compliance
How does MCP-I help with regulatory compliance?
MCP-I supports regulatory compliance through:
- Identity Verification: Meeting KYC/KYB requirements for AI systems
- Audit Trails: Supporting accountability requirements
- Access Controls: Enforcing data protection guidelines
- Delegation Records: Establishing clear responsibility chains
- Revocation Mechanisms: Enabling prompt termination of access
Is MCP-I compliant with the EU AI Act?
MCP-I is designed to support EU AI Act compliance:
- It enables transparent identification of AI systems
- It provides clear delegation chains showing human oversight
- It supports comprehensive logging for accountability
- It enables proper risk management through scope limitations
- It facilitates technical documentation requirements
How does MCP-I handle privacy considerations?
MCP-I addresses privacy considerations through:
- Minimizing personally identifiable information in credentials
- Supporting selective disclosure in Level 3 implementations
- Enabling privacy-preserving verification
- Providing fine-grained control over delegation scope
- Supporting privacy-friendly DID methods
Can MCP-I help with GDPR compliance?
Yes, MCP-I can support GDPR compliance:
- It enables clear data processing authorization
- It provides audit trails of data access
- It supports revocation for withdrawing consent
- It enforces purpose limitation through explicit scopes
- It enables data minimization through selective disclosure
Miscellaneous
Where can I find reference implementations?
Reference implementations and resources are available at:
- KnowThat.ai MCP-I Reference
- The KYA-OS SDK coming soon.
- Community implementations listed in the MCP-I GitHub repository
How can I contribute to the MCP-I specification?
You can contribute to MCP-I development by:
- Providing feedback on the specification
- Participating in the working group discussions
- Contributing to reference implementations
- Sharing implementation experiences and challenges
- Proposing extensions or improvements
Who is behind the MCP-I specification?
MCP-I is developed by a community of organizations and individuals focused on AI agent security, including:
- Contributors from leading AI research organizations
- Identity and security experts
- Practitioners from various industries
- Standards organization representatives
- Open-source contributors
Where can I get support for MCP-I implementation?
Support resources include:
- The MCP-I community forum
- The MCP-I GitHub issue tracker
- Commercial support from implementing organizations
- Community chat channels (Discord, Matrix)
- The KnowThat.ai knowledge base
How is MCP-I versioned and how will it evolve?
MCP-I follows semantic versioning:
- Major versions indicate breaking changes
- Minor versions add features in a backward-compatible manner
- Patch versions include backward-compatible fixes
The specification is expected to evolve based on:
- Implementation feedback
- Emerging security requirements
- Advancements in decentralized identity standards
- Regulatory developments
- New AI agent capabilities and use cases