A security control plane is a layer where security control is enforced, observed, and measured. Expel’s AI security risk framework defines six: data, identity, execution, human, external AI and service control, and observability.
Key takeaways
- A security control plane is a layer where security control is enforced, observed, and measured.
- It isn’t the same as a Kubernetes or network control plane—the terms share a metaphor, not a definition.
- Expel’s AI security risk framework defines six control planes: data, identity, execution, human, external AI and service control, and observability.
- AI risk crosses several control planes at once, so ownership has to be assigned per plane.
- Observability is the precondition for the other five, because you can’t verify a control you can’t see.
If you’ve worked with Kubernetes or software-defined networking, “control plane” already means something specific to you. In security, the term is borrowed for a different job: describing the layers where an organization holds or loses control over who can act, on what, and whether that action can be verified. The distinction matters more as AI spreads, because AI risk rarely sits in one place. A single agent can touch data, identities, and external services in one workflow. Expel’s guide to thinking about AI security risk organizes that problem into six control planes. This page explains what a security control plane is, how it differs from the infrastructure meaning, and why observability comes first.
How is a security control plane different from a Kubernetes or network control plane?
A Kubernetes or software-defined networking (SDN) control plane is a specific software layer. In Kubernetes, it’s the set of components (the API server, scheduler, and controllers) that manage the desired state of a cluster. In networking, it’s the logic that decides where traffic should go, separate from the data plane that actually forwards packets.
A security control plane is a governance concept, not a piece of software. It describes where security policy is enforced and measured across an organization, whatever tools happen to live there.
Both uses are legitimate. They share a metaphor—a layer that decides, separate from the layer that does—but not a definition. A Kubernetes control plane can sit inside a security control plane (execution, for example), but the two aren’t interchangeable.
| Term | What it is | Example |
|---|---|---|
|
Security control plane |
A layer where security control is enforced, observed, and measured | Identity: Who can authenticate, what they’re allowed to do |
|
Kubernetes control plane |
Cluster components that manage desired state | API server, scheduler, and controller manager |
|
Network (SDN) control plane |
Logic that decides how traffic is routed | Routing protocols and SDN controllers |
It’s also worth separating control planes from your attack surface. Your attack surface is everywhere a cybercriminal could get in. A control plane is where you can stop them (or at least see them).
What are the six control planes in Expel’s AI security risk framework?
Expel’s framework defines six control planes. Each one answers a different question about AI risk.
| Control plane | What it governs | Question it answers |
|---|---|---|
|
Data |
Data AI systems can read, retrieve, or produce | What is exposed, inferred, retained, classified, and/or combined? |
|
Identity |
Authentication and authorization for people, services, and AI agents | Who or what is allowed to act? |
|
Execution |
Actions humans, AI systems, and agents take, including tool and API calls | What can AI actually do in the environment? |
|
Human |
Interpretation, awareness, and judgment of the people working with AI (what happens outside of the computer) | How are trust, decisions, intent, and workflows influenced? |
|
External AI and service control |
Third-party AI models, services, and integrations you don’t run | What do we depend on that we don’t control? |
|
Observability |
The ability to reconstruct and explain AI-driven activity | Can we see, verify, and reconstruct what happened? |
One caution: Every organization is different, and these planes may map to different teams. The framework describes where control lives, not who must own it.
Why does AI require thinking in control planes?
Traditional security programs often map risk to tools. The email gateway handles phishing. EDR handles malware. AI breaks that model, because one AI-driven event can span several layers at once.
Take an instruction manipulation attack, where a cybercriminal hides instructions in a document an AI agent later reads—a form of indirect prompt injection. The agent acts on those instructions (execution), pulls sensitive files (data), and may do it under a service account with broad permissions (identity). If prompts and context weren’t logged, nobody can reconstruct why (observability).
No single team owns all four. Mapping risk to planes tells a security leader which functions belong in the room and what each one is accountable for instrumenting.
Which control plane matters most?
Observability, because it’s the precondition for the other five. Without the ability to reconstruct AI-driven activity, a security team can’t validate or enforce any control on the data, identity, execution, human, or external AI service planes. A data policy you can’t audit is a hope, not a control.
That’s why Expel treats observability as a control function, not a reporting layer.
How do you start mapping AI risk to control planes?
- Pick one AI workflow to start. Choose an agent or AI-powered tool that touches sensitive data, and trace everything it can read, call, and change.
- Map each step to a plane. For every action in the workflow, note which control plane governs it and which control (if any) applies.
- Name an owner per plane, not per tool. The team that owns identity should own identity risk for AI agents too.
- Look for planes with no control. Gaps often show up in external AI services and the human plane, where traditional tooling has the least reach.
- Confirm you can reconstruct the workflow. If you can’t, fix observability before tuning controls on the other planes.
Expel’s take
We started describing AI risk in control planes because conversations about AI security kept stalling on the same question: Who owns this? AI security gets handed to whoever bought the AI tool, or to the CISO by default. Neither works when the risk spans data, identity, and execution at once.
Control planes give us and our customers a shared map. When our SOC investigates AI-related activity, analysts work through the same layers: what data was involved, which identity acted, what the agent executed, and whether we can reconstruct it. That work happens in Expel Workbench™, where every analyst action is recorded so the investigation itself is reviewable.
We’re careful not to prescribe ownership. Every organization is structured differently, and the right owner for the human plane in one company might sit in a different function in another. The planes describe where control lives. Who holds it is your call.
Frequently asked questions
What is a security control plane?
A security control plane is a layer where security control is enforced, observed, and measured. Expel’s AI security risk framework defines six: data, identity, execution, human, external AI and service control, and observability. Each answers a different question about who can act, on what, and whether that action can be verified.
How is a security control plane different from a Kubernetes or network control plane?
A security control plane describes where security policy is enforced and measured across an organization. A Kubernetes or SDN control plane is a specific software layer that manages infrastructure state and routing decisions. The terms share a metaphor, not a definition, and the two aren’t interchangeable.
Why does AI require thinking in control planes?
AI risk surfaces across multiple control planes at once, so no single team can own it. An instruction manipulation attack touches execution, data, and observability at the same time. Mapping risk to planes tells a security leader which functions belong in the room and what each is accountable for instrumenting.
Which control plane matters most?
Observability, because it’s the precondition for the other five. Without the ability to reconstruct AI-driven activity, a security team can’t validate or enforce any control on the data, identity, execution, human, or external AI service planes. Expel treats observability as a control function, not a reporting layer.
How is the human control plane different from identity?
Identity covers authentication and authorization, meaning what a system will let an actor do. The human plane sits outside the machine and covers interpretation, awareness, and judgment. A deepfake-driven approval fraud is a human plane failure even when every identity control worked exactly as designed.