AI Control Plane for Companies: What to Build Before Agents Scale

An AI control plane is the layer that governs what each company agent is, what it may access, what it must ask a person before doing, and what gets recorded about its work. It sits above the models and tools, so swapping a model or adding a tool does not quietly change who is accountable for the agent. Companies should build this layer before agents take on more steps, because a more capable agent can act across several systems before anyone notices, and informal supervision does not stretch that far.

Key takeaways

• A control plane separates what an agent may do from how the agent reasons, so you can change one without rebuilding the other.
• Give every agent its own identity, a named human owner and a written scope before it touches a shared system.
• Record decisions and actions in a form an operations leader can review, not only raw technical traces.
• Set approval boundaries by consequence: reversible internal work can run alone, while external, financial or hard-to-undo actions wait for a named person.
• Review permissions on a schedule and after every capability change, not only after an incident.

What a control plane governs

Most teams start by asking what an agent can do. A control plane asks a different set of questions: who the agent is, who answers for it, which systems it can reach, which actions need a person, and what evidence remains afterward. In practice, a working control plane for company agents covers six areas:

• Identity: the agent's name in your directory, its owner and the account label that appears in logs.
• Permissions: the systems, actions and credentials the agent holds, each scoped to the task.
• Context: the documents, memory and data sources the agent can read and retain.
• Approvals: which actions run alone, which notify someone, and which wait for a named approver.
• Logs: what the agent was given, which tools it called, what it decided and who approved what.
• Limits: operating hours, request ceilings and the behavior when a limit is reached.

The separation matters because the business task and the governance rules change on different timelines. A sales process may be revised every quarter, while the rule that a contract cannot be sent without a signed approval should change only through a recorded decision. Keeping the two apart lets you improve the agent without redesigning oversight each time. If you have not yet mapped where these layers sit in your systems, draw your AI stack on one page before choosing tools.

Why stronger agents raise the cost of weak controls

An agent that only answers questions can be wrong in a contained way. An agent that reads a mailbox, looks up a customer, drafts an offer and updates a record is chaining actions across systems. Each step may be reasonable on its own, so the risk sits in the combination. A single mistaken answer becomes a sequence of changes that someone must trace and reverse.

There is also a security dimension. Content an agent reads, such as an inbound email, a web page or a shared document, can contain text written by someone who wants the agent to behave differently. The OWASP Top 10 for LLM Applications lists prompt injection and excessive agency among the core risks for these systems. An agent with broad write access that also reads outside content is exposed by design. The answer is not a longer instruction in the prompt. The answer is narrower permissions and approval gates that hold even when the agent has been persuaded to act.

The NIST AI Risk Management Framework describes governing, mapping, measuring and managing AI risk across the life of a system. A control plane is where those ideas become operating routines: who reviews, which measurements are kept, and what happens when a result looks wrong. Whatever pace capability takes, the control design should not depend on predicting it. It should be reviewable today and extendable tomorrow.

Identity and permissions come first

The first build is identity. Do not let agents share a staff login or inherit a manager's broad access. An agent needs its own account, its own credentials and a written scope. Start with these steps:

• Name the agent as an actor in your directory, with one human owner who answers for its scope and its changes.
• List every system it touches, and for each one write the specific action it needs, such as reading order status or creating a draft, rather than a general category like admin access.
• Issue separate credentials per system, scoped to read or write, and revoke them through the same process you use when a staff member leaves.
• Remove any standing write access you cannot justify in one sentence.
• Test the boundary by asking the agent to perform an action outside its scope, then confirm the attempt fails and appears in the log.

The OAuth 2.0 authorization standard describes delegated access with scoped tokens, which is the right mental model: the agent receives a limited grant, not the owner's full authority. The OWASP Authorization Cheat Sheet recommends denying by default and checking permission on every request instead of trusting the interface or the previous step. Both points lead to the same practice: each tool call should be checked against the agent's scope at the moment it happens.

Once the first set of grants exists, review it on a fixed schedule. A structured method is described in how to run a permission review for your AI agents, step by step.

Approvals and logs decide what you can trust

Approval boundaries are the most visible part of the control plane, and they are easiest to get wrong by making everything require sign-off, which quickly teaches people to click through. A simple decision guide keeps the boundaries useful:

