# AI Agent Control Plane

> What an AI agent control plane does: identity, permissions, credentials, policies, approvals, audit, and shared organizational context around autonomous agents.

An **AI agent control plane** is the governance layer around agents: it decides who an agent is acting for, what context and tools it can access, which credentials are available, which actions need approval, and how the resulting work is audited.

The agent's reasoning loop is not the control plane. Neither is the model. The control plane sits around those components so agents can operate inside real organizational boundaries.

## Control plane vs agent runtime

The distinction is similar to other infrastructure systems:

- the **runtime/data plane** performs the work: model calls, tool calls, code execution, retrieval, and actions
- the **control plane** defines and enforces the allowed environment: identity, policy, access, approvals, configuration, and audit

One product can provide both, but the responsibilities should remain conceptually separate.

Lobu can run managed agents, but it also exposes the control/context layer to external agents such as ChatGPT, Claude, Codex, and other MCP clients.

## Minimum capabilities of an agent control plane

### 1. Scoped identity

An enterprise agent should not be one global superuser. It needs a clear identity and, often, the identity of the human or role it is acting for. That scope determines which company context and actions are available.

### 2. Credential isolation

Agents need access to tools without receiving a bag of raw API keys and OAuth tokens. A control plane can broker credentials at the gateway or tool boundary so the agent gets capability without directly owning the secret.

Lobu's MCP proxy and gateway inject credentials when requests are made. See [MCP proxy](/guides/mcp-proxy/) and [secret proxy](/guides/secret-proxy/).

### 3. Tool policy

Not every visible tool should always be callable. Policy may depend on the agent, user, environment, connector, or operation. Some tools can run automatically; others should be hidden or require approval.

See [Tool policy](/guides/tool-policy/).

### 4. Human approvals

Autonomy is not binary. A useful system can let an agent investigate freely, draft a change, and stop at the point where a person must approve a sensitive action. The approval itself should become durable state rather than an ephemeral chat message.

### 5. Guardrails

Policies can also apply before or after a model/tool boundary: input checks, output checks, pre-tool rules, and egress controls. See [Guardrails](/guides/guardrails/).

### 6. Audit and provenance

Operators need to answer:

- what did the agent observe?
- what context did it use?
- which tool did it call?
- who approved the action?
- what changed afterward?

That requires durable events and traces, not only application logs.

## Why shared context belongs next to control

Permissions cannot be bolted on after retrieval. If company context is separate from the identity model, agents can accidentally retrieve information the human they represent could not access.

For that reason, Lobu treats context and control as one operating layer: the same identity that scopes tools also scopes organizational state.

See [Company context for AI agents](/company-context-for-ai-agents/).

## Agent control plane vs orchestration

Orchestration answers questions such as:

- which step runs next?
- should this task retry?
- which subagent should handle this branch?

A control plane answers different questions:

- is this agent allowed to see the source?
- which identity is it acting under?
- can it call this operation?
- does the action require approval?
- where are the credentials held?
- what evidence and audit trail must be preserved?

A system may provide both, but orchestration alone does not solve governance.

## How Lobu acts as an agent control plane

Lobu provides:

- org- and user-scoped identities
- connections to company systems
- permission-aware shared context and memory
- gateway-mediated MCP and credential injection
- isolated execution for managed agents
- per-tool policy and guardrails
- human approvals
- append-only events and audit history
- self-hosted or managed deployment

Existing agents can connect over [MCP](/mcp/) rather than being rewritten into a Lobu-specific harness.

## When you need a control plane

A dedicated control layer becomes useful when agents:

- operate for multiple employees or customers
- use credentials for real company systems
- take actions with financial, operational, security, or customer impact
- run proactively outside a supervised chat turn
- need different access depending on the user or organization
- must produce a reliable audit trail

A local personal agent using your own shell and files may not need this abstraction.

## Read next

- [AI teammate infrastructure](/ai-teammate-infrastructure/)
- [Company context for AI agents](/company-context-for-ai-agents/)
- [Tool policy](/guides/tool-policy/)
- [Guardrails](/guides/guardrails/)
- [Security](/guides/security/)
- [Related systems and research](/getting-started/related-work/)