]> Cisco Systems, Inc.

Av. des Uttins 5 ROLLE 1180 Switzerland jdiaconu@cisco.com

Cisco Systems, Inc.

Av. des Uttins 5 ROLLE 1180 Switzerland mayannuz@cisco.com

Cisco Systems, Inc.

Av. des Uttins 5 ROLLE 1180 Switzerland hmuyal@cisco.com

Cisco Systems, Inc.

Hansaallee 249, 3rd Floor DUESSELDORF 40549 Germany fbrockne@cisco.com

Cisco Systems, Inc.

170 W Tasman Dr SAN JOSE, CA 95134 USA nikkal@cisco.com

Skyfire, Inc.

Kentfield, CA USA ankit@skyfire.xyz

Ory Corp, Inc.

15169 N Scottsdale Rd Suite 205 Scottsdale, AZ 85254 USA jeff.hickman@ory.com

Amazon Web Services

Seattle, WA USA amrithak@amazon.com

Security Internet Engineering Task Force Distributed Multi-Agent Systems consist of Agents and MCP Servers operating across multiple administrative domains, each with its own Identity Providers (IdPs) and Authorization Servers (AS). This document discusses the challenges and solution approaches for sharing authorization information securely and flexibly across domains, including the use of dynamic identity, interoperable claims, and verifiable credentials.

Introduction Distributed Multi-Agent Systems, consisting of Agents and Model Context Protocol (MCP) Servers, are increasingly deployed across multiple administrative domains. Each domain typically operates its own Identity Providers (IdPs) and Authorization Servers (AS), creating a fundamental challenge: how can an agent from Organization A securely prove its identity and authorization to resources in Organization B? While OAuth 2.0 and related specifications provide authorization frameworks for human users and pre-registered clients, the emergence of autonomous agent systems operating across organizational boundaries presents new challenges that existing mechanisms do not fully address. This challenge is distinct from traditional cross-domain identity federation for human users. Humans rarely delegate authority through multiple organizational boundaries. Agents routinely do so--an orchestrator agent in Domain X may invoke a tool agent in Domain Y, which accesses an MCP server in Domain Z. Existing authorization mechanisms such as OAuth 2.0 Dynamic Client Registration and Token Exchange assume single-domain operation or pre-established relationships, and do not address the dynamic, multi-hop delegation patterns that characterize modern agentic systems. This document analyzes the cross-domain agent authorization problem and evaluates solution approaches. The proposed solution extends OAuth 2.0 Client-ID Metadata with W3C Verifiable Credentials to enable dynamic identity establishment without pre-registration across domains, cryptographically verifiable authorization claims that travel with the agent, multi-hop delegation with monotonic scope narrowing and accountability chains, and selective disclosure of sensitive authorization attributes. The document is structured as follows: defines key terminology. presents use cases demonstrating cross-domain scenarios. identifies threats specific to cross-domain authorization sharing. establishes requirements and evaluates solution approaches. covers security considerations. Enterprise deployment of AI agents is moving faster than the identity and authorization practices that govern them. Recent industry reporting, protocol roadmap work, and public vulnerability disclosures point to the same gap: agents are connected to production tools, data, and workflows without consistent per-agent identity, scoped delegation, cross-domain authorization, or revocation semantics. A February 2026 concept paper from the US National Cybersecurity Center of Excellence proposes a demonstration project applying existing identity and authorization standards, including OAuth and the Model Context Protocol, to AI agents, which indicates that this gap is now a recognized standards problem . The scale of unauthenticated deployment is measurable. A 2026 measurement study of remote MCP servers found that a large fraction expose tools without any authentication, and that the OAuth deployments which do exist commonly carry authentication flaws . This is the condition this document addresses: when an agent in one domain presents itself to an Authorization Server in another, identity and authorization information has to be verifiable, not assumed. Between February and April 2026, several public incidents exercised the threat categories described in this document. Autonomous agents obtained remote code execution against production infrastructure, reached an internal AI platform's database in under two hours, and exploited missing authentication in MCP server implementations. These incidents are mapped to the threat model in .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in and when, and only when, they appear in all capitals, as shown here.

Abbreviations / Definitions

Agent

An autonomous entity that performs tasks on behalf of a user or another program within a multi-agent system.

MCP Server

A program that exposes specific capabilities, like data access or tools, to AI models through the Model Context Protocol (MCP).

AS (Authorization Server)

A server that issues authorization tokens to clients after successfully authenticating them.

IdP (Identity Provider)

A service that creates, manages, and verifies digital identities for users and service users, often for accessing multiple applications and services.

Subject

The principal (user or service).

Claim

Essentially a piece of information asserted about a subject.

Domain

Scope over which a specific, uniform set of security policies and user management rules are enforced.

VCDM 2.0

Verifiable Credentials Data Model 2.0, a W3C standard for expressing verifiable credentials on the web.

VC

Verifiable Credential, a digital credential that is cryptographically secure and can be verified independently.

SD-JWT

Selective Disclosure JSON Web Token, a JWT that allows the holder to disclose only specific parts of the token.

DID

Decentralized Identifier, a new type of identifier that enables verifiable, self-sovereign digital identities.

Use Cases The following use cases demonstrate scenarios where cross-domain agent authorization presents challenges not addressed by existing single-domain mechanisms.

