Control Plane vs Data Plane in AI Systems

Where the distinction comes from, and what carries over

In networking, the control plane decides how traffic should be handled and the data plane carries the traffic itself. NIST's 5G security design principles describe infrastructure that isolates data plane, control plane, and operation and maintenance traffic from each other. The point of the separation is that the layer where rules are set stays apart from the layer where work happens, so a fault or compromise in one does not automatically become authority in the other.

That principle carries over to AI systems. The mechanism does not. NIST observes that large language models accept data and instruction as a single stream of tokens through a single interface, so there is no native separation between the data a model acts on and the instructions it is given. Because of this, NIST states that the separation must be enforced by architecture design, around the model and agent rather than inside them.

The terminology is also inconsistent. NIST uses "control plane" for the prompt or instruction channel. OWASP uses it for the agent orchestration layer, which it describes as highly privileged. This guide uses the networking sense: the control plane is where policy is defined, configured and approved, and the data plane is where interactions execute. Stating which meaning you use in architecture reviews and vendor conversations removes much of the ambiguity.

Why enforcement belongs in the execution path

When policy sits in documents, configuration or review processes, it is outside the path of any individual interaction. The result is a gap between what a system was allowed to do and what it did. Review after the fact can detect that gap, but it cannot prevent the action that opened it.

NIST's guidance on agent identity points to the alternative. The logic that determines what an agent attempts should be architecturally separate from the systems that determine what it is allowed to do, so that prompt injection or malicious untrusted data cannot manipulate credentials or expand the agent's actual permissions. Enforcement is established around the agent and between it and the systems, data, credentials and environments it touches. NIST also notes that deterministic decisioning limits the impact of attacks such as prompt injection and gives more predictable behavior when agents reach sensitive services and tools.

In practice, the enforcement point evaluates each interaction or tool call and returns one of a small set of outcomes: allow, redact, block, rate limit, or escalate for human approval. Two further design points follow from the NIST guidance. Avoid standing or broad agent privileges, which make hijacking or unintended actions more likely. And provide a way to contain or revoke an agent's authority when anomalous behavior or context drift appears. OWASP adds that destructive, financial, administrative or externally visible actions need controls beyond a simple approval prompt.

There is a tradeoff. An enforcement point in the path becomes a runtime dependency, so latency, availability and failure behavior (fail open or fail closed) need explicit design decisions.

Evidence is a product of enforcement

Each layer produces a different kind of evidence, and an auditor typically needs both. The control plane can show intent: policy versions, access configuration and approval records. The data plane, through its enforcement point, can show behavior: what was requested, which policy applied, and what action was taken. Traffic records alone show activity but not whether policy was applied. Evidence that is a by-product of the enforcement decision is tied to that decision, which is a stronger basis than records reconstructed later.

This matters for the frameworks most architects are asked about. The EU AI Act requires high-risk AI systems to be designed so people can effectively oversee them while in use, and to reach appropriate accuracy, robustness and cybersecurity and perform consistently throughout their lifecycle. Providers must put a quality management system in place. NIST AI RMF 1.0 states that risk management should be continuous, timely and performed throughout the lifecycle. Runtime enforcement and human escalation are one way to support these expectations, and continuous lifecycle management argues for checking behavior at runtime rather than only at design or review time.

Whether a system is high-risk under the AI Act depends on its intended purpose, so not every deployment is in scope. As of October 2026, a proposal to delay certain high-risk rules is also under way. Map each deployment to the obligations that actually apply to it.

How Trussed fits

Trussed operates on the data-plane side of this model, in the execution path. It enforces policy at runtime, not after the fact, across models, agents, tools, MCP servers, AI sites and coding assistants: allow, redact, block, rate limit, and escalate for human approval. Its scope is individual interactions and tool calls.

That enforcement generates continuous audit-ready evidence, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Trussed is self-managed in the customer cloud, with configurable retention and data residency, and has run continuously in production at a regulated enterprise for more than 18 months.