How do OAuth 2.0, OpenID Connect, and SPIFFE token propagation work in real…

Research Question

How do OAuth 2.0 (Open Authorisation), OpenID Connect (OIDC), and SPIFFE (Secure Production Identity Framework for Everyone) token propagation mechanisms work in real multi-agent Artificial Intelligence (AI) pipelines, and where does end-to-end attribution break in practice, specifically across agent-to-agent delegation, agent-to-tool handoffs, and cross-system boundary crossings?

Findings

(Populated from §6 Synthesis above.)

Executive Summary

OAuth 2.0 and OpenID Connect (OIDC) preserve enough identity and authorization context for human-initiated Application Programming Interface (API) delegation, but they do not by themselves preserve a portable, end-to-end attribution chain across autonomous multi-agent systems. Secure Production Identity Framework for Everyone (SPIFFE) and cloud workload-federation patterns close the machine-identity problem with short-lived workload credentials, yet they do not encode who originally authorized the work or what user-level scope intent should survive later hops. In the examined frameworks and platforms, attribution breaks when a sub-agent or tool call changes credential type, crosses a trust boundary, or falls back to shared runtime credentials, because native traces expose the current caller more clearly than the original authorizer. The strongest current pattern is hybrid: delegated user tokens for human-initiated hops, workload identity for autonomous hops, explicit edge-bound permission manifests, and a separate audit receipt that persists subject, current actor, target, and scope outside the runtime token.

Key Findings

1. OpenID Connect (OIDC) and delegated OAuth 2.0 flows preserve human identity and delegated authority only for the active subject and current actor, which makes them useful for user-initiated API chains but insufficient as a full historical attribution record for long multi-agent pipelines.
2. Microsoft's on-behalf-of (OBO) implementation illustrates one practical boundary of delegated user-token propagation, because it supports delegated user scopes for middle-tier APIs but explicitly excludes app-only service-principal tokens, which must switch to a machine-oriented credential pattern.
3. SPIFFE provides strong short-lived workload identity and trust-domain verification, but because each SPIFFE Verifiable Identity Document (SVID) represents a single presenting workload and not a delegated human chain, SPIFFE alone cannot express who originally authorized a downstream action.
4. Model Context Protocol (MCP) standardizes how clients authorize to tool servers through Authorization Code or Client Credentials and bearer tokens on every HTTP request, yet it leaves subject-and-actor provenance receipts to implementations rather than defining them as protocol-native artifacts.
5. Amazon Bedrock multi-agent traces preserve valuable agent-routing metadata such as collaborator names, session identifiers, agent versions, and caller chains, but the documented trace schema does not natively bind those records to an end-user principal or delegated scope set.
6. Open-source orchestration frameworks such as CrewAI, AutoGen, and LangGraph treat identity propagation mainly as runtime configuration or application state, so downstream tools are commonly invoked under shared deployment credentials or assistant runtime identity unless developers add explicit per-user or per-hop controls.
7. CrewAI's enterprise features indicate that important parts of the attribution gap are fixable today, because the platform already supports OAuth-scoped integrations, optional user_bearer_token user scoping, authenticated agent-to-agent communication, and per-execution workload identity federation.
8. The remaining gap is a portable delegation-chain receipt that survives across frameworks, tools, and trust domains, because current standards secure individual hops well but do not standardize one verifiable artifact containing original subject, current actor, prior actors, scopes, target resource, and approval context.

Assumptions

• Assumption: Native traces or message events can be enriched with custom application metadata when teams need stronger attribution than the framework provides. Justification: The examined platforms expose enough hooks to attach metadata, but this item did not validate the durability or consistency of those custom extensions.

Analysis

The evidence weighs most strongly in favor of a split model rather than a single universal credential. Delegated user tokens fit hops where a human is actively authorizing access to downstream APIs, because they preserve user identity, audience, and scope semantics that workload identity does not. Workload identity fits hops where a task is autonomous, app-only, or long-running, because those hops need a machine identity that can rotate independently of a human session and survive beyond an interactive consent event. The main trade-off is that user delegation provides better human accountability while workload identity provides better runtime durability and least-secret handling, so practical systems need both and must record where the handoff from one model to the other occurred. Bedrock's native trace depth improves incident reconstruction for agent routing, but open-source frameworks offer more flexibility and therefore require more application-layer identity discipline. Plausible rival remedies exist, including stronger model-quality gates, more human review, or preserving per-item manual approval for sensitive tools, but those rivals mostly reduce misuse probability rather than solving the provenance problem that appears once a tool call has already crossed a boundary. The strongest conclusion is therefore architectural: attribution gaps are partly fixable today with better credential separation, scope narrowing, and audit receipts, while portable cross-framework delegation proof still requires new standardization work.

Risks, Gaps, and Uncertainties

• Public documentation may understate platform-specific hooks or internal telemetry fields that enterprise customers can configure but that are not described openly.
• CrewAI's stronger identity controls are concentrated in the platform's enterprise features, so open-source-only deployments may still face a larger attribution gap by default.
• Bedrock's native trace documentation is rich for agent orchestration, but it does not rule out stronger customer-managed user attribution added outside the documented schema.
• MCP authorization is still evolving, so richer portable provenance fields could emerge without a wholly new protocol if the ecosystem standardizes them.

