MuleSoft Agent Fabric: governing the agents you didn't build

The first agent is a project. The fiftieth is a governance problem. And by the time an enterprise has fifty agents, they were not all built on the same platform — there’s the Agentforce service agent, the Amazon Bedrock agent finance stood up on their own, a Copilot Studio bot someone in ops shipped, and an MCP server a developer wired into a workflow last quarter. Each one can read data, call APIs, and take actions. None of them can see the others, and nobody has a single list of what’s running, what it can touch, or what it costs.

That’s the problem MuleSoft Agent Fabric is built for, and it’s worth being precise about the scope, because it’s easy to confuse with governance you may already have. We’ve written before about governing an Agentforce agent fleet — the sprawl inside Salesforce, where the answer is Agentforce’s own controls. Agent Fabric is the layer above that: a control plane for agents built anywhere, on any vendor’s stack, that unifies discovery, governance, orchestration, and observability across all of them. Different problem, different tool, and mixing them up is the first mistake.

This post is the honest map: what Agent Fabric is, the four capabilities that actually matter, the availability reality (some of this is GA, some is a stated roadmap), and where it’s the right call versus where you’re better off waiting.

Why single-vendor governance runs out

Salesforce’s own framing for the problem is “rogue agents,” and while that’s marketing language, the underlying failure is real. An agent your Agentforce admin never provisioned — sitting in another cloud, holding its own credentials, calling APIs on a schedule — is invisible to the Einstein Trust Layer, invisible to your Data 360 access controls, and invisible to whoever is supposed to know what’s touching customer data. It’s the same shape as shadow IT a decade ago, except the shadow asset can now act on its own.

The single-vendor tools don’t reach it by design. Agentforce governs Agentforce agents. Bedrock’s controls govern Bedrock agents. Copilot Studio governs its own. Each is competent inside its fence and blind past it. What’s missing is the thing every mature discipline eventually grows — a registry, a policy layer, and an audit trail that spans the whole estate rather than one product. That’s the gap Agent Fabric is trying to fill, and the reason it lives in MuleSoft rather than in Agentforce: MuleSoft is Salesforce’s integration and API-governance layer, and a cross-vendor agent is, structurally, an integration problem.

The four pieces that matter

Agent Fabric is a bundle, and the marketing surface is broad. Cut through it and there are four capabilities that carry the actual weight. Learn these four and you understand the product.

1. Discovery: you can’t govern what you can’t see

The foundation is an inventory, and the mechanism is Agent Scanners — automated discovery that finds agents across environments and catalogs them into a registry instead of relying on someone to fill in a spreadsheet. Salesforce brought the scanners for the major platforms to general availability in January 2026, covering Agentforce, Amazon Bedrock, Google Cloud’s Vertex AI, and Microsoft Copilot Studio, and has been extending coverage to MCP servers and additional platforms since.

This is the unglamorous but load-bearing part. Every downstream control — policy, identity, cost — depends on the estate being fully enumerated, and the single hardest thing about agent governance in practice is that nobody has the complete list. Automated discovery is what turns “we think there are about forty agents” into an inventory you can actually govern. There’s also an interoperability angle here: Salesforce has partnered on agent-naming and verification standards (an Agent Name Service, à la DNS for agents) so an agent can be identified and trusted across organizational boundaries, not just found inside your own tenant.

2. Trusted Agent Identity: the permission problem, done properly

This is the piece that should decide whether you take Agent Fabric seriously, because it addresses the failure mode that turns an agent from a productivity tool into a breach. The default, lazy way to give an agent access is a service account with broad standing permissions — and an agent holding a broad-access credential is exactly the least-privilege violation that a prompt injection turns into an incident.

