AI SYSTEMS

What Is an AI Control Plane?

11 September 2026
AI Control Plane visual showing users, AI agents, applications, data sources, APIs and external models governed through central policy, access, observability, cost and compliance controls.

Most enterprise software environments already have systems for identity, permissions, security, monitoring, policy and audit. That infrastructure was built for applications, services and people. AI adds a layer that doesn't map cleanly onto any of it: models, assistants, agents, AI-enabled applications, external model providers, and tool-using autonomous systems — often spanning multiple applications, data stores and infrastructure environments at once.

As AI becomes distributed across the enterprise, organisations need a way to understand and control the AI layer itself.

That is where the idea of an AI control plane begins.

A note on framing before going further: an AI control plane is not, at this point, a universally standardised industry category with a fixed definition. It's an emerging architectural approach — the term is borrowed, and this article uses it that way. The idea is worth explaining rigorously on its own merits rather than as a manufactured category.

What is an AI control plane?

An AI control plane is an emerging architectural approach for giving organisations central visibility, policy, permissions, enforcement and oversight across AI systems and autonomous agents. In practice, it aims to be the place an organisation can go to understand:

  • What AI systems exist
  • Who owns them
  • What identities they operate under
  • Which data they can access
  • Which tools they can use
  • What permissions they hold
  • Which policies apply
  • Which actions they attempt
  • What should be allowed, denied or escalated
  • What happened afterward

The term “control plane” is borrowed from infrastructure and network architecture, where a control plane determines how a system should behave while a separate data or execution plane does the actual work — a router's control plane decides routes; its data plane forwards packets. The analogy is useful for the shape of the idea. It shouldn't be stretched further than that — enterprise AI systems aren't network routers, and the parallel is architectural, not literal.

Control plane vs. execution plane

Carrying that distinction into an AI context gives a useful split between what decides and what performs:

CONTROL PLANE
Decides:
  • Policy
  • Identity
  • Permissions
  • Approval
  • Routing
  • Constraints
  • Oversight
EXECUTION PLANE
Performs:
  • API calls
  • Data retrieval
  • Workflow actions
  • Tool execution
  • Record modification
  • External communication
  • Agent actions

The AI control plane doesn't need to execute every business task itself. Its job is to establish the rules and controls under which AI systems operate — the execution stays wherever it already happens.

Why enterprise AI creates a control problem

AI in a typical organisation doesn't arrive through one channel. It tends to show up across:

  • SaaS products
  • Internal applications
  • Public model APIs
  • Private models
  • Browser tools
  • Copilots
  • Workflow systems
  • Autonomous agents
  • Developer environments

Different teams deploy different AI systems independently of each other, which is exactly how you end up with fragmented ownership, inconsistent permissions, inconsistent policy, invisible agents, unclear data access, duplicated controls and incomplete auditability — the same starting problem covered in our piece on shadow AI.

The core capabilities of an AI control plane

Pulling the idea into something concrete, a control plane's job tends to break down into eight capability areas:

  1. 01DISCOVERY
    • AI models
    • Agents
    • Applications
    • Providers
    • Data connections
    • Tools
  2. 02IDENTITY
    • Which agent/system is acting
    • Who owns it
    • Which human/service authorised it
  3. 03PERMISSIONS
    • Data access
    • Tool access
    • API access
    • System access
  4. 04POLICY
    • Allowed actions
    • Prohibited actions
    • Conditional actions
    • Approval requirements
  5. 05ENFORCEMENT
    • Applying policy before or during execution, where appropriate
  6. 06OBSERVABILITY
    • System activity
    • Agent behaviour
    • Attempted actions
    • Failures
    • Unusual behaviour
  7. 07AUDIT
    • What happened
    • Which policy applied
    • What was allowed/denied
    • Who approved it
  8. 08RESPONSE / CONTAINMENT
    • Revocation
    • Suspension
    • Credential restriction
    • Agent containment
    • Escalation

An AI control plane is more than a dashboard

This distinction matters. A dashboard observes. A control plane should also be capable of influencing or constraining behaviour, not just reporting on it after the fact. The difference shows up clearly in how each would describe the same event:

Dashboard
“Agent X accessed customer data.”
Control plane
“Agent X is not permitted to send customer data to this destination.”
Dashboard
“Agent Y attempted a payment action.”
Control plane
“This action requires human approval before execution.”

Visibility is necessary. Control requires the ability to translate policy into action.

AI control plane vs. traditional IAM

Traditional identity and access management remains essential, and none of this replaces it. IAM handles users, services, roles, authentication and access — the foundation everything else builds on. What an AI control plane needs on top of that is additional context IAM wasn't designed to carry:

  • Agent identity
  • Delegated authority
  • Model/tool behaviour
  • Action intent
  • Data classification
  • Dynamic policy
  • Autonomous execution

The AI control plane should complement existing identity infrastructure rather than attempt to recreate it.

