Enterprise AI Control Planes: What Businesses Need Before Agents Touch Core Systems

Enterprise AI Control Planes: What Businesses Need Before Agents Touch Core Systems

AI agents are moving from answering questions to doing work: querying business systems, invoking APIs, updating records, coordinating workflows and acting across multiple applications. That changes the risk model. Once an agent can take action, the most important question is no longer only which model is smartest? It becomes who can the agent act as, what can it access, which actions are allowed, how are those actions observed, and who can stop or reverse them?

That is why “AI control plane” is becoming an important enterprise architecture concept. Salesforce has announced an AI Control Plane as part of its Trusted Enterprise AI Harness, while Boomi is positioning an Agent Control Plane around governance, access, auditability and cost control. OpenAI’s enterprise agent platform likewise emphasizes explicit permissions, agent identity, auditing and integration with systems of record. These products are different, but they point to the same architectural need: autonomous or semi-autonomous AI needs a control layer around execution, not just a model endpoint.

For businesses evaluating agentic AI, the useful lesson is not to buy a product because it uses the phrase “control plane.” It is to define the controls your organization needs before an agent is allowed to touch production systems.

What an AI control plane is actually controlling

A practical AI control plane sits between business policy and agent execution. It should help answer six questions continuously:

1. Identity: Which agent is running, on whose behalf, and under which organizational identity?
2. Access: Which data, tools, APIs and environments can that agent reach?
3. Action: Which operations may it perform automatically, and which require human approval?
4. Observation: Can the organization reconstruct what the agent saw, decided, called and changed?
5. Evaluation: Is the agent still performing within acceptable quality, safety and business thresholds?
6. Cost and lifecycle: Who owns the agent, what does it cost, which version is active, and when should access be revoked?

Those controls matter because an AI agent is not just another user interface. It can become a new machine actor inside the enterprise. If it receives broad credentials, persistent tool access and weak monitoring, it can concentrate more operational capability than an ordinary employee account.

Salesforce’s September 2026 announcement describes a control plane that discovers and registers agents, establishes identity and policy, manages lifecycle, evaluates performance, observes behavior and outcomes, and controls cost across first- and third-party AI. OpenAI Frontier similarly describes agent identity and access management, explicit permissions, auditable actions and observability. The architecture vocabulary differs, but the operating principle is consistent: agent execution needs governed identity, constrained permissions and visible actions.

The minimum architecture before agents can act

A useful control plane does not have to start as one giant platform. It can begin as a set of enforceable architecture rules.

1. Give every production agent a distinct identity

Do not let multiple agents share a generic service account if you can avoid it. A distinct identity makes permissions, logs, ownership and incident response more precise.

The identity record should answer:

• business owner;
• technical owner;
• purpose and approved use cases;
• environments the agent may access;
• data classifications it may handle;
• tools and APIs it may invoke;
• model/runtime version;
• expiry or review date.

This also makes decommissioning possible. When an experiment ends, the organization should be able to revoke the agent’s access without breaking unrelated automation.

2. Use least privilege for tools and data

An agent that only needs to read product inventory should not also have permission to change prices, issue refunds and export customer records.

Separate read, propose and execute capabilities. Where practical, expose narrow business operations rather than raw administrator-level APIs. For example, create_refund_request is safer to govern than unrestricted database write access.

Access should also be contextual. A finance agent may need different permissions by subsidiary, transaction amount, time window or workflow stage. The control layer should enforce those boundaries outside the model prompt, because prompts are not a strong authorization mechanism.

3. Put high-impact actions behind deterministic gates

AI reasoning can be probabilistic; some enterprise actions cannot be.

Define which actions may be:

• fully automated;
• automated below a threshold;
• proposed by AI but approved by a human;
• prohibited entirely.

Payments, user access changes, deletion, payroll changes, contract commitments and sensitive customer communications are typical examples where organizations should consider stronger gates.

The important design principle is to make the gate deterministic and external to the model. The agent can recommend an action, but a policy service or workflow engine decides whether execution is permitted.

4. Keep an audit trail that reconstructs the action