• Run without review: read-only lookups and drafts that no one outside the team will see.
• Run and notify: reversible internal updates, such as tagging a ticket or filing a summary, with the owner informed.
• Require named approval: anything external, financial, involving personal data, or difficult to undo, such as sending a document to a customer or changing a supplier.
• Do not allow yet: actions no one has justified, such as deleting records or changing another agent's permissions.

Illustrative scenario: an operations agent at a small distributor prepares reorder requests. It may compare stock levels and draft purchase orders without review. Sending an order to a supplier waits for the purchasing lead's approval. The log stores the stock figures the agent read, the draft it produced, the approver's name and the moment of approval. When a supplier changes its lead times, the rule for drafting is updated through a recorded change, not by editing a prompt in place. Changes like this should follow a defined path, which is set out in how to request and approve changes to a managed AI agent.

Logs need to answer four questions: what the agent saw, which tool it called and with which parameters, what it decided, and who approved the action when approval was required. Observability practice treats telemetry as the signals that explain how a system behaved, and agents need the same discipline with one addition: the reasoning context that led to a decision. The log should also be readable by a non-engineer. A weekly summary of exceptions, refusals and approvals is more useful to an operations leader than thousands of raw traces, although the raw traces should remain available for investigation.

Memory, tools and context need explicit boundaries

Retrieval systems pull documents into an agent's context when it answers, which is what makes them useful for company knowledge. It also means every indexed source is a permission decision. Index only what the role needs, and keep memory separate for each role so that a sales agent does not carry HR records or a support agent does not hold unreleased pricing notes. Google Cloud's retrieval architecture guidance and AWS's overview of retrieval-augmented generation both describe this pattern of fetching governed sources at answer time, which is the point where access rules must apply.

Tool definitions deserve the same care. The way a tool is described shapes how an agent uses it, so write each tool definition as you would a job description: what it does, what inputs it accepts, what it must never be used for, and what a person should check first. Vague tool descriptions produce broad, unpredictable use.

Know-how is the asset that accumulates inside an agent's memory and workflows. Decide before scaling how long the agent keeps notes, how those notes are exported, how they are deleted, and which models are allowed to process them. This is the part of the control plane most often skipped, and it is the hardest to fix later. The principles are developed in protect company IP with AI and keep know-how out of shared models.

Build the control plane in this order

A practical sequence keeps the work small enough to finish and reviewable at each step:

• Inventory every agent in use or planned, with its owner, its channels and the systems it reaches.
• Write one measurable success criterion per agent, so you can tell whether a later change is an improvement or a drift.
• Create identity and scoped credentials for each agent before any production data is connected.
• Define the approval tiers and name the approver for each external, financial or irreversible action.
• Turn on logs that capture inputs, tool calls, decisions and approvals, and review a sample every week.
• Run an evaluation set after each change and keep the results attached to the change record.
• Schedule permission reviews, and test that you can suspend one agent's access quickly without affecting the others.

Be Human designs and operates this layer as part of a managed service. A first engagement defines one useful role, the memory and tools that role needs, the approval boundaries and an observable success criterion. Ongoing operations can include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, so that each change to an agent is recorded and reviewed before it becomes part of daily work. If you are not sure which task should go first, the free Be Human AI diagnostic can help you find the first task worth handing to an agent.

Frequently asked questions

What is an AI control plane? An AI control plane is the governing layer that sits above AI models and tools and defines an agent's identity, permissions, context, approvals, logs and operating limits. It lets a company change the agent's work without losing track of who authorized what. It is most useful when agents can act in more than one system.

Do small companies need an AI control plane before scaling agents? Yes, although it can be small. A small company needs a named owner per agent, scoped credentials, a short list of actions that require approval and a log that someone actually reads. These controls take less effort when they are set up before the agent is widely used than after.

What should an AI agent log? An agent's logs should show the inputs it received, the tools it called with their parameters, the decisions it made and any approval that was required and given. Keep a readable weekly summary for leaders and the detailed records for investigation. Logs should also show refusals and blocked actions, because those reveal where boundaries are working.

Who should own the control plane inside a company? Ownership should sit with a named business leader who is accountable for the outcome, supported by someone who runs the technical controls. The business owner decides approval tiers and accepts risk, while the operator maintains identities, credentials, logs and reviews. Splitting these roles clearly prevents both unchecked access and bottlenecks.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.