Compile-Time, Runtime, or Protocol: Where Enforcement Lives Determines What It Can Guarantee

This is Post 3 of The Policy Layer, our fifth series on agentic AI security. Post 1 established that linear message history destroys the causal provenance that authorization requires, and that the dependency graph provides the correct alternative state representation. Post 2 mapped the four approaches to policy authorship — Datalog specification, DSL rules, STPA-derived constraints, and behavioral learning — and gave practitioners a framework for choosing among them. This post introduces the second axis of the enforcement taxonomy: not what kind of guarantee, but where in the system lifecycle that guarantee is produced. The answer to that question determines which threat classes any given enforcement mechanism can actually see.

There is a conceptual shortcut that Post 2 of this series deliberately left unresolved. All four policy authorship approaches produce specifications that must be enforced somewhere — by some mechanism, at some point in the system’s execution. The approaches differ in how policies are written. But they share a deeper question that writing alone cannot answer: when does enforcement occur, and against what version of system state? A policy that is evaluated before the system is deployed has access to the complete intended specification. A policy that is evaluated at the moment of action execution has access to the current runtime trace. A policy that is evaluated at the protocol transport boundary has access to the message as it crosses between components. These are not the same state. They do not offer the same guarantees. And they do not close the same gaps.

This distinction — the enforcement lifecycle axis — is the second dimension that the deterministic/probabilistic taxonomy from Series 2 does not capture. Series 2 was right that deterministic controls are structurally superior to probabilistic ones. But two systems can both be deterministic and still differ fundamentally in what they can enforce, because they differ in when they enforce it. This post maps that distinction with precision and builds to the argued position: the minimum viable enforcement stack for production multi-agent deployments requires all three lifecycle positions, and each one closes a gap the other two cannot reach.

The Three Enforcement Lifecycle Positions

The Flask Analogy: Where This Architecture Comes From

The compile-time enforcement concept is not novel to agentic AI research. PCAS draws explicitly on a lineage from operating systems security that is worth understanding, because it clarifies why the architecture works and what its limits are.

The Flask security architecture, introduced in the 1990s and implemented in Security-Enhanced Linux (SELinux), established a principle that has proven durable: separate the security policy from the enforcement mechanism. SELinux compiles human-readable policy source files into binary policy modules that are loaded into the kernel. The kernel enforces mandatory access control at every system call boundary — not by reasoning about whether a given call is safe, but by consulting the compiled policy and blocking calls that the policy does not permit. The enforcement is deterministic, independent of the program making the system call, and structurally guaranteed by the kernel’s position in the execution path.

PCAS applies the same architecture to agentic systems. The policy specification takes the place of the SELinux policy source. The dependency graph takes the place of the kernel’s access vector cache. The reference monitor takes the place of the mandatory access control enforcement point at the system call boundary. And the compile step — transforming the agent implementation and policy specification into an instrumented system — takes the place of loading a compiled policy module into the kernel.

The analogy is not merely aesthetic. It explains why compile-time enforcement produces the strongest guarantees: the enforcement point is inserted into the system’s structure before it runs, in a position that the system itself cannot bypass. An application cannot circumvent SELinux by reasoning cleverly about system calls. An LLM-based agent cannot circumvent a PCAS-instrumented reference monitor by reasoning cleverly about what action to propose next. The enforcement is outside the reasoning loop entirely.

Runtime Enforcement: The Necessary Complement

Compile-time enforcement produces the strongest formal guarantees but requires that policies be fully specified before deployment. In practice, there is a meaningful class of security constraints that cannot be fully specified in advance — constraints that depend on the behavioral context of a specific session, the identity of a specific user making a specific request, or the dynamic composition of tools that an agent discovers at runtime rather than at design time.

Runtime enforcement addresses this class. AgentSpec (arXiv:2503.18666) operates reactively: it intercepts each proposed tool invocation against a set of trigger-predicate-enforcement rules and blocks those that violate the current rule set. The rules are evaluated against the current action in isolation — without transitive provenance tracking across agent boundaries, but with computational overhead measured in milliseconds and effectiveness rates above 90% for the policy classes it covers.

