The pattern across nine series of this publication is consistent. Each series documents an attack class. Each attack class turns out to exploit a structural absence — not a failure of implementation, not a misconfigured tool, but the absence of an architectural property that would make the attack class structurally infeasible. Injection attacks exploit the absence of command-data boundary enforcement. Memory Control Flow Attacks exploit the absence of memory isolation architecture. Supply chain attacks exploit the absence of provenance verification. And threading through all of them, as the precondition every control depends on, is the absence of verified agent identity.
Without verified identity, memory isolation is bypassable by a rogue agent claiming the identity of a trusted one. Without verified identity, provenance attestation chains can be forged by an attacker who obtains a signing key. Without verified identity, policy enforcement is operating on trust assertions that have no cryptographic basis. Identity is not one control among many in the agentic AI security stack — it is the condition under which all the other controls are meaningful.
This is the claim that Series 9 has been building toward. Not that identity is important — that is obvious. The claim is structural: the controls documented across Series 2 through 8 of this publication are each necessary and each valuable. They are not independently sufficient. Their sufficiency depends on the identity layer that most enterprise deployments have not built. A deployment with provenance attestation but no verified agent identity has provenance that can be forged. A deployment with memory isolation but no verified agent identity has isolation boundaries that a rogue agent can claim authorization to cross.
The Three-Layer Trust Architecture
The controls documented in Posts 1 and 2 of this series — and the identity infrastructure they depend on — form a three-layer trust architecture. Each layer is independently valuable and collectively necessary.
Privilege Separation
The quarantine agent / action agent pipeline structurally separates the component that processes untrusted content from the component that executes privileged actions. Untrusted content cannot reach the action layer. Injection payloads are structurally blocked from reaching the tool-invocation layer.
Closes: Injection-to-action attack surface. 0% ASR against 649 attacks. (arXiv:2603.13424)
Does not close: The trust question of who is issuing instructions to the action agent. A rogue orchestrator can still send malicious delegation instructions to the action agent’s upstream layer.
Structural · EnforceableVerifiable Delegation Chains
IBCTs carry the full delegation chain from user authorization through every intermediate agent, with scope attenuation at each hop. Every downstream component can verify that an invocation is authorized within a traceable chain from legitimate user intent. Forged delegation is detectable because no forged block can carry the upstream agent’s valid signature.
Closes: The delegation verification gap. Answers the four questions: who authorized, through which chain, with what constraints, what was the outcome. (arXiv:2603.24775)
Depends on: Agent identity being cryptographically verifiable — the delegation chain is only as trustworthy as the identity anchoring each block.
Chain-Verified · Scope-AttenuatedWorkload Identity (SPIFFE)
SPIFFE (Secure Production Identity Framework For Everyone) provides cryptographically verifiable identity documents (SVIDs) to workloads at runtime, regardless of deployment environment. An agent provisioned with a SPIFFE identity has a verifiable credential that it can present to any downstream component — and that the downstream component can verify without trusting the agent’s self-assertion.
Provides: The identity anchor that makes delegation chain verification meaningful. Without this layer, IBCTs bind to self-asserted identities that could be forged. With this layer, each block in the delegation chain binds to a SPIFFE-verified workload identity.
Identity-Anchored · Runtime-ProvisionedThe three layers are not sequential steps — they are concurrent requirements. A deployment with privilege separation and delegation chains but no workload identity has chains whose identity bindings are self-asserted. A deployment with workload identity and delegation chains but no privilege separation has a processing pipeline where injected content can still reach the action layer. The full architecture requires all three, and each layer reinforces the others.
What SPIFFE Provides for Agent Identity
SPIFFE was designed for the microservices world: a runtime framework that issues cryptographically verifiable identity documents to workloads without requiring human operators to manage certificates manually. Its core abstraction — the SPIFFE Verifiable Identity Document (SVID) — is a standard format for workload identity that any component in a distributed system can issue and verify.
SPIFFE/SVID Applied to Agent Workloads
A SPIFFE identity is issued at deployment time to each agent workload — not to the human user operating the agent, but to the agent runtime itself. The SVID takes the form of a URI following the pattern spiffe://trust-domain/path, cryptographically signed by the trust domain’s certificate authority. When an agent presents its SVID to a downstream component, that component can verify: that the SVID was issued by a trusted authority, that it has not expired, and that the agent presenting it is the workload that holds the corresponding private key.
Applied to the AIP delegation chain: each block in an IBCT binds to the SPIFFE identity of the delegating agent, signed with that agent’s private key. A downstream component verifying the chain verifies not only that each block is cryptographically signed, but that each signature corresponds to a SPIFFE-verified workload with a known identity within the trust domain. The chain from user authorization through each intermediate agent is both cryptographically linked and identity-verified.
The practical significance is in what SPIFFE eliminates: the need for each agent to trust another agent’s self-assertion of identity. Self-asserted identity is what makes the 100% inter-agent trust exploitation rate possible — an attacker who can inject a message claiming to be from a trusted orchestrator succeeds because nothing verifies the claim. SPIFFE-anchored identity eliminates the self-assertion: each agent’s identity is issued by a trusted authority and verifiable by any downstream component without relying on the agent’s own claim.
The MAC Framework Layer: SEAgent
The Mandatory Access Control framework introduced by SEAgent (arXiv:2601.11893) adds a fourth dimension to the trust architecture that the three-layer model above does not fully address: the enforcement of access control policies at runtime, based on the verified identity and context of each agent action. MAC frameworks from traditional operating systems security encode rules about what identities can do — what resources they can access, what operations they can perform, what data they can read or write. SEAgent extends this to the agent layer.
Attack vectors that SEAgent’s Mandatory Access Control framework addresses in agent systems: direct prompt injection, indirect prompt injection, RAG poisoning, confused deputy attacks, and untrusted agent interactions. In multi-agent systems, SEAgent maintains isolated entity dictionaries per agent — preventing context leakage or manipulation across agent boundaries. In multi-user settings, strict user-level isolation ensures that user-specific history and execution paths remain separated. The MAC framework enforces at runtime what privilege separation and delegation chains provide as architecture.
The MAC layer does not replace the other three layers — it enforces their policies at runtime. Privilege separation defines which components can access which surfaces. Delegation chains define what authority has been granted through which chain. Workload identity anchors the identities in those chains to verifiable credentials. MAC enforcement ensures that runtime agent behavior conforms to the policies that privilege separation, delegation, and identity define — catching deviations that the structural controls cannot prevent but that policy can flag and block.
Why Every Prior Control Now Makes More Sense
The cross-series implication of the identity architecture argument is worth making explicit, because it reframes every control documented since Series 2.
Memory isolation (Series 7) was framed as constraining what memory can reach. Its full power is realized when the agent attempting to access memory across an isolation boundary can be cryptographically identified as unauthorized. Without identity, memory isolation relies on the memory system’s own access controls. With identity, it relies on verifiable agent credentials — a structurally stronger enforcement.
Provenance attestation (Series 8) closes the substitution gap for supply chain artifacts. The adaptive attacker scenario — forged attestation with a valid signing key — requires that the signing key be obtained through identity compromise. SPIFFE-anchored workload identity constrains the attack surface for key compromise: keys are issued at runtime by a trusted authority, rotated automatically, and bound to specific workload identities. Obtaining a valid signing key requires compromising the SPIFFE infrastructure, not merely obtaining a file.
Policy enforcement (Series 5) produces enforceable controls when it can verify who is making a request. Without verified agent identity, policy rules evaluate requests from unverifiable principals. With workload identity, every policy evaluation knows the cryptographically verified identity of the requesting agent — enabling fine-grained, auditable policy decisions rather than identity-blind rules.
Every control documented in this series assumes that agents are who they claim to be. Identity infrastructure is the condition under which that assumption can be verified rather than trusted. Without it, the architecture has controls without enforcement anchors.
— Luminity Digital synthesis from arXiv:2603.13424, arXiv:2603.24775, arXiv:2601.11893The Enterprise Implementation Path
The full trust architecture — privilege separation, delegation chains, workload identity, MAC enforcement — is not a single-sprint project. It is a program with a sensible sequence that produces value at each step.
The April 2026 State of Standards
SPIFFE is production-ready and widely deployed in the Kubernetes ecosystem through SPIRE (the SPIFFE Runtime Environment). It is the workload identity standard with the broadest enterprise adoption. AIP (arXiv:2603.24775) is an alpha-stage protocol with IETF drafting activity but no major ecosystem endorsement yet. WIMSE (Workload Identity in Multi-Service Environments) is an active IETF working group addressing workload identity for multi-service environments that overlaps significantly with the agent delegation use case. Enterprise teams should implement SPIFFE workload identity now, track AIP and WIMSE for delegation chain standards convergence, and design their delegation architectures to accommodate the protocol that achieves ecosystem adoption — likely within 12–18 months at the current trajectory.
The implementation sequence that follows is ordered by value delivery and feasibility, not by theoretical completeness.
First — Privilege separation (available now). Implement the quarantine/action agent pipeline for any agentic deployment that processes untrusted content. This is an architectural change to agent pipeline design, not an identity infrastructure requirement. It delivers 0% ASR against the injection attack surface immediately, without waiting for standards convergence on delegation protocols.
Second — SPIFFE workload identity for agents. Provision each agent runtime with a SPIFFE SVID. This establishes the identity anchor that delegation chains depend on. SPIRE (the SPIFFE Runtime Environment) is production-ready and integrates with Kubernetes and other orchestration platforms. For enterprise deployments already running SPIFFE for microservices, extending coverage to agent workloads is an incremental step, not a new infrastructure program.
Third — Explicit delegation scope constraints. Even before AIP adoption, implement explicit scope constraints on every delegation step. Define what authority an orchestrator can delegate to a specialist, and enforce those limits in the delegation API. This does not require cryptographic delegation chains — it requires policy discipline that will be verifiable once IBCTs are deployed.
Fourth — MAC policy enforcement. Implement mandatory access controls on agent behavior — what identities can access what resources, what operations are permitted in what task contexts. SEAgent’s entity dictionary approach is the most directly applicable framework for enterprise multi-agent deployments. MAC enforcement running against SPIFFE-verified identities is the runtime layer that makes the privilege and delegation architecture enforceable rather than merely designed.
Identity is the foundation. Not a foundation — the foundation. Every structural control documented in this series — from memory isolation to supply chain provenance to behavioral analysis — is structurally stronger when it can verify who is requesting what, through which authorization chain, with what credentials. The trust architecture described in this post is buildable now: SPIFFE workload identity is production-ready, privilege separation is immediately implementable, delegation scope constraints are policy decisions. The cryptographic delegation chain standard is approaching convergence. The enterprise that builds the identity foundation now will be positioned to adopt the delegation protocol when it converges rather than scrambling to retrofit identity into a deployment that assumed it was not necessary.
The controls documented across Series 2 through 9 of this publication address the full structural attack surface of enterprise agentic AI. If your organization is deploying agents at scale and the identity architecture described in this series is not yet in place, the attack surfaces documented in each prior series remain open. Luminity is available for a focused architecture conversation.
Series 10 — The Measurement Problem — examines a question that becomes newly answerable once the identity layer is in place: how do you know when your controls are working? Without verified identity, security measurement in agentic systems is indirect and probabilistic. With it, you can ask auditable questions. Series 10 maps what rigorous agentic AI security measurement looks like.
