The Substrate Argument, Stated in eBPF

A May 2026 paper names the failure mode directly: identity and delegation pushed into application code become difficult to enforce and difficult to audit. The proposed fix moves enforcement below the code, not around it.

On May 26, 2026, an eight-author group posted an arXiv preprint describing Grimlock, a system for guarding what the paper calls "high-agency systems" using eBPF traffic interception and TLS-bound attestation. The paper opens with a diagnosis stated without hedging: "identity, authorization, provenance, and delegation are often pushed into application code, where they become difficult to enforce consistently and difficult to audit." That sentence is a direct academic statement of an argument that has circulated informally across the agentic-security discussion for months, that governance properties bolted onto application code inherit all the inconsistency of application code, and none of the reliability of the substrate underneath it.

Grimlock's response is architectural rather than procedural. The paper describes it as an "Agent Guard" that "restores separation of concerns by moving trust enforcement into the sandbox substrate while leaving agent code unchanged." The phrase "leaving agent code unchanged" is doing real work. It means the enforcement layer does not ask agent developers to adopt a new SDK, annotate their code with policy hints, or trust that every downstream engineer implements the same authorization check consistently. It sits underneath the code entirely, in the kernel-level traffic path.

What moves into the substrate, specifically

The mechanism has two paired components. The first is eBPF-enforced traffic interception, which the paper describes as ensuring "that sandbox communication passes through a guard." eBPF programs run inside the Linux kernel with visibility into network traffic that no amount of application-layer instrumentation can be bypassed by a misconfigured or malicious agent process, because the interception happens beneath the layer where the agent's own code executes. The second component is post-handshake attestation, bound to standard TLS 1.3 channel bindings. After a connection is established, the guard authorizes the communication and mints what the paper calls "short-lived, channel-bound scope tokens" that encode least-privilege delegation for that specific channel.

The receiving side performs a parallel check. The destination guard, per the paper, "re-validates identity, scope, and channel binding, terminates TLS, and releases plaintext to the destination sandbox only after policy checks succeed." Both ends of the connection independently verify the same properties before any application data is exposed. Neither side is trusted to have correctly performed the other's check. The paper notes that kTLS, a kernel-level TLS offload mechanism, provides the dataplane for this protected communication, keeping the performance cost of the additional verification close to that of unencrypted kernel networking.

Why binding to TLS channel bindings matters

Channel binding is a specific cryptographic technique that ties an authentication or authorization decision to the exact TLS session over which it was made, preventing an attacker who has captured or replayed a credential from presenting it over a different connection. By binding the scope tokens to TLS 1.3 channel bindings rather than to a bearer credential alone, Grimlock's design closes a class of relay and replay attacks that affect systems relying purely on bearer tokens passed inside application payloads. A stolen scope token is not useful outside the specific channel it was minted for.

This is a meaningfully different security property than what most current agent-to-agent communication schemes provide. Bearer tokens, API keys, and even short-lived OAuth tokens are, in most current agentic deployments, portable: whoever holds the token can present it, regardless of which network path they present it over. Binding authorization to the channel itself removes that portability, at the cost of requiring the underlying infrastructure to support eBPF and TLS 1.3 channel binding consistently across every hop in a multi-cloud agent-to-agent path.

The claim about auditability, and what still depends on deployment discipline

The paper frames the outcome as "a path toward transparent, auditable, and scope-bound agent-to-agent communication across heterogeneous multi-cloud environments, using commodity Linux primitives and without requiring changes to user-layer orchestration code." The phrase "path toward" is notably more measured than a claim of solved auditability. Grimlock's architecture makes enforcement consistent within any environment where the guard is correctly deployed on every relevant node. It does not, on its own, guarantee that every node in a heterogeneous multi-cloud topology actually has the guard installed, correctly configured, and kept current as the topology changes.

That distinction, between "the substrate can enforce consistently" and "the substrate is consistently deployed," is where the paper's architectural contribution and an enterprise's operational reality can diverge. A guard that is bypassed because a new node was provisioned without it produces the same failure mode the paper describes for application-code enforcement: a gap invisible until something goes wrong. Moving enforcement into the substrate reduces the number of places inconsistency can originate. It does not eliminate the need to verify that the substrate itself is present everywhere it needs to be.

Where this sits in the identity arc

The paper's diagnosis, that identity and delegation pushed into application code are difficult to enforce consistently and difficult to audit, is the same structural gap that has surfaced repeatedly across advisories and frameworks addressing agentic risk: privilege assigned without consistent scoping, entitlements checked once and trusted thereafter, accountability chains that no single party holds in full. Grimlock does not propose a new policy language or a new governance framework. It proposes moving the enforcement point to a layer where the code running above it cannot silently opt out. Whether that architectural move actually closes the accountability gap, or simply relocates the question of who verifies the guard is present, is not something the paper's benchmark, run inside a controlled multi-cloud test environment, can settle on its own.

Open Questions

• What mechanism verifies, at scale, that every node in a heterogeneous multi-cloud deployment actually has the Grimlock guard correctly installed and current, rather than assuming it based on provisioning policy?
• When a scope token is denied because of a channel-binding mismatch, what artifact does an operator receive to distinguish a legitimate security event from a misconfiguration, and who is positioned to review it?
• Does binding authorization to TLS 1.3 channel bindings introduce a new single point of failure at the TLS termination layer, and if the guard itself is compromised at that layer, what governs the compromise?
• How does the architecture handle an agent-to-agent path that must traverse infrastructure not under either party's operational control, where neither party can guarantee the guard is present?
• What auditing standard would an external reviewer apply to confirm that "auditable" in the paper's framing produces evidence sufficient for a regulatory or contractual dispute, rather than evidence sufficient only for internal engineering review?

The governance artifact is retained. The governance function is not.