This article supercedes the original article 2026 Enterprise Guide for AI Control Plane I published in May.
The short version
Microsoft says nearly 50 million agents are registered on its platform. No vendor I looked at publishes how many agents sit under an enforced policy.
A control plane earns the name where it can refuse an agent at the tool call; model-call checks only lower the odds.
Where the model runs decides who owns its safety layer, and for imported weights that layer is often off, absent or yours.
No deadline forces a purchase this quarter, so pick the governance step you are on, then pilot 2 vendors against it.
Everything here is read from vendor documents, filings and incident reports. I have not run any of these products in production.
On September 30 Microsoft wrote that “nearly 50 million agents have been registered across tens of thousands of organizations” since Agent 365 launched in May. It is the biggest number I have seen anyone in this market publish, and it answers a question I do not hear anyone at a mid-market company asking.
The question I do hear is different.
Of the agents in your company, how many would be stopped if they tried to do something they are not allowed to do? Microsoft does not publish that number. Neither does ServiceNow, Salesforce, Databricks, AWS or Google, and I looked hard.
A registration is a count of agents that have been written down. Governance is a count of agents that a policy can refuse at the tool call. This guide is about the gap between those 2 counts and how to close it for your own agents.
One disclaimer before anything else.
Every claim here comes from vendor documents, regulatory filings and incident write-ups I read this month, not from a deployment I ran. Where I say a product “enforces” something, I mean its own documentation says so.
What a control plane does
An AI control plane is the layer that answers 5 questions about every agent you run. An agent, for this article, is software that uses an AI model to decide what to do next and then does it: calls a tool, reads a record, sends a message.
Identity. Which agents exist, who owns each one, and what is it supposed to be? The answer should come out of a register in a minute, not out of a spreadsheet someone updates when they remember.
Authorization. Which tools, data and systems is each agent allowed to touch? Here “allowed” has to mean “refused if not.”
Policy. The rules an agent operates under: what it may say, where its data may live, which model it calls and what safety layer sits around that model. If the rule only lives in a PDF, it is a wish. If the platform checks it on every call, it is a policy.
Evidence. For any action an agent took yesterday, can I see the prompt, the policy decision, the tool it called and where the data came from, without raising an engineering ticket?
Lifecycle. Register, version, retire and kill, with evidence in the log that the kill worked.
Where the model runs, and who operates the safety layer around it, sits inside policy and lifecycle, because whoever picks the model inherits the job of screening what goes into it and what comes out.
It is where I found the vendors differ most, and where I suspect buyers assume the most.
Who sells one now
Every major platform now ships a register of agents, about half pair it with a gateway that sits in front of calls, and most claim to reach agents built somewhere else. The table lists what I could verify in each vendor’s own documents. “Enforces” means a documented point where the platform can refuse a call.
2 things stood out when I read these side by side.
The first is that “control plane“ now appears in Salesforce’s, Databricks’, Palo Alto’s and Microsoft’s own copy, for products that do different jobs. Salesforce’s is a plan for early fiscal 2028, Databricks’ is a claim with no documented mechanism for agents outside its lakehouse, and Palo Alto’s is a gateway in front of model calls.
The second is that the enforcement that does exist is narrow. ServiceNow can revoke an agent’s credential and stop it at runtime. AWS can refuse a tool call at its gateway under a written policy. Microsoft can refuse an identity. None of them documents how many customer agents sit under one of those controls, and ServiceNow’s July filing reports contract value and deployment growth, not agents governed.
The identity vendors are the ones I watched most closely.
Between May and September, 3 identity vendors and 1 data-security vendor closed deals for startups that give agents their own credentials. That tells me where those buyers expect enforcement to end up. It does not tell me it has ended up there yet: SailPoint said on October 6 that its Entro integration “will soon be complete,” and Okta’s September release gives Permiso-based detection no ship date.
Where the model runs, and who runs the harness
Every agent calls a model, and that call is a boundary where a platform can screen what goes in and what comes out. That screening layer is what the vendors have started calling a harness, so I will use their word. Some vendors guard this boundary for your models; others leave it to you.
Microsoft shows it in 2 current documents.
Foundry agents may call “a self-hosted, non-Azure hosted, or custom solution“ through a gateway, and for those models “you are responsible for implementing your own responsible AI mitigations,” used “at your own risk.”
Its Fireworks service, which also takes your own weights, applies “the Microsoft.DefaultV2 guardrail unless a different one is specified.“ So whether a harness is on depends on which of Microsoft’s 2 doors you came in through.
Oracle is the plainest: “Guardrails aren’t available for imported models.”
Databricks ships its guardrails as service policies, still in beta.
On AWS you can import your own weights, screen text with Bedrock Guardrails separately from the model, and enforce tool policy at the AgentCore gateway, but the docs describe these as parts you wire together, not a switch.
Google’s custom-weight deployment is preview; its Model Armor screening has been live on its gateway since June 24.
ServiceNow takes no outside model for its agents, only for skills.
Salesforce built its Koa model on open NVIDIA Nemotron weights so that “Salesforce controls the model weights“ and inference stays “entirely within its own trust boundary.“ I could not read SAP’s or IBM’s documents, so their absence here is my limit, not a finding.
The best evidence I have seen that the harness is a separate layer comes from an incident. OpenAI’s technical report on the July Hugging Face intrusion says a model’s tendency to compromise infrastructure “can drop over 100x when using the production ChatGPT harness and system prompt.“
So what the model does depends on the harness you put around it.
A download is more than weights: it ships with loader code and a chat template. CISA, the US cyber agency, says a model without its training data and pipeline should be treated as “proprietary software with incomplete provenance.” Hugging Face’s own docs recommend pinning a commit hash so the loader code cannot change under you, and outside NVIDIA’s catalog I found no model signing you can enforce today.
There is one good reason to keep a model you run yourself even if you govern everything else through a vendor. Hugging Face’s incident timeline says its responders ran GLM-5.2 on their own infrastructure after hosted models, Claude Opus among them, refused much of the analysis. I’d keep a local model for that, with one limit: a different model cannot reproduce what your production model did, so it is for analysis, not replay. Renting an open model by the token is cheap now, gpt-oss-120B at $0.15 in and $0.60 out per million tokens on Together today, so the self-hosting decision is mostly about who operates the harness.
Registered is not governed
In July, by both companies’ accounts, an autonomous agent running on OpenAI models broke into Hugging Face through a dataset-processing pipeline. Hugging Face’s own timeline has the 2 sentences that matter: “We had wrongly provisioned that broker with a single connector credential shared across clusters,” and “One stolen system credential was therefore cluster-admin everywhere.” The agent was somebody else’s, so no register of Hugging Face’s agents would have listed it. What would have shrunk it is enforcement at the tool boundary: a credential that only works on one cluster, and a gateway that refuses a call outside policy.
That is the test I’d apply to every row in the table: not “does it register my agents“ but “at which boundary can it refuse, for my model, my runtime and my tools, and what evidence is left afterward?”
The tool boundary is where an agent calls a system, and a gateway sits in front of that call. The Model Context Protocol (MCP, the common way agents call tools, now a Linux Foundation project) made that job easier in July: its spec went stateless and put the method and tool name in headers, so “gateways can route and authorize on headers directly.” The model boundary is where the agent calls the model, and the vendor documents show how often the harness there is off, absent or yours.
Even where it is on, it can be beaten: researchers from OpenAI, Anthropic and Google DeepMind showed in October 2025 that adaptive attacks beat all 12 prompt-injection defenses they tested, most more than 90% of the time. A harness lowers the odds. The refusal you can count on is at the tool boundary.
One bill in Congress is heading the same way. H.R. 10362, the Stop Rogue AI Act, was introduced in the House on September 14 and referred to 2 committees. Its sponsors say it would have NIST write standards to find and track every AI agent, verify who built and runs it, and “allow, deny, or revoke” its access.
2 lines in the text caught me: standards “not dependent on proprietary or platform-specific registries,” and identity that does “not rely solely on self-attested or single-provider assertions.” I read that as aimed at every single-vendor register.
It is introduced, not law yet. If enacted it binds federal agencies and contractors, NIST gets a year, and the FAR Council, the body that writes the rules for federal buying, up to 18 months after that.
I found no regulator that has said what the enforcement number should be either. US bank regulators’ April model-risk bulletin says generative and agentic AI “are not within the scope.”
How I’d decide
Pick the step, then the vendor. The step is which of these you can answer yes to next, in this order.
Inventory
Can I list every agent and its owner in a minute?Credential
Does each agent carry its own credential, limited to its job and revocable on its own?Tool boundary
Can a gateway refuse a tool call under a written policy, and log the refusal?Model boundary
For every model my agents call, who runs the harness, is it on, and can I prove it?Evidence
Can I produce the prompt, the decision, the tool and the data for yesterday’s action without a ticket?
My guess is that most mid-market companies are on step 1 or 2, and the vendor pitch is aimed at step 5.
Your stack narrows the choice.
A Microsoft 365 shop starts ahead on steps 1 and 2 because Entra already governs every human identity.
A Databricks shop gets steps 3 and 4 for data agents from Unity Gateway, with the beta caveat.
On AWS, step 3 comes from AgentCore Policy and step 4 from Guardrails, both as parts you wire up yourself.
For Salesforce, ServiceNow, Workday and Oracle, I’d verify each boundary rather than trust the register.
The EU dates leave room, with one exception.
Regulation (EU) 2026/1744, in force since July 27, sets the high-risk obligations for the listed uses at 2 December 2027 and for products covered by existing safety law at 2 August 2028. The transparency duties under Article 50 applied from 2 August 2026. Telling people they are talking to an AI gets no grace period; generative systems already on the market have until 2 December 2026 to mark their output. So the transparency work is due now and the high-risk work has 14 months.
The Commission’s own FAQ says a company that modifies a general-purpose model is “not automatically subject to all the obligations.”
That is not legal advice, and I’d put the question to counsel before importing weights.
I’d run 2 vendors for 90 days against the same agents and the same test: at each boundary, show me the refusal and the log. The places where the 2 do not line up (identity format, policy language, log shape) are what you learn from, and a single-vendor pilot hides every one of them.
What I’d do on Monday
Count 3 numbers: agents registered, agents under an enforced policy at the tool boundary, and agents whose model call has a harness switched on.
Ask each vendor in writing: for an agent using my model, on my runtime, calling my tool, show me the refusal and the log entry.
Revoke one agent’s credential and watch what happens.
See whether your API gateway’s prompt-attack check is on. Azure API Management’s is off by default.
I’d write down who owns the harness for every imported model. If the answer is the vendor, find the sentence in their docs that says so. Oracle’s says the opposite.
Pin the commit hash on every model download.
I’d confirm every customer-facing agent already tells people it is an AI. That duty applies now.
References:
Microsoft, What’s new in Agent 365, September 2026 (2026-09-30): https://techcommunity.microsoft.com/blog/agent-365-blog/whats-new-in-agent-365---september-2026/4560803
Microsoft Learn, AI gateway for Foundry agents (updated 2026-08-28): https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/ai-gateway
Microsoft Learn, Enable Fireworks models in Foundry (updated 2026-10-01): https://learn.microsoft.com/en-us/azure/foundry/how-to/fireworks/enable-fireworks-models
Oracle docs, Create an endpoint (OCI Generative AI): https://docs.oracle.com/en-us/iaas/Content/generative-ai/create-endpoint.htm
ServiceNow docs, Configure AI agent containment (updated 2026-09-10): https://www.servicenow.com/docs/r/intelligent-experiences/gov-sec-configure-ai-agent-containment.html
AWS docs, AgentCore Policy: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html
SailPoint, Chaos to control (2026-10-06): https://investor.sailpoint.com/news-releases/news-release-details/chaos-control-sailpoint-unlocks-secure-agentic-era-autonomous
Hugging Face, Agent intrusion technical timeline (2026-07-27): https://huggingface.co/blog/agent-intrusion-technical-timeline
OpenAI, Hugging Face Incident Technical Report (PDF, undated in text; file metadata 2026-08-26): https://cdn.openai.com/pdf/67869394-cb91-4c12-888c-5cbd85c7814c/OpenAI-Hugging-Face%20Incident-Technical-Report.pdf
CISA, Open Source Software: Security Principles and Practices (publication 2026-07-30), pp. 18-20: https://www.cisa.gov/sites/default/files/2026-08/open-source-software-security-principles-and-practices.pdf
Model Context Protocol, specification changelog (2026-07-28): https://modelcontextprotocol.io/specification/2026-07-28/changelog
Nasr, Carlini, Hayes et al. (OpenAI, Anthropic, Google DeepMind and others), The Attacker Moves Second: Stronger Adaptive Attacks Bypass Defenses Against LLM Jailbreaks and Prompt Injections, arXiv:2510.09023 (v1 2025-10-10): https://arxiv.org/abs/2510.09023
GovInfo, H.R. 10362 text: https://www.govinfo.gov/content/pkg/BILLS-119hr10362ih/xhtml/BILLS-119hr10362ih.html
OCC Bulletin 2026-13a, model risk management (2026-04-17): https://www.occ.treas.gov/news-issuances/bulletins/2026/bulletin-2026-13a.pdf
EUR-Lex, Regulation (EU) 2026/1744 (2026-07-08; in force 2026-07-27): https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng
This guide supersedes my May 2026 control-plane guide.