Trusted Agent Identity replaces that with an On-Behalf-Of (OBO) model: the agent acts with the specific user’s permissions for that task, not a broad shared account, and authorization is granted just-in-time rather than held standing. The result is that every action an agent takes is attributable to a real principal and scoped to what that principal is actually allowed to do — which is both the security posture you want (zero-trust, per-action) and the audit trail compliance will eventually demand. Salesforce has also described a mobile authorization step for high-risk actions, so a human approves the consequential move from their phone before the agent proceeds. If you read only one section of the Agent Fabric documentation, read this one; identity propagation is the hard part of multi-agent systems and the part most homegrown setups get wrong.

3. AI Gateway: one place to see cost, usage, and policy

Every agent call is a model call, and every model call costs money and moves data — often to a third-party LLM outside Salesforce’s Trust Layer. The AI Gateway is the single control point in front of that traffic: it governs the models your agents call, standardizes token management, and gives you centralized visibility of token usage, costs, and data flows across a multi-LLM, multi-agent stack. Salesforce has made an LLM Governance capability in the Gateway generally available for exactly this — the third-party-model spend and data-flow visibility that’s otherwise scattered across four vendors’ billing consoles.

The reason this matters is the reason Flex Credit math matters inside Agentforce, only worse: when agents span vendors, the cost surface fragments across every provider’s pricing model, and nobody owns the total. A gateway that meters the whole thing is the difference between a defensible AI budget and a quarterly surprise. It’s also a policy chokepoint — a single place to enforce what data is allowed to leave for which model, rather than trusting each agent to behave.

4. Agent Broker: orchestration, with a determinism dial

The fourth piece is Agent Broker — the layer that coordinates actions across agents and lets you build networks where one agent hands off to another. On its own that’s multi-agent orchestration, which Agentforce already does inside its own walls; the Broker’s job is to do it across vendors, using open protocols so an Agentforce agent and a Bedrock agent can be composed into one workflow.

The feature worth watching here is Guided Determinism: you define the fixed hand-off rules — the parts of the workflow that must happen in a set order, every time — and let the LLM handle the reasoning in between the fixed points. That’s the right shape for regulated work, and it’s the same principle we’ve argued for repeatedly: deterministic control where correctness is non-negotiable, model reasoning where flexibility pays. It’s also the least-mature part of the bundle. On Salesforce’s stated timeline, deterministic orchestration in Agent Broker entered beta around April 2026 with general availability targeted mid-2026 — so treat the Broker as the piece to pilot, not the piece to bet a production workflow on today. Verify its status against the current release notes before you design around it.

The protocol layer underneath

None of this works without interoperability, and Agent Fabric leans on two open protocols you should already know. MCP — the Model Context Protocol — is how agents connect to tools and data sources, and Agent Fabric includes an MCP Bridge so MCP servers are first-class citizens in the registry and governance layer rather than an ungoverned side door. A2A — the Agent2Agent protocol — is how agents built by different vendors talk to each other, which is what makes cross-vendor orchestration possible at all.

The practical implication: Agent Fabric is a bet on the open-protocol future, not a proprietary walled garden. That’s the correct bet — an agent-governance layer that only governed Salesforce agents would be pointless — but it means your leverage depends on the other vendors’ protocol support being real, not just announced. Before you assume an agent is governable through the Fabric, confirm it actually speaks A2A/MCP and that the scanner for its platform is GA.

Where it fits — and where it doesn’t

Be clear-eyed about the boundary, the same way we are about where Salesforce fits and doesn’t in any agent build.

Agent Fabric is a control plane, not a runtime. It does not run your Bedrock agent or your Copilot Studio bot; those keep running where they were built. What it adds is the layer that discovers them, gives them scoped identities, meters their spend, and lets them be composed and observed together. If your entire agent estate is Agentforce, you don’t need it yet — Agentforce’s native governance and Command Center observability already cover a single-vendor fleet, and adding MuleSoft Agent Fabric on top is cost and complexity you can’t justify.

The threshold where it starts to earn its place is specific and worth naming:

• You have agents on more than one platform, and no single tool can list them all.
• Agents are holding broad-access service accounts, and you need per-user, per-action attribution before an auditor or an incident forces the issue.
• Third-party LLM spend is real and fragmented, and nobody owns the total across vendors.
• You need to compose agents across vendors into one governed workflow, not just run them side by side.

