How should identity, delegation chains, and permission scopes be formally…

Research Question

How should identity, delegation, and permission scopes be formally represented in an Artificial Intelligence Bill of Materials (AIBOM) schema to enable end-to-end attribution, "who authorized what", across multi-agent compositions involving human users, orchestrator agents, sub-agents, tools, and model instances, and where do current identity standards, OAuth 2.0, OpenID Connect (OIDC), Secure Production Identity Framework for Everyone (SPIFFE), and zero-trust guidance, succeed or fail when applied to agentic delegation chains?

Findings

Executive Summary

An AIBOM that can support end-to-end attribution in multi-agent systems should model identity as a typed graph of distinct principals and workload actors linked by explicit delegation edges and bounded permission-scope manifests, not as a flat list of components.

RFC 8693 provides explicit formal semantics for subject, actor, delegation, and impersonation, but it does not itself preserve the whole audit-relevant chain for authorization decisions, so AIBOM must persist full delegation history as a separate design-time artifact.

OpenID Connect and Microsoft Entra On-Behalf-Of remain useful for authenticated human delegation, while SPIFFE remains useful for workload identity and trust-domain verification, but neither layer alone captures effective permissions, trust-boundary policy, and cross-hop provenance.

The practical AIBOM answer is therefore a six-part schema, identity inventory, delegation chain, permission manifests, trust-boundary crossings, credential policy, and attribution requirements, because current standards solve adjacent slices rather than the whole agentic attribution problem.

Key Findings

1. An AIBOM should model human principals, agent workloads, tool or service workloads, model instances, runtime contexts, and trust domains as distinct identity classes, because current standards distribute those concepts across end-user identity, workload identity, and zero-trust subject composition rather than collapsing them into one actor type.
2. RFC 8693 provides explicit concepts that AIBOM can reuse for delegation edges, including subject, actor, authorized actor, delegation, and impersonation, but AIBOM must still persist full prior-hop history separately because nested prior actors are informational only for authorization decisions.
3. OpenID Connect and Microsoft Entra On-Behalf-Of are appropriate for authenticated user-delegated flows, but they do not solve app-only or autonomous multi-hop delegation, so an AIBOM must separate human-identity assertions from workload-identity assertions instead of treating them as one credential class.
4. SPIFFE succeeds at issuing short-lived cryptographic workload identities and trust bundles across trust domains, but it does not define end-user delegation or permission scopes, so AIBOM must layer scope manifests and delegation semantics above workload identity rather than expecting SPIFFE alone to supply authorization meaning.
5. Permission scopes in an AIBOM should be represented as edge-bound manifests containing target resource or audience, allowed operations, delegation mode, credential class, maximum lifetime, approval requirement, and revocation path, because least privilege is enforced at the hop rather than by the identity label alone.
6. A zero-trust-compatible AIBOM must declare trust domains, authentication method, attestation or identity-issuance mechanism, enforcement point, and credential-rotation policy for every boundary crossing, because identity inventories without verification-path metadata do not show how trust is actually established at runtime.
7. Attribution fails most predictably when systems rely on shared service identities, ambient runtime credentials, tool substitution that changes downstream audience, or cross-domain retrieval that cannot bind the original human subject to the current workload actor, so those conditions should be named explicitly in the AIBOM failure-mode register.
8. The minimal formal AIBOM schema for this problem is therefore six linked objects, identities, delegations, permission_manifests, trust_boundary_crossings, credential_policies, and attribution_requirements, because no reviewed standard independently covers all six layers needed for auditable multi-agent operation.

Assumptions

• None.

Analysis

The evidence was weighted toward primary standards where they named formal objects directly, which is why RFC 8693 carries more weight for delegation edges than platform guidance, and why SPIFFE carries more weight for workload identity than OpenID Connect.

Two rival simplifications were considered and rejected. A runtime-only alternative, storing trace logs without design-time identity manifests, was rejected because RFC 8693 makes prior actors informational only for authorization and the adjacent repository items show that missing permission representation leaves downstream evidence semantically incomplete.

The second rival, relying on stronger model quality gates or more frequent human review instead of explicit delegation and scope manifests, was rejected because those controls may reduce misuse probability but they do not create machine-verifiable actor separation or trust-boundary semantics.

The preferred model is therefore not a new identity standard, but a schema-level composition of existing standards into one auditable graph, human identity from OpenID Connect, delegation edges from RFC 8693 style semantics, workload identity from SPIFFE or equivalent, and hop-level enforcement constraints from Zero Trust Architecture and transport-layer authorization.

Risks, Gaps, and Uncertainties

• No reviewed standard defines an AIBOM schema directly, so the recommended field grouping is a synthesis rather than a standards-backed canonical format.
• SPIFFE documentation is explicit about identity issuance and verification but not about application-layer authorization semantics, so claims about what must be added on top of SPIFFE remain partly inferential.
• Platform-specific audit coverage can still vary even when the AIBOM graph is complete, which means schema completeness does not guarantee uniform downstream telemetry quality.

Open Questions

• What is the smallest interoperable serialization for nested delegation chains that preserves audit history without causing token or manifest bloat?
• How should an AIBOM identify model instances when the same logical model is accessed through multiple hosted endpoints with different trust and logging behavior?
• Which runtime trace fields are the minimum necessary companion to the design-time AIBOM so that a post-incident reviewer can bind intent, delegation, and action together without ambiguity?

sources

• [x] National Institute of Standards and Technology (NIST) Special Publication 800-207 Zero Trust Architecture
• [x] Internet Engineering Task Force (IETF) RFC 8693 OAuth 2.0 Token Exchange
• [x] OpenID Foundation OpenID Connect Core 1.0
• [x] OpenID Foundation What is OpenID Connect
• [x] SPIFFE Overview
• [x] SPIFFE Concepts
• [x] SPIFFE Specification
• [x] Microsoft Entra ID On-Behalf-Of flow
• [x] Model Context Protocol (MCP) Authorization specification
• [x] David Mitchell (2026) AI agent identity and access management enterprise
• [x] David Mitchell (2026) Access control amplification under agentic operations
• [x] David Mitchell (2026) Permission-safe Retrieval-Augmented Generation in enterprise information architectures
• [x] David Mitchell (2026) Agentic Artificial Intelligence regulatory preconditions control failure assessment
• [x] David Mitchell (2026) Application Programming Interface (API) context hubs, Retrieval-Augmented Generation (RAG), and the Model Context Protocol (MCP)