Enterprise AI agent governance before the vendors ship

Salesforce previewed the Trusted Enterprise AI Harness at Dreamforce on 10 September 2026, and with it an AI Control Plane: one place to see, manage and control agents and AI across the enterprise, including agents that are not Salesforce's. The diagnosis is right. Enterprise AI agent governance is the problem most companies have and almost none have named, because agents arrived one department at a time and nobody was ever asked to approve the set.

The catch is in the availability line. Many of the foundational technologies are available today, but the new capabilities and the unified experience are planned to begin rolling out in early fiscal FY28 — which, as SiliconANGLE notes, starts in February 2027. That is not far away. It is also not now, and "begin rolling out" is doing real work in that sentence.

What was actually announced

Salesforce's announcement describes six capabilities, and they are worth reading as a checklist rather than a product, because they are a reasonable decomposition of the problem whoever solves it.

• Trusted Context — data, metadata, semantics, knowledge and memory, so AI shares an understanding of the customer and the business.
• Trusted Agency — reasoning, planning, state, memory, collaboration and orchestration, with deterministic controls over them.
• Trusted Action — secure connection to applications, APIs, workflows and business processes so agents can actually execute.
• Trusted Governance — policies and processes with lineage, quality guardrails and controls.
• Trusted Security — identity, permissions, privacy and runtime security governing what AI can reach and what agents may do.
• Trusted Models — routing between models on accuracy, performance and cost.

The AI Control Plane sits above them and covers discovery, identity and policy, lifecycle management, performance evaluation and cost control, across both Salesforce and third-party AI. Rohan Kumar, Salesforce's president and chief platform and engineering officer, framed the bet plainly: the agentic enterprise will not be defined by which model a company chooses, and what differentiates an enterprise is the trusted, proprietary context it brings to that intelligence and its ability to securely turn that context into action.

We think that framing is correct, and we would say so even from a vendor we did not use. The model is not the differentiator. The context and the controls around it are.

Five months is long enough to matter

Here is the practical problem with waiting. In our experience, a mid-market company with a CRM, an ERP and a support desk has already accumulated agents in all three, plus one or two departmental tools somebody expensed. Each has its own permissions model. Each writes to systems of record. Very few organisations can answer, today, three questions about that set: which agents exist, what each is permitted to touch, and who approved it.

Those questions do not need a control plane to answer. They need somebody to ask them. And the honest reading of a February 2027 rollout is that a unified console reaches general availability some time after that, which means the governance you have in the second half of 2027 is mostly the governance you build yourself between now and then.

There is a second consideration for anyone not standardised on Salesforce. A control plane offered by an application vendor is, understandably, best where that vendor's data already is. If your agents live across a Salesforce CRM and a non-Salesforce ERP, "including third-party AI" is a claim to test against your actual stack during a pilot rather than to design around in advance.

The controls that need no vendor at all

Four of the five things that most reduce agent risk are ordinary engineering discipline, and every one of them is available this quarter.

An inventory. One list of every agent running against a system of record: what it is, who owns it, which systems it reads, which it writes, and what it is allowed to do without a human. Most of the value of a control plane is the list. You can keep the list in a spreadsheet and get most of the benefit now.

One identity per agent. Not a shared service account, not a human's credentials borrowed because it was quicker. If an agent cannot be told apart from a person in your audit log, you have no governance, whatever tooling you buy later. This is the single change we would make first.

Scoped credentials with an expiry. An agent that summarises support tickets does not need write access to billing. The permission set should be the narrowest one that lets it finish its job, and it should expire, because a permission granted for a pilot in March is still granted in November. The reasoning is the same as for sandbox allowlists: decide what is reachable before deciding what is forbidden.

An action log you can actually query. Not model traces — business actions. Which record changed, which agent changed it, under whose authority, at what time. When something goes wrong the question will be "what did it touch", and an answer that requires a vendor's dashboard export is an answer you will not have at the moment you need it.

Prompts, tools and policies in version control. An agent's behaviour is defined by its instructions and its tool definitions, and those are code whether or not they live in a code repository. Keeping them reviewable and diffable is the same argument we made for holding agent knowledge in git, and it is what makes "who changed this agent and why" a question with an answer.

The fifth item — a single console spanning every vendor's agents — is the one you genuinely cannot build yourself at reasonable cost, and it is the one Salesforce is selling. That is a fair division of labour. It is just not a reason to defer the other four.

One more reason not to wait: the four controls above are the same four an auditor, an insurer or an enterprise customer's security questionnaire will ask about, and none of those parties accept a roadmap as an answer. We have watched a mid-market supplier lose six weeks of a sales cycle to a single question about which systems an agent could write to, which nobody could answer from the tooling they had. The inventory would have taken an afternoon.

Evaluation is the part nobody schedules

One capability on Salesforce's list deserves separating out, because it is where we see governance programmes quietly fail. Performance evaluation is listed as a control plane function, and in practice it is the function that decides whether any of the rest matters.

An agent that is governed but not evaluated is an agent you have made safe to run and have no idea whether to keep. Worse, without a regression suite you cannot change it: every prompt edit becomes a gamble, so the agent freezes at whatever quality it launched with. That is the argument for scoring the trajectory rather than the final answer, and it is worth starting before any console exists, because the test cases are yours regardless of which vendor eventually runs them.

Enterprise AI agent governance: where to start this month

If this lands on your desk as a board question, the useful answer is a sequence rather than a platform decision.

1. Count the agents. Ask each department what it is running, including anything bought on a card. The number is almost always higher than the CIO's estimate, and the exercise itself is the most valuable hour in this list.
2. Give each one its own identity and revoke the shared accounts. Two weeks of work, and it converts every later question from guesswork into a query.
3. Write down what each agent may do unattended. One line each. The ones nobody can write a line for are the ones to pause.
4. Put the prompts and tool definitions under review. Same pull request process as application code.
5. Pick twenty real tasks and score them. Before you need to prove anything to anyone.
6. Then evaluate control planes, with the inventory in hand, which is also the only way to run a useful pilot.

None of this is an argument against buying the harness when it arrives. It is an argument that the inventory, the identities and the evaluation suite are yours in every scenario, portable to whichever vendor wins, and required before any console can tell you anything useful. The same logic applies when the question is whether to buy the agent runtime itself, which we worked through for the OpenAI Agents API: what travels between vendors is your context, your tools and your tests.

If you want help taking that inventory — or making it survive contact with a CRM and an ERP that were never designed to be governed together — that is the kind of work we do before the platform decision, not after it.