If none of those is true, Agent Fabric is a solution to a problem you don’t have yet. If two or more are true, it’s the layer you were about to build yourself, badly. And there’s a licensing reality to weigh: this is MuleSoft, a separately-licensed platform, so the buying decision is a real integration-platform commitment, not a toggle inside your existing Agentforce spend. Price it as what it is.

The takeaway

Agent Fabric is the answer to a problem most enterprises don’t have on day one and can’t avoid by year two: agents multiplying across vendors, each competent in its own fence and invisible past it. The four pieces that matter are discovery (Agent Scanners, so you have a real inventory), identity (Trusted Agent Identity’s OBO model, so every action is scoped and attributable), cost and policy (the AI Gateway, so spend and data flows have one owner), and orchestration (Agent Broker with Guided Determinism, so cross-vendor workflows keep their fixed rules). Discovery, identity, and the gateway are the mature, GA parts you can plan around today; the Broker’s deterministic orchestration is the roadmap piece to pilot and verify against current release notes.

The discipline is the same one that separates a working agent program from a demo: govern the estate, not the instance. Single-vendor controls govern the instance. Agent Fabric is the bet that, once agents are everywhere, the estate is what you actually have to manage.

Understanding the basics

What is MuleSoft Agent Fabric?

Agent Fabric is a control plane from Salesforce, delivered through MuleSoft, for discovering, governing, orchestrating, and observing AI agents across your whole enterprise — regardless of which platform each agent was built on. It sits above single-vendor tools like Agentforce, Amazon Bedrock, Vertex AI, and Microsoft Copilot Studio, giving you one registry, one identity model, one cost-and-policy gateway, and one orchestration layer for agents that would otherwise each be governed (or ungoverned) in isolation. It runs on open protocols — MCP for tools and A2A for agent-to-agent communication — rather than a proprietary walled garden.

How is Agent Fabric different from Agentforce governance?

Agentforce governs Agentforce agents: topics, actions, guardrails, and the Trust Layer, all inside Salesforce. That’s the right tool for a single-vendor fleet. Agent Fabric governs agents built anywhere — the Bedrock agent, the Copilot Studio bot, the standalone MCP server — that Agentforce’s controls can’t see. If your entire estate is Agentforce, you use Agentforce governance and don’t need the Fabric. You reach for Agent Fabric once agents span multiple platforms and no single vendor’s controls can enumerate, secure, and meter them all.

What is Trusted Agent Identity?

Trusted Agent Identity is Agent Fabric’s identity model for agents. Instead of an agent acting through a broad-access service account, it acts On-Behalf-Of a specific user, with that user’s permissions, and authorization is granted just-in-time rather than held as standing access. For high-risk actions, Salesforce has described a mobile authorization step so a human approves before the agent proceeds. The effect is per-action, per-user attribution and a zero-trust posture — every action is scoped to what the real principal is allowed to do, and the audit trail shows who each action was actually performed for.

Is MuleSoft Agent Fabric generally available?

Parts of it. Salesforce brought the Agent Scanners for major platforms (Agentforce, Amazon Bedrock, Vertex AI, Copilot Studio) to general availability in January 2026, along with the AI Gateway’s LLM Governance capability, the MCP Bridge, and Trusted Agent Identity. Deterministic orchestration in Agent Broker — the Guided Determinism capability — entered beta later, on a stated timeline targeting general availability around the middle of 2026. Because the rollout is staged and the beta features move, verify the current status of any capability you plan to depend on against Salesforce’s live release notes before you architect around it.

---

Standing up agents on more than one platform and realizing nobody owns the estate? Talk to us — drawing the boundary between what Agentforce governs natively and where a cross-vendor control plane like Agent Fabric earns its place is exactly the kind of architecture call that decides whether an agent program scales or sprawls. Our integration practice lives in this MuleSoft layer.