This is Post 1 of The Policy Layer, our fifth series on agentic AI security. Series 1 mapped where agentic systems break. Series 2 argued that deterministic architectural enforcement — not probabilistic guardrails — is the structural answer, and established the empirical case for that position. This series goes one level deeper: how deterministic enforcement is actually specified, modeled, and enforced at a mechanistic level. Series 2 established what needs to be built. The Policy Layer explains how to build it — and where it still falls short.
Series 2 made a claim that the research now fully supports: the security problems in agentic AI are not implementation failures but architectural ones, and architectural failures require architectural remedies. Probabilistic defenses — alignment training, prompt scanning, guardrails — are necessary but structurally insufficient. Deterministic controls — mandatory access control, cryptographic authentication, architectural enforcement — are the correct answer at the structural layer. That argument is settled. The empirical anchors are strong. SEAgent demonstrated a 0% attack success rate against privilege escalation through mandatory access control. Authenticated Workflows showed 100% recall with zero false positives across 174 test cases through cryptographic workflow authentication.
What Series 2 left open — deliberately, because the research was not yet there to fill it — was the mechanistic question. Saying that deterministic enforcement is necessary is the correct policy position. It does not, by itself, specify what the system state must look like for that enforcement to be possible. It does not explain what data structure a reference monitor needs to make an authorization decision. It does not address the upstream engineering question of who writes the policies, in what language, against what formal model of system behavior.
A new research stream, anchored by PCAS — the Policy Compiler for Agentic Systems (arXiv:2602.16708, Palumbo et al., February 2026) — provides the formal answers to those questions. This post addresses the foundational one: why the state representation that current agentic frameworks use is structurally incapable of supporting real authorization, and what a correct alternative requires.
What the Token Stream Destroys
To understand why current agentic systems cannot support real authorization, it is necessary to be precise about what current agentic systems actually do. An LLM-based agent operates on a context window — a sequence of tokens representing the accumulated history of the session. That sequence contains everything: the original system prompt, the user’s instruction, the outputs of previous reasoning steps, the results returned by tool calls, and messages received from other agents in a multi-agent deployment. All of it arrives at the model as a single, ordered, flat sequence of tokens.
This is not a bug. It is how LLMs work. The transformer architecture processes sequences. The context window is a sequence. The model attends to all tokens in the window and generates the next token. There is no architectural distinction between a token that came from a trusted system prompt and a token that came from a document retrieved from an external server controlled by an adversary. The model’s attention mechanism operates on the full sequence without regard to the provenance of any particular token.
This is precisely what our earlier research named the command-data boundary collapse: the LLM processes trusted instructions and untrusted data as an undifferentiated token stream, with no architectural separation between them. The diagnosis is correct, and the empirical evidence for it is extensive. Mind the GAP (arXiv:2602.16943) demonstrated across six frontier models and six regulated domains that alignment training which successfully suppresses harmful text outputs does not suppress harmful tool-call actions. The alignment operates on the model’s output token distribution; it cannot operate on a trust boundary that does not exist in the underlying data structure.
But the command-data boundary collapse, while accurate, is the surface manifestation of a deeper structural problem. The deeper problem is this: linear message history destroys provenance. By flattening all events into a single ordered sequence, the context window eliminates the causal relationships between those events that authorization decisions require. You cannot ask “where did the information that influenced this action originally come from?” because the sequence does not encode that relationship. All you can ask is “what tokens appeared before this token?” — and that is not the same question at all.
Why Authorization Requires Provenance
Authorization, in any serious security framework, is not a question about the action being requested. It is a question about the causal history of the request. A database query to read a customer record is authorized or not depending on who initiated the request, through what chain of delegation, with what original mandate, and whether any untrusted input influenced the decision to make that query. The query itself — “read record X” — carries none of that information. The authorization decision requires reasoning about everything that led to the query being generated.
In conventional software systems, this is tractable because the execution model is deterministic and the call stack is explicit. You can trace, at the code level, exactly what function invoked what, with what arguments derived from what inputs. Information flow analysis tools do precisely this — they track taint from untrusted sources through the program’s data flows to identify where untrusted data reaches sensitive operations.
In an LLM-based agent, the execution model is non-deterministic and there is no call stack. The agent decides what to do next based on its current context window. The authorization question — “was this decision influenced by untrusted content, and if so, through how many hops?” — cannot be answered from the context window itself, because the context window is a flat sequence that has discarded exactly the relational structure needed to answer it.
Policy compliance rate for frontier LLM agents operating without explicit policy enforcement, measured across customer service tasks in multiple domains. This is the baseline cost of treating authorization as a model reasoning task rather than a structural enforcement problem. A majority of policy violations occur not from adversarial attack but from ordinary model reasoning failures in unguarded deployments.
The practical consequence of this structural gap is not merely theoretical. PCAS (arXiv:2602.16708) measured baseline policy compliance for frontier models operating without policy enforcement at 48% across customer service tasks in multiple domains. Fewer than half of actions taken by capable frontier models in typical enterprise workflows comply with the organization’s authorization policies — not because the models are adversarially manipulated, but because they have no structural mechanism for reasoning about the provenance of the information that drives their decisions. Authorization that depends on model reasoning is authorization that succeeds less than half the time.
The Happens-Before Relation
The solution to this problem is not new. Distributed systems research solved an analogous problem decades ago. When multiple processes in a distributed system communicate through message passing, a linear log of those messages is insufficient to reason about causal relationships between events. A message received by process B might have been caused by a message sent earlier by process A — or it might be independent. The linear log records that both messages occurred, in some order, but not whether one caused the other.
Leslie Lamport’s happens-before relation, introduced in 1978, provided the formal foundation for reasoning about causality in distributed systems. If event A happens-before event B, then A could have causally influenced B. If neither A happens-before B nor B happens-before A, the events are concurrent and cannot have influenced each other. This partial order captures the causal structure of distributed execution that a linear log discards.
PCAS applies the same principle to agentic systems. The observation is precise: multi-agent LLM systems exhibit distributed characteristics — multiple autonomous agents interacting asynchronously through message passing and shared tools. A linear concatenation of messages or tool invocations, whether per agent or globally across agents, is insufficient for system-level policy enforcement because it obscures cross-agent dependencies and loses the provenance necessary for authorization decisions. The solution is to model agent execution not as a sequence but as a partial order — a dependency graph that preserves the causal relationships that the sequence discards.
The Dependency Graph
A dependency graph for an agentic system is a directed acyclic graph where nodes represent events and edges represent causal information-flow relationships. Three node types capture the essential events: tool call nodes represent an agent’s decision to invoke an external function; tool result nodes represent the output returned by that function; and message nodes represent communications between agents or between the system and the user.
Edges encode information flow: a tool result node has an incoming edge from the tool call that generated it, and outgoing edges to any subsequent events that were causally influenced by that result. When agent A sends a message to agent B, and agent B subsequently makes a tool call, there is an edge from the message node to the tool call node, encoding that the message influenced the tool call. The graph preserves what the linear sequence discards: the complete causal history of every action in the system.
Authorization policies defined over this graph can reason about transitive information flow — asking not just “what is this action?” but “what was the original source of the information that caused this action, through any number of intermediate agents and tool invocations?” This is the structural foundation that real authorization requires and that linear message history cannot provide.
Three Node Types, One Structural Guarantee
The three-node-type model is worth examining in practical terms, because it is the mechanism by which the dependency graph achieves what the context window cannot. Consider a representative attack scenario that illustrates the problem precisely.
An agent is instructed to summarize a document about a company’s conflicts of interest. The document is retrieved through a tool call — a legitimate, authorized operation. The document contains legitimate content followed by an injected instruction: a fabricated “compliance audit” notice that impersonates a system update, claims executive authorization and CISO pre-approval, and instructs the agent to exfiltrate sensitive merger plans to an external address.
In the context window, the legitimate instruction and the injected instruction are both tokens. The model cannot architecturally distinguish between them. The injected instruction arrives at the model as authoritative-looking text in the same position where legitimate instructions appear. Without structural enforcement, the agent may comply.
In the dependency graph, the injected instruction has explicit provenance. The tool result node representing the document retrieval has an outgoing edge to any reasoning or action node that was causally influenced by its content. An information flow policy can be stated precisely: actions whose causal history includes a path through an untrusted tool result node are not authorized to reach external communication channels. The reference monitor evaluates this policy against the graph before executing the action and blocks the exfiltration — regardless of whether the model’s reasoning was successfully manipulated. The model’s state is irrelevant. The structural enforcement operates outside it.
The Three-Hop Injection Problem
In a multi-agent deployment, the provenance tracking requirement extends across agent boundaries. An untrusted document retrieved by a subagent influences that subagent’s message to the orchestrator. The orchestrator’s reasoning is influenced by that message and produces a decision that is passed to a second subagent. The second subagent makes a tool call based on that decision. The untrusted content from the original document is now three hops away from the action it ultimately influences. Linear message history — even if maintained globally across agents — cannot reconstruct this causal chain. The dependency graph encodes it explicitly: there is a path of edges from the tool result node representing the untrusted document to the tool call node representing the ultimately influenced action. A transitive information flow policy that checks for this path will block the action. A policy that only examines the immediate context of the tool call will not.
What Transitive Provenance Makes Possible
The practical significance of transitive provenance tracking becomes fully apparent when considering the class of policies it enables. A reference monitor operating on linear message history can enforce only local policies — rules about the current action, the current agent, the current context. It cannot enforce global policies — rules that reason about the causal history of an action across multiple agents and tool invocations.
Local policies capture a meaningful subset of security requirements. “This agent may not send emails to external addresses” is a local policy. It can be enforced by examining the action and the agent identity, without any provenance tracking. These are the policies that existing rule-based systems like AgentSpec (arXiv:2503.18666) enforce effectively, with over 90% success rates and millisecond-level overhead.
But the most critical security properties in multi-agent deployments are global. “No action in this system may be causally influenced by content retrieved from an untrusted external source” is a global policy — it requires knowing the complete causal history of the action being authorized, across any number of agent hops. “Data classified as sensitive may not flow to any channel, direct or indirect, that has a path to an unauthorized external endpoint” is a global policy. “An approval workflow requiring human sign-off may not be bypassed by any action whose causal history includes a tool result that was not present when the workflow was initiated” is a global policy.
These policies cannot be enforced locally. They require the dependency graph. The Datalog-derived policy language in PCAS is specifically designed for this: recursive queries that compute transitive closure over the dependency graph, enabling policies that reason about causal paths of arbitrary length. This is what “compliance by construction” means in practice — not merely that actions are checked before execution, but that the check is performed against the full causal history of the action, encoded in a data structure that preserves that history from the beginning of the session.
The authorization question in agentic systems is never just “what is this action?” It is always “what caused this action, through what chain of information flow, originating from what source?” A state representation that cannot answer the second question cannot support real authorization — regardless of how sophisticated the policy language built on top of it may be.
— Synthesis from PCAS (arXiv:2602.16708); Systems Security Foundations for Agentic Computing (arXiv:2512.01295)Linear History vs. Dependency Graph: The Structural Comparison
Linear Message History as State
All events — system prompts, user instructions, tool calls, tool results, inter-agent messages — are appended to a flat, ordered sequence. The sequence records what happened but not why. Causal relationships between events are implicit in the model’s attention weights, not explicit in the data structure.
Authorization decisions made against this state can only examine what is immediately present in the context. Transitive provenance — where an event’s causal influence traces back through multiple hops to an original source — is invisible. A policy that checks “did untrusted content influence this action?” cannot be evaluated because the data structure does not encode the causal path.
Policy compliance for frontier models in this architecture: 48% in empirical measurement across enterprise task domains.
Destroys Provenance · Local Policies OnlyCausal DAG as State
Events are represented as nodes in a directed acyclic graph. Edges encode causal information flow: tool result nodes connect to the actions they influence; message nodes connect across agent boundaries; the graph accumulates the complete causal history of every action in the system from session start.
Authorization decisions are evaluated against the full graph using a policy language with recursive query support. Transitive provenance is explicitly computable: the reference monitor can determine in a single policy evaluation whether any path exists in the graph from an untrusted source to the action being authorized, through any number of intermediate agents and tool calls.
Policy compliance in instrumented systems: 93% with zero policy violations in empirical measurement. Enforcement is deterministic independent of model behavior.
Preserves Provenance · Global Policies EnforceableThe Series 2 Connection
Series 2 established two empirical anchors that remain the strongest demonstrations of deterministic enforcement in the corpus. SEAgent (arXiv:2601.11893) showed that mandatory access control at the privilege enforcement layer produced a 0% attack success rate against privilege escalation — a complete structural defense, not a probabilistic reduction. Authenticated Workflows (arXiv:2602.10465) showed that cryptographic workflow authentication produced 100% recall with zero false positives across 174 test cases — complete enforcement without correctness tradeoffs.
Both results were real, both were significant, and both were presented at the right level of abstraction for the argument Series 2 was making: that architectural controls work when applied, and model-level controls do not provide the same guarantee. What Series 2 could not yet specify — because the PCAS research was not yet published — was the formal model of system state that makes these controls possible at the multi-agent level.
SEAgent’s mandatory access control operates at the process level, assigning security labels to agents and enforcing access policies at system call boundaries. It is architecturally sound but does not address cross-agent provenance — the causal influence that untrusted content retrieved by one agent can exert over actions taken by a different agent in the same deployment. Authenticated Workflows authenticates the integrity of workflow specifications — it detects when a workflow has been tampered with — but does not track how information flows through the workflow’s execution.
The dependency graph fills the gap between these two results. It provides the state representation that makes cross-agent, transitive-provenance authorization possible — the level of enforcement that neither per-agent access control nor per-workflow authentication alone provides. This is not a replacement for SEAgent-style mandatory access control or Authenticated Workflows-style cryptographic verification. It is the layer that sits between them and above them, enabling policies that reason about causal information flow at the system level rather than at the agent or workflow level individually.
The implication for practitioners is concrete. A deterministic enforcement stack for a production multi-agent deployment requires at minimum: per-agent mandatory access control at the resource layer (SEAgent-style), workflow authentication at the task specification layer (Authenticated Workflows-style), and causal provenance tracking at the system state layer (PCAS-style). Each layer closes a class of vulnerabilities that the others cannot see. No single layer is sufficient. The failure mode is treating any one of them as the complete answer.
The command-data boundary collapse is the correct diagnosis of why LLM-based agents are structurally vulnerable. But the mechanism that makes the boundary impossible to enforce is more specific: linear message history destroys the causal provenance that authorization decisions require. The fix is not a better policy language or a more sophisticated guardrail. It is a different state representation — one that encodes causal relationships as first-class data rather than discarding them in the flattening of events into a sequence. The dependency graph provides that representation. It transforms the command-data boundary collapse from a permanent architectural vulnerability into a tractable engineering problem. That is the ground Post 2 and Post 3 of this series build on.