AI control plane vs. SIEM / observability

The same logic applies to SIEM and observability platforms — they provide critical telemetry and detection, and that doesn't change. An AI control plane focuses on AI-specific context that general-purpose observability tooling isn't built to capture:

  • Agent identity
  • AI permissions
  • Model/provider
  • Tool usage
  • Policy context
  • AI action approval
  • Autonomous execution

Again: complement, not replacement.

AI control plane vs. AI governance platform

This one is worth being precise about, and connects directly to our piece on enterprise AI governance.

Governance focuses on
Policy, accountability, risk, lifecycle, oversight.
A control plane focuses on
Operationalising those decisions.

Governance may define the rule. A control plane helps make the rule enforceable. The two overlap heavily and may well exist within the same platform — this isn't a rigid industry taxonomy, just a useful distinction to keep in mind when evaluating what a given tool actually does.

Why autonomous agents make the control plane more important

The case for a control plane gets stronger, not weaker, as AI agents take on more autonomy. Agents may call tools, use APIs, retrieve data, modify systems, communicate externally, trigger workflows, delegate work, or interact with other agents. As that autonomy increases, so does the need for controls around:

  • Authority
  • Permissions
  • Approval
  • Policy
  • Monitoring
  • Containment

The more capable the agent, the more important the control layer around it becomes.

Pre-action control vs. post-action monitoring

This is one of the more consequential distinctions in this whole area. Post-action means observing after something happened. Pre-action means evaluating whether something should be allowed before execution.

Take an AI agent attempting to export sensitive customer records to an external API. Before that export happens, a control plane needs to be able to evaluate the request against a set of factors, and reach one of a small number of decisions:

EVALUATES
Agent identityData classificationDestinationRequested actionPermissionsApplicable policyApproval state
ALLOW
DENY
REQUIRE APPROVAL
RESTRICT
LOG + ESCALATE

This is architectural framing for what that decision point needs to be capable of — not a claim that Sentinel, or any product, performs all of this in production today.

Centralised control does not mean centralised execution

An important nuance: AI systems can keep operating wherever they already run — SaaS, cloud environments, applications, private infrastructure, developer platforms — without all being forced into one execution environment. A control plane can provide central policy and visibility across that spread without demanding that every workload move somewhere new first. That's what makes the architecture realistic rather than aspirational.

What should an enterprise AI control plane know?

For each system it's tracking, a useful control plane needs a record with real structure behind it:

FIELDWHAT IT CAPTURES
AI systemWhat it's called and how people refer to it.
OwnerWho is accountable for it.
System typeModel, agent, SaaS feature, API integration, etc.
Model / providerWhat's actually powering it, and who operates that.
Agent identityHow it authenticates and is recognised as itself.
Business purposeWhat it's for, in plain terms.
Data accessedWhat it can read or write.
Tools connectedWhat other systems and APIs it can call.
CredentialsWhat access keys or tokens it holds.
PermissionsWhat it's actually authorised to do.
Risk tierA deliberate classification, not a guess.
Applicable policiesWhich policies govern it.
Approval stateWhether it's actually been through review.
Current statusActive, restricted, suspended.
Last activityWhen it last did something.
Last reviewWhen someone last actually checked the above.
Audit eventsThe record of what it's done and what was decided.

Reference architecture

Put together, the layers involved look roughly like this:

ENTERPRISE SYSTEMS
DataApplicationsAPIsInfrastructureSaaS
AI LAYER
ModelsAssistantsAgentsAI-enabled applications
AI CONTROL PLANE
DiscoveryIdentityPermissionsPolicySecurityObservabilityEnforcementAudit
ACTIONS
ReadWriteExecuteCommunicateDeployTransact

A practical control-plane checklist

  • Discover AI systems.
  • Maintain an AI inventory.
  • Assign ownership.
  • Give agents identifiable identities.
  • Map data access.
  • Map tools and APIs.
  • Map credentials.
  • Apply least privilege.
  • Define enterprise AI policies.
  • Enforce high-risk policies where possible.
  • Require approval for high-impact actions.
  • Monitor AI activity.
  • Maintain audit trails.
  • Detect unmanaged AI.
  • Support revocation and containment.
  • Integrate with existing IAM/security systems.
  • Review controls as agent capabilities evolve.

Where Sentinel fits

Sentinel is Porthos Labs' exploration of this control-layer problem. It is being designed as an enterprise AI security and control layer for discovering AI systems and agents, understanding their access and permissions, applying policy, monitoring activity, and creating stronger operational control over autonomous systems. The product direction aligns with the emerging idea of an enterprise AI control plane described in this article — see Sentinel.

Closing

AI systems are becoming another operational layer of the enterprise. As they gain access to more data, more tools and more authority, organisations will need more than visibility.

They will need a way to define how intelligent systems are allowed to operate.

That is the role an AI control plane is beginning to describe.

RELATED RESEARCH
← Back to Research