Enterprise network security has spent twenty-five years getting very good at one question: should this be allowed onto the network, and where can it go once it is? Cisco ISE, at the center of a mature identity architecture, answers that question continuously and at scale. It authenticates the endpoint, authorizes the session, and — through the enforcement points it drives — decides exactly what that session can reach. Done well, it is formidable.
But there is a horizon ISE cannot see past, and it is the same horizon every network-centric architecture shares. Once a workload is admitted and running on a host, the network can no longer observe what that workload actually does — instruction by instruction, system call by system call. The identity was verified at the door. What happens inside the room, at the execution boundary between a process and the operating system, is invisible to the network. For AI workloads handling sensitive decisions, that invisible space is exactly where the risk concentrates.
Closing it does not mean replacing the network layer. It means adding a second enforcement surface where the network’s vision ends — in the kernel — and unifying the two so that a single authorization decision governs both. This is the controlled-execution property of AI Sovereignty Architecture made concrete: identity-driven network enforcement and kernel-level enforcement, fed by one attestation decision, operating as a single real-time fabric.
What ISE already does well
It is worth being precise about ISE’s strengths, because they are the foundation the second layer builds on, not something to be worked around.
ISE is a policy decision point. It does not itself sit in the data path; instead, it tells the devices that do — switches, wireless controllers, firewalls — what to enforce. When an endpoint authenticates, ISE evaluates identity, posture, and context, then hands the enforcement point an authorization: a downloadable ACL, a VLAN assignment, a Security Group Tag. The endpoint gets exactly the reach its identity and posture earn, and nothing more.
Three ISE capabilities matter most for what follows. pxGrid is a publish-and-subscribe framework that lets an external system exchange context with ISE and, critically, drive its decisions — the sanctioned way for a non-Cisco system to influence enforcement without touching any device directly. Adaptive Network Control (ANC) lets that external system apply a policy state — quarantine, restrict, or grant — to an endpoint in real time. And RADIUS Change of Authorization (CoA) is the mechanism by which ISE re-authorizes a live session: it can push a new ACL, move a VLAN, or reassign a tag on an already-connected endpoint without tearing the session down. Together these mean an external decision can become a network-wide enforcement action in seconds, propagated by machinery Cisco networks have run in production for years.
That last point is the strategic one. ISE already knows how to fan a single authorization decision out to every switch, router, and firewall in the estate. Any system that can drive ISE inherits that entire distribution fabric through one integration rather than dozens.
What ISE cannot see
Now the limit. ISE governs reach — what a session can connect to. It does not govern execution — what a process does on the host once it is running. These are different questions, and the difference is not academic.
Consider an AI inference workload that authenticated cleanly, received an appropriate authorization, and is running exactly where policy allows. From the network’s vantage, everything is correct. But suppose that workload has been tampered with, or has drifted from its intended behavior, and begins attempting operations it should never perform — spawning an unexpected process, opening a file outside its scope, initiating a connection it was never meant to make. Each of those actions is a system call, made inside the host, at the boundary between the process and the kernel. The network did not admit a rogue action; it admitted a session that later produced one. By the time the effect of that syscall reaches the network as traffic, the action has already happened.
This is the gap. Not a flaw in ISE, but a boundary it was never designed to cross. Enforcing at the execution boundary requires being in the execution environment — in the kernel of the host where the workload runs.
What eBPF adds at the execution boundary
eBPF is the mechanism that makes kernel-level enforcement practical without sacrificing performance. It runs small, verified, sandboxed programs inside the Linux kernel, attached to specific hooks, where they can observe and act on kernel events at native speed. It is not a research curiosity — it is the technology behind Cilium, Falco, and Tetragon, in production on millions of nodes across the industry.
For enforcement, the relevant capability is the BPF Linux Security Module. BPF-LSM lets an eBPF program attach to the kernel’s security hooks — the same hooks the kernel already consults before permitting security-relevant operations — and return an allow-or-deny verdict. A program attached to the process-execution hook can permit or block an exec. A program on the file-open hook can gate access to a path. A program on the socket-connect hook can allow or refuse an outbound connection. The decision is made in-kernel, synchronously, before the operation proceeds. A denied syscall does not happen — it is not logged after the fact and cleaned up later; it is refused in the moment, at microsecond scale, with no round trip to anything.
The enforcement program does not decide policy on its own. It consults an in-kernel map that a userspace agent keeps current, reflecting the workload’s present attestation state: is this workload’s identity valid, is it still current, does its runtime behavior still match what it attested to? A companion set of eBPF programs traces selected syscalls to detect exactly that behavioral drift — a workload that authenticated as one thing but has begun acting like another. When attestation is valid, the operations proceed at full speed. When it is revoked or the workload drifts, the gate closes. (The deeper case for why the execution boundary is the decisive place to enforce, and how drift detection works, is a subject in its own right.)
Unifying the two into one fabric
Here is the synthesis, and it is the part that no single-discipline practitioner assembles, because it requires knowing both worlds at once.
There is one decision origin: the attestation control plane, which holds the authoritative answer to “is this workload trusted, and for what.” From that single origin, two enforcement surfaces are fed.
The network surface is driven through ISE. When the control plane determines a workload’s state has changed — say, an inference workload is found to have drifted and must be contained — it calls ISE’s ANC capability over pxGrid to apply a quarantine state to that workload’s endpoint. ISE issues a CoA, and the enforcement points reassign the endpoint in seconds: a quarantine ACL, a restrictive tag, a segmented VLAN. The workload’s reach collapses across the entire network, enforced by the fabric ISE already commands.
The kernel surface is driven locally. The same control-plane decision updates the eBPF maps on the node where the workload runs, and the BPF-LSM gate begins denying the workload’s privileged syscalls immediately. The workload’s execution is constrained at the boundary, in-kernel, without waiting for anything network-side.
One decision, two surfaces, two timescales. The kernel gate reacts in microseconds, locally and synchronously. The network quarantine propagates in seconds, fleet-wide, through ISE. A workload that turns hostile is contained at the execution boundary on its own host and severed from the network everywhere else — from a single authoritative decision, not two separate manual actions that might disagree.
This is what “real-time” means here, precisely: enforcement co-located with the event it governs. The kernel does not phone home to ask permission before every syscall — that would be neither real-time nor survivable. It enforces against locally cached attestation state and reports asynchronously, while the network layer handles the fleet-wide propagation. Enforcement is local and synchronous; distribution is central and fast; observation never sits in the enforcement path.
The rogue-workload loop, end to end
Put concretely, the fabric runs a single loop:
An AI workload on an owned node begins behaving outside its attested profile. The kernel’s syscall-tracing programs detect the drift and the BPF-LSM gate begins refusing the privileged operations the workload now attempts — the harm is stopped at the execution boundary, on that host, in-kernel, immediately. The node agent reports the event to the control plane. The control plane revokes the workload’s short-lived credential and calls ISE’s ANC to quarantine the endpoint; ISE issues a CoA and the workload is severed from the network estate within seconds. Every step — the drift detection, the kernel denials, the revocation, the network quarantine — is written to the signed attestation ledger as tamper-evident evidence. Containment at both layers, triggered by one attestation decision, and provable after the fact.
That loop is the controlled-execution property doing its job: an unattested or drifted workload cannot execute privileged actions and cannot maintain its network reach, no matter how it arrived on the machine.
Why this is defense in depth that actually matters
Two enforcement surfaces that fail independently are worth far more than one that carries the whole load. Concentrate everything at the network and a single class of bypass — a workload admitted under false pretenses — defeats the system. Add the kernel surface and the arithmetic changes: a threat now has to defeat the network layer to reach the host and the kernel layer to execute on it, and the two do not share a failure mode. The network stops illegitimate reach; the kernel stops illegitimate execution. Neither yields to a workload that cannot present a valid attestation rooted in an air-gapped anchor — which a rogue workload, by definition, cannot produce.
None of the pieces is unproven. ISE-driven network enforcement is decades of production practice. eBPF enforcement runs at industry scale. The contribution is the binding: rooting both surfaces in a single sovereign attestation decision so that the network layer and the kernel layer enforce the same policy against the same verified identity, in real time. Proven parts, composed into something the parts cannot be alone.
Where ISE isn’t the answer
One honest boundary. This article describes the most elegant path — the one available when a mature ISE deployment is present to command the network fabric. Not every environment has it. The architecture does not depend on ISE; the control plane emits its decisions to a set of enforcement adapters, of which the ISE path is the first and cleanest. Where there is no ISE, the same decision drives RADIUS Change of Authorization directly, or programmable network interfaces, or cloud-native controls — while the kernel surface remains constant on every owned node, because it never depended on the network at all. In environments without ISE, the kernel layer simply becomes the primary enforcement surface rather than the second. That multi-environment enforcement model is a subject we treat on its own.
For the enterprise that already runs ISE, though, the message is direct: you have already built the harder half of this. The network enforcement fabric is in place. Adding kernel-level attestation enforcement at the execution boundary, and binding both to one sovereign decision, is what turns a strong network posture into genuine controlled execution over your AI workloads — the difference between governing what your AI can reach and governing what it can do.
Ready to apply this?
Talk to Acclivity about your security posture.
Four security practices delivered today. One category being defined. We run the AI Sovereignty Architecture reference implementation on our own infrastructure, hardening it for enterprise scale with partners.