Cross-Domain Tool Invocation A coding assistant agent operated by Developer Tools Inc. needs to invoke a code review tool provided by Code Analysis Corp. The tool is exposed as an MCP Server protected by Code Analysis Corp's Authorization Server.

Cross-Domain Challenge

Developer Tools Inc.'s agent must present credentials that Code Analysis Corp's AS can verify, despite having no pre-existing trust relationship. The AS must determine what operations the agent may perform based on claims issued by a foreign domain.

Requirements

Verifiable agent and MCP server identity across domain boundaries, authorization claims that are interpretable by the receiving domain.

Enterprise Partnership Integration Company A partners with Company B to provide integrated customer support services. Company A deploys a support agent that needs to access Company B's customer ticketing system and knowledge base to resolve customer issues.

Cross-Domain Challenge

Company A's agent authenticates using Company A's IdP and holds a Verifiable Credential issued by Company A. Company B's Authorization Server has no trust relationship with Company A's IdP--it cannot verify Company A's tokens. Company B needs a mechanism to verify the agent's identity and authorization claims without requiring bilateral federation setup for every partner.

Requirements

Dynamic identity verification across domains, verifiable compliance attestations, and scope restrictions that Company B's AS can enforce based on Company A's authorization grants.

Multi-Vendor Workflow Orchestration A security operations workflow involves agents from multiple vendors: an orchestrator agent from Security Vendor X coordinates a threat intelligence agent from Vendor Y and a remediation agent from Vendor Z. The orchestrator must delegate appropriate permissions to each specialized agent.

Cross-Domain Challenge

The orchestrator in Domain X must delegate authority to agents in Domains Y and Z. Each receiving domain must verify the delegation chain, ensure the delegated scope does not exceed what the originating principal authorized, and maintain an auditable record of the delegation chain. Receiving domains must ensure that the authorization decisions do not rely on revoked, suspended, or superseded delegations by performing runtime delegation chain verification according to the local policy.

Requirements

Multi-hop delegation with scope narrowing, cross-domain accountability chains, privacy-preserving identity claims, and domain-specific policy enforcement at each trust boundary crossing.

Supply Chain Data Exchange A manufacturer's inventory management agent needs to query suppliers' availability systems. Multiple suppliers operate their own authorization infrastructure. The agent must access each supplier's MCP servers with appropriate credentials.

Cross-Domain Challenge

Each supplier's AS must verify the manufacturer's agent without requiring manual pre-registration. Dynamic Client Registration would require the agent to register separately with each supplier's AS, creating operational overhead and not providing cryptographic verification of the agent's authorization claims from its home domain. The agent may need different permission levels at different suppliers based on partnership agreements. Suppliers must be able to audit which manufacturer agents accessed their data.

Requirements

Dynamic agent provisioning across multiple foreign domains, verifiable identity without pre-registration, and domain-specific scope mappings.

Regulatory Compliance Across Jurisdictions A financial services agent operating in the EU needs to access data from a partner institution in the US. Both jurisdictions have different regulatory requirements.

Cross-Domain Challenge

The receiving domain's AS must verify that the requesting agent's compliance attestations meet local policy requirements. The VC issued by the originating domain asserts compliance with GDPR; the receiving domain must determine whether this satisfies its own data handling requirements without assuming equivalence of compliance frameworks.

Requirements

Verifiable compliance attestations that receiving domains can evaluate against local policies, and data sensitivity clearance, verification across regulatory boundaries.

Requirements Summary A system for cross-domain sharing of authorization information of agents needs to meet the following set of requirements:

• Dynamic Identity for Agents and MCP Servers: The Agents and MCP Servers can onboard dynamically and get an assigned identity in the IdP.
• Interoperability Across Domains: The system must enable interaction between Agents across different domains.
• Flexible Definition of Claims: Claims should be adaptable as they may vary from organization to organization. They may include information related to authorization, compliance requirements, chains of delegation, and other domain-specific concerns.
• Dynamic Management of Authorization Information: The system must allow creation, removal, updating, and deletion of authorization information for agents, as agents can be highly dynamic.
• Security and Privacy: Ensuring secure and private sharing of authorization information across domains.
• Compliance and Auditability: Support for compliance with regulatory standards and auditability of authorization exchanges.

Solution Approaches

Solution Approach 1: Dynamic Client Registration (RFC 7591) Description: Dynamic Client Registration as outlined in allows clients to register with an AS dynamically, facilitating the management of client credentials and metadata. Discussion:

Requirement	Met or Partially Met	Not Met
Dynamic Identity for Agents and MCP Servers	Met
Interoperability Across Domains	Partially Met (Granted by the Dynamic Registration, however no common ground between AS)
Flexible Definition of Claims		Not Met (OAuth2 claims only)
Dynamic Management of Authorization Information		Not Met (Delete or Update not supported)
Security and Privacy		Not Met (Claims are shared but no common schema)
Compliance and Auditability	Partially Met (Claims are shared, APIs are auditable, but no regulatory standards are defined for the schema)

Solution Approach 2: SCIM extensions proposes extending the SCIM (System for Cross-Domain Identity Management) protocol to standardize the provisioning, management, and governance of AI agents and other digital workers. is a companion document to the draft-abbey-scim-agent-extension. Its purpose is to define the specific SCIM schema and attributes required to represent AI agents (digital workers) and agentic applications within the SCIM framework. Description: Provision Agents / MCP Servers through a SCIM extension. Discussion:

