Single Control Plane for AI Agents

Open Copilot Studio to check who owns an agent. Open Agentforce to read flow permissions. Open Bedrock for IAM roles, Vertex for service accounts, n8n for hardcoded credentials, ChatGPT Enterprise for shared workspaces. By the time you finish the loop, someone has built three more agents and wired up two MCP servers. This is the gap an ai agent control plane exists to close: one place to discover, govern, and enforce instead of a dozen native consoles that never talk to each other.

Each of those consoles shows the same thing, theoretical configuration. None of them show effective access. None correlate a Copilot agent with the Salesforce objects it actually read, or a Vertex agent with the Drive files it actually pulled. You are left stitching that story together by hand, across tenants, after the fact.

The insight that collapses the work: SaaS access and AI access are not two problems. An AI agent is a machine identity holding OAuth tokens against your third-party apps. A shadow agent is a shadow integration with a probabilistic brain attached. Agents already move roughly 16x more data than humans, and about 90% of them are over-permissioned, so the space between what an agent is configured to do and what it can actually reach is where the blast radius lives. Treating agents and app access as separate stacks is why teams are drowning.

The daily reality worth ending: stop digging through hundreds of agents across a dozen consoles. One plane. Discover, govern, enforce.

A real control plane does three jobs in one place. Do one of them well and you have a useful feature. Do one and call it a plane and you have a dashboard.

Discover, govern, enforce in one place

Discover without govern gives you an inventory nobody acts on. Govern without enforce gives you tickets nobody closes. Enforce without discover blocks the agents you already know about while shadow agents keep working. The value is the single map underneath all three: one authority map that shows which agent exists, who built it, which service account and credentials it inherited, what it can actually touch inside each app, and what it just did.

Most tools see one half of the picture. Agent-side tools read agent configuration but cannot see what the agent can do inside Salesforce or Drive. App-side tools read entitlements but cannot see the agent invoking them. Each gives you half an answer, and the risk lives in the half it misses.

A Knowledge Graph joins the two. It correlates the agent's builder and their credentials, the user who invoked it and their permissions, the MCP servers and connectors attached, the third-party app's actual entitlement resolution, and the runtime action that just occurred.

That correlation is the only way maker-mode privilege escalation shows up. Picture it. A user with no Salesforce access invokes an agent an admin built. The agent runs on the admin's service account. Salesforce sees a legitimate admin query and answers it. The user walks away with CRM records they were never provisioned to see, and nothing in Salesforce's own logs looks wrong. To catch it, you have to line up the runner's identity, the maker's permissions, and the object-level access the agent actually exercised, in one query. A one-sided tool cannot make that join. This is the difference between reading a config page and knowing effective access: the config page says what an admin can do, the graph says what this user just did through the admin's agent.

Enforcement does not require standing up another inline proxy. A gateway means new traffic paths, new failure modes, new latency, and a new thing for your team to own and page on at 2 a.m. Most teams do not want another box in the data path.

A control plane hooks into the AI platform through native APIs and webhooks instead. When an agent attempts an action, the platform calls out to the decision engine, which evaluates policy against the agent's effective access and returns allow, alert, or block inside a roughly one-second window. No packet inspection. No new network hop. If the decision service is unreachable, the platform keeps running and you lose a single decision, not a business process.

Think Intel Inside for AI security. The platform runs. The control plane decides. That is why this is an identity graph and decision engine, not a gateway: different architecture, different failure model, and the same enforcement outcome where it is live.

Vendors love to imply runtime enforcement everywhere. Here is the honest version.

Read the table literally. Discovery and governance span the enterprise agent stack today. Autonomous runtime blocking is live for Microsoft Copilot and Claude and nowhere else yet; every other row is planned, not present. So "single control plane" describes where you can see and govern agents, not a promise that the product blocks on every platform this quarter. When a vendor claims enforcement everywhere, ask which webhook or API they hook on each platform and how decision latency behaves under load. The honest answer is usually a roadmap.

This is why governing effective access matters even before enforcement is live everywhere. The UNC6395 campaign against Salesloft Drift reached around 700 organizations by abusing OAuth tokens held by a trusted integration, which is exactly the shape of a machine insider. You shrink that blast radius by seeing and constraining what agents can reach across platforms, not by waiting for a block button on all of them.

A control plane retires the manual work you are doing to fake one today:

• Hand-maintained agent inventory spreadsheets that are stale the day after you build them.
• Ad hoc console reviews across Copilot, Agentforce, Bedrock, Vertex, and n8n.
• Native log stitching in your SIEM to reconstruct what an agent touched.
• Quarterly access reviews performed by hand, which cannot keep pace once you cross 100 agents.

It does not replace your identity provider, your SIEM, or your existing security tooling. Those stay. The control plane sits alongside them as the authority layer for machine insider risk, turning theoretical configuration into runtime truth: which agent, which service account, which objects, which action, allowed or blocked. That evidence generates itself as agents operate, so the next time your audit committee asks how many agents you run and what they can reach, the answer is a query, not a fire drill.