Pro2Guard (arXiv:2508.00500) extends the runtime position proactively: rather than intercepting only at the moment of action proposal, it learns a probabilistic model of execution trajectories from historical traces and predicts, at each step, the probability that the current trajectory leads to an unsafe state. It intervenes when that probability exceeds a threshold — before the unsafe action is proposed, not after. This reduces token overhead by 12.05% through early trajectory rejection, and represents a hybrid of the runtime enforcement position and the probabilistic prediction approach that sits in between reactive runtime and the more formal compile-time guarantee.

The practical division of labor between compile-time and runtime enforcement is therefore: compile-time for policies that can be fully specified before deployment and that require formal guarantees — particularly transitive information flow policies over the dependency graph. Runtime for policies that depend on dynamic session context, that benefit from behavioral adaptation, or that cover the broader space of operational constraints that do not require transitive provenance reasoning. Neither position makes the other redundant.

Protocol-Layer Enforcement: The Gap That the Other Two Cannot Close

The third enforcement lifecycle position is the one with the most direct bearing on the core Luminity thesis, and the one that is furthest from operational readiness in the current research landscape.

Both compile-time and runtime enforcement operate at the agent-framework application layer. They can govern what actions an agent takes. They cannot govern what messages that agent receives — specifically, they cannot structurally distinguish between a message that carries a trusted instruction and a message that carries untrusted content embedded in a tool result — at the point where that distinction needs to be enforced, which is the transport boundary between the agent and the external system it is communicating with.

This is the protocol-level structural gap that the Luminity corpus has documented across two series. The four missing structural controls in MCP — cryptographic tool schema binding, per-session capability scoping, structural instruction-data separation, and inter-agent trust delegation standards — are not missing because no one has thought to implement them at the application layer. They are missing because MCP’s protocol design does not carry the data structures that would make them implementable at the transport layer. An application-layer reference monitor cannot verify the integrity of a tool schema it receives over a protocol that carries no cryptographic binding for that schema. A runtime enforcement mechanism cannot enforce per-session capability scoping on agent authority that is defined at the protocol level and not surfaced to the application layer.

The STPA+IFC paper (arXiv:2601.08012) proposes the research community’s current best answer to this gap: a capability-enhanced MCP framework that requires structured labels on capabilities, confidentiality levels, and trust tiers to be carried in the protocol transport itself. This is not an application-layer patch. It is a protocol extension — a change to what MCP messages carry and what MCP-compliant components are required to assert and verify at each hop.

The Two-Axis Enforcement Taxonomy

With the lifecycle axis established, the full taxonomy is a 2×3 matrix: deterministic/probabilistic crossed with compile-time/runtime/protocol-layer. Most real deployments will have multiple cells populated simultaneously. The matrix clarifies which cells must be populated to close which threat classes.

Reading the matrix against the threat landscape, the implication is precise: compile-time deterministic enforcement closes the transitive provenance gap. Runtime deterministic enforcement covers the operational constraint surface. Protocol-layer enforcement — currently at research stage, not production readiness — is the only position that closes the structural MCP gap. An organization that deploys only compile-time and runtime enforcement has a strong application-layer posture and a protocol-layer exposure that neither of those positions can see.

The MCP Structural Gap: Which Layer Closes What

Mapping the four missing structural MCP controls against the enforcement lifecycle matrix makes the protocol-layer requirement concrete rather than abstract.

Cryptographic tool schema binding — detecting unauthorized additions or modifications to tool descriptions between sessions — requires enforcement at the protocol layer. A reference monitor that sees tool results at the application layer cannot verify whether the schema that governs those results was tampered with before the session began. This gap requires that MCP carry cryptographic commitments to tool schemas that agents can verify at session initiation.