Requirement	Met or Partially Met	Not Met
Dynamic Identity for Agents and MCP Servers	Partially Met (SCIM support is limited and with constraints, example for Azure: “Subsequent syncs are triggered every 20-40 minutes”.)
Interoperability Across Domains	Partially Met (SCIM is supported and schema is well defined)
Flexible Definition of Claims	Met (Defined by the schema)
Dynamic Management of Authorization Information	Partially Met (SCIM support is limited and with constraints, example for Azure: “Subsequent syncs are triggered every 20-40 minutes”.)
Security and Privacy	Partially Met (A schema is defined but Selective Disclosure not supported)
Compliance and Auditability	Partially Met (Claims are shared, APIs are auditable, but no regulatory standards are defined for the schema)

Solution Approach 3: Client-ID Metadata Description: Client ID Metadata is a method for OAuth clients to identify themselves using a URL, which points to a JSON file containing their OAuth metadata. Instead of requiring pre-registration, an authorization server can fetch this JSON document at the client's provided URL to provision the identity. Discussion:

Requirement	Met or Partially Met	Not Met
Dynamic Identity for Agents and MCP Servers	Met
Interoperability Across Domains	Met
Flexible Definition of Claims		Not Met* (client_id is common, all the rest is limited to OAuth2 claims)
Dynamic Management of Authorization Information	Met
Security and Privacy	Partially Met** (A schema is defined but Selective Disclosure not supported)
Compliance and Auditability	Partially Met** (Claims are shared, APIs are auditable, but no regulatory standards are defined for the schema)

*Flexible Definition of Claims: The OAuth claims in the draft follow the claims exposed and defined by IANA OAuth Parameters. Hence, the metadata fields are limited to a fixed set of claims. This makes it difficult to convey richer features about the client, including provenance details, compliance attestations, or contextual trust scores without introducing vendor-specific extensions, thereby reducing portability and interoperability. **Security and Privacy, Compliance and Auditability: All metadata is published to a publicly accessible endpoint. There is no native ability to keep certain attributes private, apply selective disclosure, or restrict visibility based on trust relationships. Sensitive operational data or compliance-related data must be handled outside the metadata framework, leading to fragmented trust models. There is no mechanism for revocation and expiration.

Solution Approach 4: Client-ID Metadata + W3C Verifiable Credentials Extension

Client-ID Metadata with VC Verification Flow | | | | | | | 2. HTTP GET (URL) | | |--------------------->| | | | | | 3. Returns Metadata | | | (JWKS + "vc+jwt") | | |<---------------------| | | | | | 4. Validate Metadata | | | & Verify VC Signature (JWKS) | | | ]]>

Description: The proposed solution is based on Solution 3, but enhances the supported claims with a new claim, "vc+jwt", based on the Verifiable Credentials Data Model 2.0 from W3C.

vc+jwt

A standard method used in decentralized identity to package and secure a digital credential. The Verifiable Credential (VC), the actual data proving a fact (e.g., identity or degree), is encapsulated within a JSON Web Token (JWT), which provides a cryptographic signature from the issuer. This signature allows any third party (the Verifier) to instantly confirm the credential's authenticity and integrity. Modern formats like SD-JWT VC further enhance this by enabling the holder to share only specific parts of the credential (Selective Disclosure) to protect privacy.

Discussion:

Requirement	Met or Partially Met	Not Met
Dynamic Identity for Agents and MCP Servers	Met
Interoperability Across Domains	Met (1)
Flexible Definition of Claims	Met (2)
Dynamic Management of Authorization Information	Met
Security and Privacy	Met (3)
Compliance and Auditability	Met (4)

Detailed explanations: The W3C Verifiable Credentials Data Model 2.0 addresses the shortcomings of the previous Solution 3, by introducing a cryptographically verifiable and standards-based way to assert identities, capabilities, and compliance attestations. It supports selective disclosure to protect sensitive information, enables time-bound and revocable authorizations, and ensures provenance tracking for audit and regulatory compliance. They are part of a broader decentralized identity (DID) specification. Using the W3C Verifiable Credentials Data Model 2.0 for Agents, MCP Clients, and MCP Servers provides a standardized, cryptographically secure way to establish trust, delegate authority, and ensure interoperability across different systems. It enables Agents, MCP Clients, and MCP Servers to prove, among other things, their identities, identity issuers and provenance, supported skills and permitted actions through verifiable proofs, including support for fine-grained and time-bound access control, while maintaining transparency enabling audit trails for compliance. Additionally, it enhances privacy through selective disclosure and privacy-preserving proofs (e.g., allowing Agents to prove skills and authorized actions without exposing unnecessary details). The Verifiable Credentials Data Model 2.0 is a W3C standard that fits the needs expressed above: (1) Enhanced Interoperability: VCDM 2.0 provides a standardized, extensible way to express identities, capabilities, and compliance data across different systems. Its use of DIDs and schema-governed claims ensures that Agents, MCP Clients, and MCP Servers can verify and exchange trust information, enabling consistent interoperability across domains and platforms. (2) Flexible Definition of Claims: VCDM 2.0 allows arbitrary, schema-governed claims that can represent complex concepts such as provenance, software supply-chain attestations (e.g., SLSA), security posture, audit certifications (SOC2, ISO-27001), or dynamic trust signals. These claims can be extended without breaking interoperability, thanks to widely adopted JSON-LD and schema registries. (3) Security and Privacy: Credentials are signed using verifiable cryptographic proofs (e.g., JSON Web Signatures, Data Integrity proofs). This ensures that Agents, MCP clients, and MCP servers can verify the authenticity of claims without relying solely on HTTPS endpoints or centralized registries. Through techniques like BBS+ signatures, holders can disclose only the subset of claims required for a given authorization flow. This is essential for scenarios where Agents must prove capabilities (e.g., "I'm allowed to execute this skill") without revealing unnecessary or sensitive identity attributes. (4) Compliance and Auditability: VCDM 2.0 enables cryptographically verifiable audit trails by binding each credential to an issuer, timestamp, and revocation status. Compliance attestations can be embedded directly in credentials, and real-time revocation checks ensure they remain valid. This provides trustworthy provenance, regulatory-grade accountability, and reliable lifecycle tracking across distributed systems.