A useful audit event should capture more than “AI ran successfully.”

Depending on sensitivity, record:

• agent identity and version;
• initiating user or system;
• time and tenant/organization context;
• tool or API invoked;
• relevant policy decision;
• parameters or a safe representation of them;
• result and changed resource identifiers;
• approval evidence when applicable;
• error or rollback state.

Logs must also respect privacy and security. Do not solve observability by indiscriminately copying secrets, credentials or unnecessary personal data into log storage.

5. Evaluate behavior continuously, not only before launch

NIST’s AI Risk Management Framework organizes risk work around Govern, Map, Measure and Manage, while its 2026 TEVV-Athlon draft explicitly addresses evaluation methods that can extend to agentic systems. The practical implication is that approval to launch an agent should not be permanent proof that it remains safe or useful.

Track measures relevant to the workflow, such as:

• task success;
• human override rate;
• policy violations;
• tool-call errors;
• hallucinated or unsupported actions;
• latency;
• cost per completed task;
• incident rate;
• rollback frequency.

Set thresholds that trigger review, reduced permissions or automatic suspension.

6. Separate model choice from business controls

Models will change faster than enterprise governance.

If authorization, audit, policy and tool access are tightly coupled to one model vendor, changing models can become a security redesign. A stronger architecture treats the model as one component behind a stable control boundary.

This is one reason current enterprise platforms are emphasizing composability and multi-vendor control. Businesses may use different models for different tasks, but the organization still needs one coherent policy for identity, access, approvals and evidence.

What this means for Malawi businesses

Malawi organizations do not need to wait for a large “agentic enterprise” programme before applying these controls.

A company connecting AI to accounting software, a customer-support platform, an ERP, a mobile-money integration or an internal database already has the core governance problem. The first production agent may be small, but it can still access valuable data and trigger consequential actions.

A practical starting pattern is:

For organizations with limited IT capacity, this approach is more realistic than trying to build a sophisticated centralized platform on day one. Start with the control requirements, then decide whether they are best implemented through existing IAM, API gateways, workflow tools, observability systems, vendor control-plane products or a small custom governance service.

Questions to ask vendors and implementation teams

Before approving an agent that will touch core systems, ask:

• Does every agent have a unique identity?
• Can permissions be scoped per tool, action, tenant, environment and data domain?
• Can sensitive actions require human approval?
• Are authorization decisions enforced outside the model prompt?
• Can we see every production tool call and the resulting action?
• Can we revoke an agent immediately?
• Can we change the model without rebuilding the entire security boundary?
• Can we evaluate quality and safety against our own test cases?
• Can we set cost limits or usage policies?
• What happens when a tool call partially succeeds?
• How are secrets stored and rotated?
• How long are logs retained, and what sensitive data do they contain?
• Can third-party agents be governed alongside internally built agents?
• Can the system prove which policy and version applied to a historical action?

Weak answers to these questions are a warning that the organization may be automating execution faster than it is building accountability.

Do you need a dedicated AI control-plane product?

Not always.

A dedicated platform becomes more valuable when an organization has many agents, multiple model providers, several development teams, fragmented tool access or strong audit/compliance requirements. A smaller organization may initially achieve the same control objectives with existing identity management, an API gateway, scoped service accounts, approval workflows, centralized logging and an agent registry.

The architecture decision should therefore start with control objectives, not product labels.

A sensible progression is:

1. inventory production agents and AI-enabled automations;
2. assign owners and unique identities;
3. map data and tool access;
4. classify actions by impact;
5. implement approval and authorization rules;
6. centralize audit and evaluation;
7. add cost/lifecycle management;
8. consolidate into a dedicated control plane when scale or complexity justifies it.

The strategic takeaway

The enterprise AI race is moving beyond model access. The differentiator is increasingly the system around the model: trusted context, secure actions, evaluation, policy, identity and observability.

That does not mean every business needs to copy the architecture of Salesforce, OpenAI or Boomi. It means businesses should treat AI agents as governed production actors before giving them production power.

The best time to design that control boundary is before agents can change orders, move money, expose data or alter critical records—not after the first incident.