Abhijeet Mukkawar | Enterprise Architect, Siemens Digital Industry Software.gettyWhen my recent article argued that agentic AI is being built for enterprises that don't exist, I focused on the gap between clean demo environments and the messy, multi-vendor IT/OT reality most organizations run. Since then, something else has become impossible to ignore: The agents are arriving faster than our ability to see them, let alone govern them.Business units are spinning up agents using various IT tools, SaaS platforms and COTS products. Meanwhile, OT vendors are adding "autonomous" features at the edge. However, many enterprise architects and leaders don't know the answers to a few basic questions: How many agents do we have? What are they allowed to touch? Who is on the hook when one makes a bad decision? How can we control what they should and shouldn't do?That is why the conversation is rapidly shifting to "How do we build an agent control plane?"Why Agents Require Their Own Control PlaneAgents don't behave like traditional software. A conventional application executes a predefined flow. An agent reasons about a goal, chooses tools and acts—often across multiple systems. As they reason and execute, they don't have a defined path. With the ongoing ease of developing agents, their number can grow from a handful to hundreds or thousands across vendors and business domains.A decade ago, we saw identity sprawl beyond manual control. Now, we're watching "agent sprawl" outgrow the current governance framework. An agent control plane is one of the trends to solve this challenge. Defining An Agent Control PlaneForrester describes an agent control plane as a vendor-agnostic governance layer that inventories agents, enforces policy at the moment of action and records what happened. An agent control plane answers three questions at any time, for every agent: Who are you? What are you allowed to do? What did you just do—and where?This is not the same thing as orchestration. Orchestration is about how workflows run. The control plane is about whether they're allowed to run, under what constraints and with what evidence.Kubernetes did it for containers. Identity providers did it for users and apps. Once scale and heterogeneity reached a certain point, we needed a separate layer to see the whole picture and enforce rules consistently. Agents are hitting that point.What Happens When You Don't Have A Control PlaneThe main concern is that many business units are deploying AI agents without centralized oversight.While vendors may have their own vendor-specific minimal governance, several failure modes show up quickly when security teams discover active agents during audits:• Shadow Agents: Teams wire up agents to internal systems and forget about them. Months later, no one remembers what data they can see or which credentials they use.• Cross-System Incidents: An IT-side agent resolves an exception, triggering a change that cascades into a physical adjustment on the shop floor through an OT-side agent. Each stack logs its own view. When something goes wrong, no one can reconstruct the chain of decisions.• No Single View: There's no consolidated telemetry of the overall agentic landscape.This is what "unmanaged automation with probabilistic behavior" looks like in practice. To address these challenges, here are a few key design principles for building a vendor-agnostic agent control plane: • Start with a live inventory. You can't govern what you can't see. Automatic discovery of agents, models, tool connections and agent-to-agent links is essential.• Treat agents as identities with sponsors. Every production agent needs its own identity, bounded permissions and a named human sponsor responsible for its lifecycle.• Put the policy engine at the seams. Most controls live inside individual tools. The hard problems show up at boundaries: between IT systems, cross-domain systems, between IT and OT, between agent ecosystems. Express policies once and enforce them wherever relevant.• Make observability and evidence the default. Record intent, context, tool usage and handoffs between agents, not just the final API call. That gives you a defensible audit trail.• Design for openness. If the layer that prevents agent lock-in is itself proprietary, you've simply moved the problem. Assume hybrid and multi-cloud, multiple model providers and evolving frameworks from day one.Considerations For Brownfield EnvironmentsIn brownfield landscapes with decades of accumulated complexity, a control plane becomes about safety, survivability and avoiding governance collapse.Most large enterprises run multiple ERPs or cross-domain systems, layered with best-of-breed tools—each with its own authentication, permissions and audit system. These platforms were built for rigid workflows, not autonomous agents making distributed decisions. The data is messy or locked behind proprietary schemas. Custom fields proliferate. Extensions that were "temporary" a decade ago are now load-bearing. None of this can be ripped out, as these systems often run payroll, revenue recognition and regulatory reporting.Without a control plane, no one can track autonomous agents reading custom SAP fields or batching Oracle updates while hitting rate limits using service accounts. On the OT side, constraints are tighter. Industrial control systems, programmable logic controllers and supervisory control and data acquisition platforms often predate modern APIs. They were designed for safety and uptime, not flexibility. Many run on protocols older than the cloud. Because OT assets are safety-critical and can't tolerate downtime, you can't experiment your way to a solution, as the cost of a mistake can be plant shutdowns or safety events.A control plane has to be an overlay, not a replacement. It needs to inventory agents touching custom API calls and multi-subsidiary structures, enforce policies at the boundary between IT and OT devices that barely expose metadata and audit decisions spanning vendors and decades-old middleware without requiring re-platforming.Three Leadership QuestionsIf you're a CIO, CISO, digital transformation or technology leader, ask:• Can you show me a single view of every agent across vendors that your platform can see and control?• Where do I define a policy once and have it enforced across IT systems, OT environments and different clouds?• If an autonomous change crosses three systems, can I reconstruct the full decision trail?Most organizations are still focused on the strength of their agentic models without understanding how and where those models are used. A control plane is the primary governance consideration, as you can only scale agents when you know what you're scaling.Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
You Can't Govern What You Can't See: The Case For Agent Control Planes
The control plane is about whether agents are allowed to run, under what constraints and with what evidence.