Delegation Semantics for Cross-Domain Multi-Agent Workflows Multi-agent systems frequently involve chains of delegation where Agent A invokes Agent B, which may invoke Agent C, potentially spanning multiple administrative domains. This section defines authorization semantics for such delegation chains, addressing the novel challenges of cross-domain delegation. Humans rarely delegate authority through multiple levels across organizational boundaries. Agents routinely do so. Existing delegation mechanisms ( Token Exchange 'act' claims) assume single-domain operation and do not address cross-domain VC-based delegation with verifiable accountability chains.

Delegation Models This specification supports two delegation models:

Direct Invocation

Agent A directly invokes MCP Server M using A's own credentials. No delegation occurs; authorization is based solely on A's VC.

Delegated Invocation (Cross-Domain)

Agent A in Domain X invokes Agent B in Domain Y to perform a task. B acts on A's behalf (and transitively, on behalf of A's originating principal) when accessing resources. The authorization decision considers both A's delegation grant and B's own credentials, applying Domain Y's policies.

Cross-Domain Delegation Flow | | | | | | | | | | | 2. Delegate + VC(A)| | | |------------|------>| | | | | | | | | | | 3. Request | | | | | + VC(B) | | | | | + Deleg(A) | | | | |-------------->| | | | | | | | | | 4. Verify chain | | | | 5. Apply local policy | | | | 6. Authorize ]]>

Scope Derivation Rules When Agent A delegates to Agent B (potentially across domains), B's effective scope MUST be computed as the intersection of:

1. A's delegatable scope: The subset of A's permissions that A is authorized to delegate
2. B's intrinsic scope: The permissions B holds in its own VC
3. Explicit delegation grant: What A actually delegated to B for this invocation
4. Receiving domain policy: The maximum scope the receiving domain permits for this cross-domain delegation

Scope Derivation Formula

This ensures:

• B cannot exceed A's authority (no privilege amplification)
• B cannot exceed its own authority (intrinsic limits apply)
• A can further restrict B for specific tasks (explicit grant)
• The receiving domain retains sovereignty over its resources (local policy)