Open Questions

• Should the repository create a follow-on item for a portable delegation-receipt schema that can be embedded in an Artificial Intelligence Bill of Materials (AIBOM) edge record and emitted by Model Context Protocol (MCP), agent-to-agent, and tool-call frameworks?
• Which existing signing or attestation formats could carry subject, current actor, prior actors, target resource, approval state, and scope intent without exposing unnecessary personal data?
• What is the minimum trace field set that Amazon Bedrock, CrewAI, AutoGen, and LangGraph would each need to expose natively for end-user attribution to become reviewable without custom middleware?

sources

• [x] Internet Engineering Task Force (2020) Request for Comments (RFC) 8693 OAuth 2.0 Token Exchange - primary standard for delegation versus impersonation, subject_token, actor_token, act, may_act, and target-scope narrowing.
• [x] Microsoft (2025) Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow - primary practical documentation for delegated user-token propagation in Microsoft ecosystems.
• [x] OpenID Foundation (2023) OpenID Connect Core 1.0 - primary standard for end-user identity assertions layered on OAuth 2.0.
• [x] SPIFFE (2025) SPIFFE Overview - primary overview of workload identity, trust domains, and SPIFFE primitives.
• [x] SPIFFE (2025) SPIFFE Concepts - primary details on SPIFFE IDs, SPIFFE Verifiable Identity Documents (SVIDs), trust bundles, and the Workload Application Programming Interface (API).
• [x] Model Context Protocol (2025) Authorization - primary MCP authorization specification for Authorization Code, Client Credentials, token handling, and third-party token mapping.
• [x] Model Context Protocol (2025) Transports - primary MCP transport specification for HTTP and standard input and standard output (STDIO) credential handling differences.
• [x] Amazon Web Services (2025) Use multi-agent collaboration with Amazon Bedrock Agents - primary Bedrock documentation on supervisor and collaborator agent orchestration.
• [x] Amazon Web Services (2025) Amazon Bedrock agent trace events - primary Bedrock documentation on callerChain, collaboratorName, sessionId, and trace payload structure.
• [x] CrewAI (2025) Collaboration - primary CrewAI documentation on delegation tools and collaborator messaging.
• [x] CrewAI (2025) Tools - primary CrewAI documentation showing tool execution patterns and shared environment-variable credentials.
• [x] CrewAI (2025) Large Language Models (LLMs) - primary CrewAI documentation showing provider configuration via shared environment variables or runtime configuration.
• [x] CrewAI (2025) Tools & Integrations - primary CrewAI platform documentation on OAuth-connected apps, enterprise tokens, and optional user_bearer_token scoping.
• [x] CrewAI (2025) Agent-to-Agent (A2A) on the CrewAI platform - primary CrewAI platform documentation on agent-to-agent authentication schemes, including OpenID Connect (OIDC), OAuth 2.0, Mutual Transport Layer Security (mTLS), and distributed state.
• [x] CrewAI (2025) Vertex AI with Workload Identity - primary CrewAI platform documentation on per-execution OpenID Connect (OIDC) workload identity federation and short-lived credentials.
• [x] Microsoft (2025) AutoGen Agents - primary AutoGen documentation on agent state, tool execution, and message events.
• [x] Microsoft (2025) AutoGen UserProxyAgent - primary AutoGen source documentation on representing a human user and handoff messages.
• [x] Microsoft (2025) AutoGen Concurrent Agents - primary AutoGen documentation on direct messaging and delegator-worker patterns.
• [x] LangChain (2025) Multi-agent systems - primary LangChain documentation on multi-agent patterns and subagents.
• [x] LangChain (2025) Use subgraphs - primary LangGraph documentation showing explicit state mapping between parent and subgraph contexts.
• [x] Open Worldwide Application Security Project (OWASP) GenAI Security Project (2025) Top 10 for Large Language Model Applications - authoritative security taxonomy covering insecure plugin design and excessive agency.
• [x] Mitchell (2026) AI agent identity and access management enterprise - prior repository item on machine identity, delegation models, and attribution requirements.
• [x] Mitchell (2026) Access control amplification under agentic operations - prior repository item on blast-radius amplification under delegated automation.
• [x] Mitchell (2026) Permission-safe Retrieval-Augmented Generation in enterprise information architectures - prior repository item on cross-boundary retrieval and identity-sensitive access control.
• [x] Mitchell (2026) How should identity, delegation chains, and permission scopes be formally modelled in an Artificial Intelligence Bill of Materials (AIBOM) schema to enable end-to-end attribution across agentic Artificial Intelligence (AI) systems? - prior repository item defining the design target this practice item tests.
• [x] Mitchell (2026) What introspection, export, and control surfaces actually exist across production agentic Artificial Intelligence (AI) platforms? - prior repository item on the runtime evidence substrate available from production platforms.