Per-session capability scoping — narrowing agent authority to the current task’s specific resource requirements — is currently a governance and IAM problem. Making it a structural enforcement problem requires that the protocol carry explicit capability declarations that the transport layer can scope at session establishment. Application-layer enforcement can check whether an agent’s actions fall within its declared capabilities; it cannot enforce that the capability declaration was correctly scoped in the first place without protocol-level attestation.

Structural instruction-data separation — the protocol-enforced trust boundary between instructions and retrieved content — is precisely the command-data boundary collapse described in Post 1. Protocol-layer enforcement is the only position that can insert this boundary at the transport layer, before instructions and data are concatenated into the context window that the application layer sees. Compile-time and runtime enforcement both operate after this concatenation has already occurred.

Inter-agent trust delegation standards — governed propagation of access scope across orchestrator-to-subagent chains — requires that each hop in the agent chain carry verifiable attestation of the authority scope being delegated. PCAS’s dependency graph tracks the causal history of information flow; it does not verify that the authority the orchestrator claimed to delegate was legitimately granted in the first place. Protocol-layer enforcement is the only position that can enforce this at the communication boundary rather than inferring it from execution traces.

The Minimum Viable Enforcement Stack

The practical argument for practitioners follows from the matrix. An organization deploying agentic systems in authorization-critical contexts needs, at minimum, the following stack: compile-time instrumentation for policies that require transitive provenance reasoning and formal guarantees, runtime enforcement for operational constraints that benefit from reactive or proactive interception during execution, and a protocol-layer enforcement roadmap that acknowledges the current gap and tracks the MCP protocol extension work required to close it.

That last component — the roadmap — is not optional. An organization that deploys a strong application-layer enforcement stack and treats the protocol-layer gap as someone else’s problem is making a security architecture decision it may not have made explicitly. The protocol gap does not disappear because the application layer is well-defended. It remains open at the layer below, accessible to adversaries who understand where the enforcement boundary actually sits.

What does a protocol-layer enforcement roadmap look like today, given that production-ready protocol-layer enforcement does not yet exist? It means tracking the STPA+IFC research trajectory. It means participating in or monitoring MCP protocol governance discussions around capability labeling and trust tier encoding. It means designing application-layer deployments with the assumption that protocol-layer enforcement will eventually be added below them — and ensuring that the application-layer architecture is compatible with that addition rather than entangled with the absence of it.

The Series 2 Extension: A Complete Taxonomy

The original Series 2 taxonomy labeled two categories: probabilistic defenses as “Necessary · Not Sufficient” and deterministic defenses as “Structural · Enforceable.” Both labels remain accurate. The enforcement lifecycle axis adds a third dimension to each label. Deterministic compile-time enforcement is “Structural · Enforceable · Pre-Deployment.” Deterministic runtime enforcement is “Structural · Enforceable · Session-Scoped.” Deterministic protocol-layer enforcement — when it exists — will be “Structural · Enforceable · Transport-Boundary.”

The two strongest empirical anchors from Series 2 map cleanly onto this extended taxonomy. SEAgent’s mandatory access control operates at the compile-adjacent position — assigning security labels to agents and enforcing access policies at a boundary that cannot be bypassed by model reasoning. Authenticated Workflows operates at the runtime-adjacent position — verifying the integrity of workflow specifications against cryptographic commitments at the moment of execution. Both are deterministic. Both demonstrate zero-violation or perfect-recall performance within their scope. Neither addresses the protocol-layer gap, because neither was designed to.

The Policy Layer series has provided the formal model (dependency graph), the authorship approaches (Post 2), and the lifecycle taxonomy (this post) that give the Series 2 prescriptions their mechanistic grounding. Post 4 closes the series by mapping precisely where this entire enforcement stack — correctly specified, correctly authored, correctly positioned across all three lifecycle points — still falls short. Because it does fall short, in ways that are important and that trace back to exactly the protocol-level vulnerabilities this corpus has been documenting since Series 1.