Implementations MUST enforce monotonic scope narrowing: at each delegation step, effective scope can only decrease or remain the same, never increase. This intersection semantics aligns with capability-based security principles (see: Mark Miller's Principle of Least Authority, Google Macaroons, Biscuit authorization tokens) and extends Token Exchange delegation semantics to cross-domain VC-based scenarios.

Accountability Chain Construction Each delegation step MUST produce a verifiable record enabling cross-domain forensic reconstruction.To support revocation and scope-change handling, delegation records SHOULD enable downstream verifiers to identify and validate upstream delegation elements so that authorization decisions do not depend on revoked or superseded delegation claims. The delegation record MUST include: Delegation Record Fields

Field	Description	Cross-Domain Relevance
delegator_id	Agent A's id from its VC	Enables tracing to originating domain
delegator_domain	Domain that issued A's VC	Identifies trust relationship to verify
delegatee_id	Agent B's id from its VC	Identifies receiving agent
delegatee_domain	Domain that issued B's VC	Identifies receiving domain
timestamp	Time of delegation	Temporal ordering for forensics
granted_scope	Scopes delegated	Audit of intended authorization
expiration	Delegation validity period	MUST NOT exceed delegator's VC expiration
chain_hash	Cryptographic binding to prior chain	Ensures chain integrity across domains

The complete accountability chain enables:

1. Cross-domain attribution: Determining which principal originated a request that traversed multiple domains
2. Forensic reconstruction: Rebuilding the sequence of delegations across domain boundaries
3. Coordinated revocation: Identifying downstream delegations in other domains that must be invalidated

Delegation Depth Limits Implementations SHOULD enforce maximum delegation depth. Cross-domain delegations SHOULD count toward depth limits regardless of whether they're same-domain or cross-domain. Receiving domains MAY impose stricter depth limits than the originating domain. When a delegation would exceed the receiving domain's depth limit, the AS MUST reject the request with an error indicating the depth violation.

Delegation Claims in VCs To express delegation authority in VCs, the following claims are defined for credentialSubject:

Delegation Claims Example

delegation.permitted

Boolean indicating whether this agent may delegate. Default: false.

delegation.maxDepth

Maximum additional delegation hops this agent may initiate. Default: 0.

delegation.crossDomainDelegation.permitted

Whether cross-domain delegation is allowed at all.

delegation.crossDomainDelegation.allowedDomains

Domains to which delegation is permitted (wildcards allowed).

delegation.scopeRestrictions.crossDomainNonDelegatable

Scopes that may be delegated within the same domain but MUST NOT be delegated across domain boundaries.

Agent Authorization Verifiable Credential Profile This section defines a Verifiable Credential profile that enables interoperable cross-domain agent authorization. The profile specifies claims that Authorization Servers in different domains can reliably interpret. W3C VCDM 2.0 is intentionally flexible. For cross-domain interoperability, domains must agree on claim semantics. This profile provides that common language. The claims in this profile are defined at the top level of the credential subject. They can be carried as plain JWT claims for direct identity presentation, or wrapped in a VC for cross-domain use where selective disclosure, revocation, and issuer-independent verification are required. This document specifies the claim hierarchy, not an exhaustive set of nested fields, so that implementations can adopt the profile without committing to a specific serialization of every attribute.

Profile Objectives The Agent Authorization VC Profile (AAVC) enables:

• Cross-domain interoperability: ASs in different domains can parse and evaluate the same VC
• Semantic clarity: Claim meanings are defined, reducing policy skew risk
• Extensibility: Organizations can add custom claims without breaking base interoperability
• Selective disclosure compatibility: Claims are structured to support SD-JWT VC presentation

Required Claims for Cross-Domain Interoperability The credentialSubject MUST include these claims for a VC to be recognized across domains:

id (required)

Globally unique identifier for the agent. SHOULD be a dereferenceable URI pointing to client-id metadata.

agentType (required)

Classification of the agent. Receiving domains use this to apply type-specific policies. Implementations MUST support:

• tool-agent: Provides specific tool/skill capabilities
• orchestrator-agent: Coordinates other agents
• workflow-agent: Executes multi-step workflows
• system-agent: Long-running infrastructure agent
• ephemeral-agent: Short-lived, single-task

authorizedScopes (required)

Authorization scopes this agent may request. Receiving domains map these to local authorization policies.

issuerDomain (required)

Administrative domain of the credential issuer. Receiving ASs use this to look up trust relationships and policy mappings.

Recommended Claims for Production Deployments

dataSensitivityClearance (recommended)

Maximum data sensitivity level this agent may access. Standard values:

• public - Publicly available information
• internal - Organization-internal, non-sensitive
• confidential - Business-sensitive information
• restricted - Highly sensitive, need-to-know basis
• regulated - Subject to regulatory controls (PII, PHI, PCI)

complianceAttestations (recommended)

Compliance certifications relevant to cross-domain trust decisions. Should include standard, scope, validUntil, and optionally certificationBody.

operationalConstraints (recommended)

Runtime constraints that receiving domains MAY enforce, including maxConcurrentSessions, maxRequestsPerMinute, allowedTimeWindows, and geofence restrictions.

delegation (recommended)

Delegation permissions as defined in .

Extension Mechanism Organizations MAY extend the profile with additional claims by:

1. Defining a JSON-LD context document for the extension
2. Including the extension context URI in the VC's @context array
3. Adding extension claims under a namespace prefix

Implementations receiving VCs with unrecognized claims SHOULD:

• Ignore unknown claims (do not reject the VC)
• Log unrecognized claims for operational visibility
• NOT make authorization decisions based on claims they cannot interpret

Interoperability Requirements For cross-domain interoperability, implementations: MUST:

• Support required claims (id, agentType, authorizedScopes, issuerDomain)
• Recognize the AgentAuthorizationCredential type
• Verify the credential proof before processing claims
• Reject VCs missing required claims

SHOULD:

• Support recommended claims
• Implement selective disclosure for cross-domain presentations
• Maintain logs of cross-domain VC presentations

MAY:

• Define and process organization-specific extensions
• Implement additional validation beyond profile requirements

Relationship to JWT Profile Approaches Other work defines JWT profiles with predefined claims for agent and principal identity, for example a profile that carries agent, agent platform, and human identity claims as typed JSON in a signed JWT . That approach uses standard JWT claims without a JSON-LD context or a Verifiable Credential proof structure. A JWT profile of that kind fits direct identity presentation, where an agent asserts its identity and its principal's identity to a single service endpoint. Validation follows ordinary JWT processing and no VC infrastructure is needed. The VC-based approach in Solution Approach 4 targets cross-domain authorization, where an Authorization Server in one domain evaluates a credential issued in another domain without a direct trust relationship to the issuer's token endpoint. The proof is bound to the credential rather than to the transport or the issuing endpoint. This allows selective disclosure, revocation, and verification by a party that does not trust the issuer's infrastructure directly. The approaches are complementary. The claim set defined by the Agent Authorization VC Profile can be carried as plain JWT claims for direct presentation, or wrapped in a VC for cross-domain use where the additional properties are needed. An agent can hold both forms. The choice depends on the deployment context described in .

Example This section provides illustrative examples of how Client-ID Metadata can be extended with Verifiable Credentials for agent identity. These examples demonstrate the recommended Approach 4 and show how the concepts apply to scenarios similar to the travel booking use case described earlier. These examples are non-normative and intended to demonstrate the concepts discussed in this document.

Client-ID Metadata Example The following example shows OAuth client metadata that includes a Verifiable Credential in the "vc+jwt" field: The "vc+jwt" field contains a JWT-encoded Verifiable Credential. The actual JWT would be significantly longer and contain the complete credential structure shown in the next subsection.

Verifiable Credential Example The following example shows the decoded structure of a Verifiable Credential for an agent (before JWT encoding): Note: The actual credential would include a "proof" section with cryptographic signatures. The proof section is omitted here for clarity, as it would add significant length to the example. The proof structure varies depending on the signature suite used (e.g., Ed25519Signature2020, JsonWebSignature2020).

Related Work Several efforts address adjacent parts of the agent authorization problem. describes agent authentication and authorization using a WIMSE-based architecture and OAuth 2.0. It works at the protocol flow layer, covering identity chaining and token exchange. This document works at the credential layer, covering the claims carried in client-id metadata. The two address different layers of the same problem. defines a JWT profile for agent identity and payment tokens. The relationship to the VC-based approach is discussed in . Academic analysis of agent and tool-protocol security supports the threat categories in this document, including formal study of protocol-level authentication gaps and measurement of authentication weaknesses in deployed servers . Work on authenticated delegation for agents extends OAuth and OpenID Connect with agent-specific credentials and auditable delegation . Work in the Coalition for Secure AI (CoSAI) on agentic identity and access management, and on secure design patterns for MCP-based systems, provides the enterprise framing within which the protocol mechanisms in this document operate. See and .

Security Considerations

Security Considerations This section addresses security considerations specific to cross-domain authorization information sharing. Implementations MUST also follow security guidance in , , and .

Threat Model for Cross-Domain Authorization Sharing This section defines threats specific to sharing authorization information across administrative domain boundaries. General OAuth and VC security threats are addressed in and ; this section focuses on threats that emerge or are amplified when credentials cross domain boundaries.

Protected Assets in Cross-Domain Scenarios Beyond standard authorization assets, cross-domain sharing introduces additional assets requiring protection:

Cross-Domain Trust Relationships

The established trust between domains that enables agents to operate across organizational boundaries. Compromise affects all agents relying on that trust relationship.

Shared Authorization Semantics

The agreed-upon meaning of claims, scopes, and compliance attestations between domains. Semantic drift or manipulation can cause authorization decisions that violate one or both domains' policies.

Delegation Chains Spanning Domains

When agent A in Domain X delegates to agent B in Domain Y, the chain itself becomes an asset requiring integrity protection across trust boundaries.

Cross-Domain Specific Threat Actors

Rogue Domain

An entire domain that participates in the trust federation but issues fraudulent VCs or makes incorrect authorization decisions, either through compromise or malicious operation. Unlike a single rogue IdP, a rogue domain may control IdP, AS, and metadata endpoints coherently.

Cross-Domain Insider

An administrator with legitimate access in Domain A who abuses cross-domain trust relationships to gain unauthorized access to Domain B's resources.

Cross-Domain Attack Categories

Trust Anchor Attacks

Metadata Endpoint Compromise

An attacker gains control of the URL hosting an agent's client-id metadata document and substitutes malicious metadata or VCs. Because the metadata URL is the trust anchor for cross-domain identity, compromise enables complete identity takeover across all trusting domains. Cross-domain amplification: In single-domain scenarios, the AS typically has out-of-band trust with clients. In cross-domain scenarios, the metadata endpoint IS the sole trust anchor, and there's no fallback.

Metadata Poisoning

Injection of false claims into legitimate metadata documents through supply chain attacks, DNS hijacking, or exploitation of hosting infrastructure. Cross-domain amplification: Poisoned metadata propagates trust violations to all domains that fetch and cache the metadata.

Semantic Attacks

Policy Skew Exploitation

An agent authorized under Domain A's policies operates in Domain B where different security policies apply. The agent performs actions that are within Domain A's authorized scope but violate Domain B's policies.

Claim Semantic Drift

Domains interpret the same claim differently, leading to authorization decisions that neither domain intended.

Compliance Attestation Mismatch

Compliance attestations (SOC2, ISO-27001, GDPR) in VCs are accepted at face value without verifying that the issuing domain's certification scope covers the receiving domain's requirements.

Delegation Attacks Across Domains

Cross-Domain Privilege Amplification

In multi-hop delegation (A to B to C) where agents belong to different domains, downstream agents in permissive domains accumulate effective permissions that exceed what the originating principal intended.

Accountability Chain Breakage

Delegation chains that cross domain boundaries lose forensic continuity. When incidents occur, attribution cannot be reconstructed because each domain only has partial visibility.

Confused Deputy Across Trust Boundaries

An attacker in Domain A tricks a trusted agent in Domain B into performing actions on their behalf that the attacker couldn't perform directly, exploiting the cross-domain trust relationship. See .

Cross-Domain Lateral Movement Using legitimate cross-domain authorization to pivot from a compromised position in Domain A to resources in Domain B that would not otherwise be accessible. An attacker compromises a low-privilege agent in Domain A. That agent has cross-domain authorization to Domain B. The attacker uses the agent's credentials to establish a foothold in Domain B, then escalates within Domain B.

Correlation and Privacy Attacks Linking agent activities across domains using stable identifiers in VCs to build profiles of organizational operations, potentially revealing sensitive business processes or security postures. Cross-domain amplification: In single-domain scenarios, the domain controls what's logged. In cross-domain scenarios, each domain receiving the VC can correlate independently, and the agent's home domain cannot prevent this.

Tool Registry Poisoning Agents discover available tools by querying a registry or directory. Any dynamic tool discovery mechanism is therefore an authorization input. If a registry entry is mutable, unsigned, stale, or redirected, the Authorization Server may end up authorizing the wrong executable capability. An attacker who can write to the registry, or redirect the endpoints it points to, can substitute malicious tool definitions or reroute tool calls to an attacker-controlled server. Most agent frameworks do not verify tool integrity at invocation time, so once an entry is in the registry the agent treats it as trusted and the redirection is not visible to the caller.

Registry Write Compromise

Direct modification of tool entries through the registry database or its management API.

Endpoint Redirection

Repointing a tool's endpoint URL to an attacker-controlled host, for example through DNS hijacking or a stale entry whose original host is no longer controlled by the tool provider.

Supply Chain Injection

Inserting malicious tools into the registry through a compromised build or publishing pipeline.

Cross-domain amplification: a registry shared across domains propagates a poisoned entry to every domain that resolves tools through it. A single write compromise affects all consumers. Mitigation binds the tool identity to its implementation so the Authorization Server can verify it. A vc+jwt credential can carry a cryptographic fingerprint of the tool, for example a SHA-256 hash of the tool definition or a subresource integrity hash of the endpoint contract, which the verifier checks before authorizing the call. The endpoint's TLS certificate is verified against an expected value at invocation time, and registry entries are revalidated against a known-good baseline on a schedule. This attack class and its mitigations are discussed in recent work on tool squatting and tool poisoning in agent tool registries .

Empirical Validation of the Threat Model Between February and April 2026, the threat categories above were exercised by public incidents and measurement studies. This section maps observed events to the threat model. The intent is to show that the threats produce real consequences, not to attribute specific products.

Autonomous Agent Exploitation of CI/CD Pipelines An autonomous agent ran a multi-day campaign against continuous integration pipelines across repositories at several technology companies. It obtained remote code execution in multiple targets, using a different technique for each pipeline configuration. The agent held valid credentials throughout. The failure was not in identity verification but in the absence of intent validation and scope enforcement. One target was not compromised because a code review step detected the injected instructions and refused to act on them. Maps to: confused deputy across trust boundaries () and cross-domain lateral movement (). Valid credentials with invalid intent is the core pattern. The vc+jwt approach in this document carries scope and operational constraints that an Authorization Server can check against the requested action, which a bare credential check cannot.

Enterprise AI Platform Breach An offensive agent reached the production database of an internal AI platform in under two hours, without credentials, by finding unauthenticated API endpoints and a SQL injection path. The same access allowed modification of the prompts that governed the platform's behavior. Maps to: metadata endpoint compromise (). The platforms that host and coordinate agents are themselves authorization targets and need the same rigor as the agents they run. The ability to alter governing prompts through the same access is a trust poisoning path that authorization controls on the platform itself would constrain.

Optional Authentication in Tool Servers Public vulnerability records in this period described missing authentication for critical functions in deployed MCP server implementations, including a server-side request forgery path reachable without an authorization header and a critical-function authentication gap that allowed an unauthorized network attacker to act on the server . A measurement study of remote MCP servers in the same period found unauthenticated tool exposure to be widespread . The common root cause is that the protocol treats authentication as optional and leaves it to each implementer. Maps to: credential forgery () and the broader gap this document addresses. Making agent identity a required part of the metadata that an Authorization Server fetches, rather than an optional implementation choice, removes the class of failure that comes from optional authentication.

Silent Trust Boundary Failure in an Agent Framework An agent orchestration framework was found to allow a chain from prompt injection to sandbox escape to remote code execution. The sandbox fell back to an unsandboxed mode when its container runtime was unavailable, without signaling the change, so the agent and the orchestrator both assumed isolation that was not in effect. Maps to: delegation attacks across domains (). A verifiable assertion about an agent's execution environment, carried in its credential, lets an Authorization Server decide based on the actual enforcement state rather than an assumption about the framework.

Trust Establishment Between Domains

Domain Trust Lists Before accepting VCs from another domain, an Authorization Server MUST verify that the issuing domain is in an explicitly configured trust list. Implementations MUST NOT implicitly trust domains based solely on successful cryptographic verification of the VC. Trust list entries SHOULD include:

• Domain identifier (issuerDomain claim value)
• Accepted VC types from that domain
• Scope of trust (which local resources may be accessed)
• Expiration or review date for the trust relationship

Cross-Domain Policy Mapping Implementations MUST NOT assume semantic equivalence of claims across domains. Before accepting a VC from another domain, the AS SHOULD verify:

1. Explicit mapping exists between the foreign domain's claim semantics and local policy requirements
2. Compliance attestations in the VC meet local regulatory requirements (not just the issuing domain's)
3. Scope values have been mapped to local authorization semantics

Trust Relationship Lifecycle Cross-domain trust relationships MUST have defined lifecycles:

• Periodic review and re-validation
• Documented procedures for trust relationship termination
• Immediate revocation capability when a trusted domain is compromised
• Notification mechanisms between domains for security events

Metadata Endpoint Security for Cross-Domain Trust Because the client-id metadata endpoint is the sole trust anchor for cross-domain agent identity, it requires enhanced protection beyond typical endpoint security.

Endpoint Integrity Beyond Transport Metadata documents SHOULD be signed independently of the transport layer, allowing verification even if TLS is compromised or if the document is cached by intermediaries.

Change Detection for Cached Metadata Authorization Servers SHOULD:

• Cache fetched metadata documents with appropriate TTLs
• Detect and alert on unexpected changes to critical fields (jwks_uri, vc+jwt, token_endpoint_auth_method)
• Implement anomaly detection for metadata that changes more frequently than expected

Cross-Domain Availability Dependencies When metadata endpoints are unavailable, cross-domain authorization fails. Implementations SHOULD:

• Cache validated metadata with TTLs appropriate to the sensitivity of protected resources
• Implement circuit breakers to prevent cascading failures
• Define graceful degradation policies

Delegation Security Across Domain Boundaries

Domain Boundary Checkpoints When a delegation chain crosses a domain boundary, the receiving domain's AS MUST:

• Fully verify the upstream delegation chain before accepting
• Apply local policy to the delegation
• Log the domain boundary crossing for audit purposes

Receiving domains SHOULD consider the status of delegated credentials and, where status information is available, avoid making authorization decisions that rely on revoked,suspended, or suspended delegation chain elements, according to local policy. Deployments concerned with stale delgations MAY apply bounded caching and periodic revalidation of delegation status appropriate to the sensitivity of protected resources.

Monotonic Scope Narrowing Across Domains Implementations MUST enforce that effective scope can only decrease (or remain the same) at each delegation step, including when crossing domain boundaries. The receiving domain MUST apply its local policy as an additional constraint on effective scope.

Accountability Chain Preservation Delegation chains spanning domains MUST maintain cryptographically verifiable accountability. Each domain SHOULD:

• Preserve the incoming delegation chain in its audit logs
• Add its own delegation record when extending the chain
• Provide APIs for authorized forensic queries from upstream domains

Privacy Considerations for Cross-Domain Sharing

Selective Disclosure for Cross-Domain Presentations Agents presenting VCs across domain boundaries SHOULD use selective disclosure mechanisms (SD-JWT VC, BBS+ signatures) to reveal only claims necessary for the specific cross-domain authorization request.

Correlation Risk Assessment Organizations SHOULD assess cross-domain correlation risks before establishing trust relationships, including whether agent identifiers enable activity tracking by foreign domains.

IANA Considerations This document introduces a new OAuth client metadata parameter "vc+jwt" as described in the Solution Analysis section (Approach 4). If this approach is standardized, the following registration would be required:

• Registry: IANA [`OAuth Dynamic Client Registration Metadata`](https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#client-metadata) registry
• Client Metadata Name: vc+jwt
• Client Metadata Description: JWT-encoded Verifiable Credential
• Change Controller: TBD
• Reference: https://www.w3.org/TR/vc-data-model-2.0

This informational document does not make a formal request for IANA registration at this time. Registration would be appropriate if this approach is adopted and progresses to a standards track specification.

References Informative References W3C National Cybersecurity Center of Excellence, NIST National Vulnerability Database, NIST Coalition for Secure AI (CoSAI), OASIS Coalition for Secure AI (CoSAI), OASIS

Mapping Mechanisms to Deployment Contexts The mechanisms in this document apply with different rigor depending on the deployment. This appendix is informative. Not every deployment needs every mechanism. The intent is to identify a minimum set of controls for a given risk profile and a path from what is deployable today to what is needed for regulated cross-domain operation.

Level 1, Sandbox or Development

Isolated environments with no production data and no cross-domain connectivity. Standard OAuth2 with local scope management. The cross-domain mechanisms in this document are not required.

Level 2, Internal and Non-Sensitive

A single administrative domain accessing non-sensitive resources. Client-ID Metadata without VCs (Solution Approach 3) can be sufficient. Basic OAuth scope management applies. Delegation is limited to direct invocation. This level is supportable on existing IdP and Authorization Server infrastructure without new components.

Level 3, Production and Cross-Domain

Operation across domains on business-sensitive resources. Client-ID Metadata with Verifiable Credentials (Solution Approach 4). The vc+jwt claim carries compliance attestations and operational constraints. Delegation with scope intersection applies. Sender-constrained tokens are recommended. Credential lifetimes are bounded and revocation is checked. This level needs VC issuance but not hardware-attested key storage.

Level 4, Regulated and High-Assurance

Regulated data or irreversible operations across domains. All Level 3 mechanisms apply, plus hardware-attested key storage, cryptographic binding between agent identity and execution environment, and re-authorization at trust boundary crossings. Audit logging supports cross-domain forensics. Selective disclosure is used to limit data exposure in cross-domain presentations.

The expected path is to start at Level 2 and add VCs (moving to Level 3) when cross-domain requirements appear, without replacing the underlying authorization infrastructure.