Delegation Layer

Learn how authority is securely delegated in MCP-I using verifiable credentials.

Why Delegation Matters

Without delegation, AI agents would need full access to a user's account—posing risks for security, privacy, and compliance.

Delegation in MCP-I solves this by using VCs to:

  • Scope authority to only what’s necessary
  • Prove user consent cryptographically
  • Support revocation and expiration
  • Allow audit of each request

Delegation Credential Structure

Delegation is encoded inside a VC that includes:

  • The issuer (user/delegator DID)
  • The subject (agent/delegatee DID)
  • The scope of allowed actions and constraints
  • The expiration timestamp
  • A cryptographic proof signed by the issuer

→ See Credential Models for the full schema

Delegation Process

The delegation process typically follows these steps:

Loading diagram...

Delegation Lifecycle Diagram

The following diagram shows how a credential is issued, optionally rotated, and eventually revoked:

Loading diagram...
  • A credential may be valid until expiration or actively revoked
  • Rotation means a new VC replaces the old one with updated scope or subject
  • Verifiers must reject expired or revoked credentials

Delegation Chain

MCP-I supports chained delegation:

  • User → Agent A → Agent B
  • Each link in the chain is a separate credential
  • The verifier must validate each link on the chain recursively
Loading diagram...

When verifying a delegation chain:

  1. Start with the leaf credential (the one presented by the requesting agent)
  2. Verify each credential in the chain recursively
  3. Ensure each delegation's scope is a subset of its parent
  4. Check for circular dependencies
  5. Verify no credential in the chain is expired or revoked

Each VC must:

  • Be valid (not expired or revoked)
  • Be signed by the correct issuer
  • Match the scope requested
  • Link to previous subject DID

Delegation Validation Failures

Delegation fails if:

  • A link is missing (e.g., broken chain)
  • A VC is revoked or expired
  • Signature is invalid
  • Scope is insufficient or fails constraint expressions
{
  "error": "delegation_chain_invalid",
  "reason": "revoked_credential",
  "at": 1
}

→ These checks happen inside the Edge Verifier

Scope Definition

Scopes in MCP-I follow a standardized format to ensure clear and consistent authorization:

action:resource[/subresource][#instance]

Examples:

  • read:email - Permission to read emails
  • write:calendar/events - Permission to create calendar events
  • transfer:finance#account123 - Permission to transfer funds from account123

Revocation

MCP-I requires implementation of credential revocation to enable withdrawal of delegation:

StatusList2021

The recommended revocation method uses the StatusList2021 specification:

{
  "credentialStatus": {
    "id": "https://example.com/status/123#94",
    "type": "StatusList2021Entry",
    "statusPurpose": "revocation",
    "statusListIndex": "94"
  }
}

Revocation services maintain bitstring status lists where each bit represents a credential's status.

Revocation Process

Loading diagram...