September 6, 2026

Governing Third-Party MCP Servers in Agentforce: The Controls You Have Today

Winter '27 promises MCP risk scoring. Here are the controls that ship today: Agentforce Registry, tool allowlisting, Gateway policies, and their limits.

TL;DR

Registering a third-party MCP (Model Context Protocol) server is the moment you hand an outside vendor a working seat inside your org. Setup, then Agentforce, then Agentforce Registry is where that happens, and it needs only the Manage AI Agents permission plus whatever your agent type requires.
MCP for Agentforce supports two authentication options: none, or OAuth 2.0 client credentials. Authorization code, JWT bearer, PKCE, CIMD and DCR are all unsupported, and user-level authentication is not supported at all. Every call leaves as one shared service identity.
That is the exact inverse of traffic coming the other way. Salesforce Hosted MCP Servers, which let Claude or ChatGPT act inside your org, use per-user OAuth 2.0 with PKCE and respect each user's field-level security and sharing. Outbound to a vendor, you lose that.
Your sharpest control is the per-tool allowlist at registration. Salesforce will warn you when a tool description contains bidirectional or decorative Unicode, invisible characters, or mixed scripts, and calls those tools high risk. That warning is the platform's tool-poisoning check, and it asks you to do the review by hand.
Agentforce Gateway policies (Setup, then Policies) have an MCP Servers tab and can attach to servers manually or by matching rule. This is the closest thing you have to a per-server off switch.
Winter '27 ships API Catalog as the central inventory for APIs and MCP servers. The MCP risk scores in Security Center advertised in the Release in a Box deck are not in the Winter '27 Security, Identity, and Privacy release notes as published on 7 September 2026.
One documented bug matters more than the rest: when a registered server is out of sync or unreachable, the Registrations list still shows it as connected. Do not treat that column as monitoring.

What You'll Learn

The four routes a third-party MCP server can take into your org, and which of them an admin sees
Exactly what Salesforce creates on your behalf when you register a server, and what that means for least privilege
Why the authentication ceiling on outbound MCP calls breaks user attribution, and what to do instead
How to run the tool allowlist as a review gate rather than a checkbox
Where Agentforce Gateway policies sit, and what they can and cannot reach
The documented limits, bugs and billing behaviour that decide whether this is safe to turn on

The Problem

Salesforce's Winter '27 Release in a Box deck has a Platform: Salesforce Guardian page, and the headline feature on it is MCP Risk Scores in Security Center. The pitch is direct: third-party MCP servers expose agent workflows to tool poisoning and rug-pull attacks, so Salesforce will scan every server at registration, monitor it afterwards, and surface a Low, Medium or High score that admins can act on.

It is a good pitch. It is also not in the release notes. The Winter '27 Security, Identity, and Privacy notes, checked on 7 September 2026, cover Backup and Recover Next, domains, external client app migration, named credentials with custom CA certificates, the new Security Health Review viewer, Data Detect for Data 360 objects, trusted URLs for Chrome extensions and custom root certificates. There is no mention of MCP risk scores, and none of Observability Center or Security Mesh connectors either. Security Center is a separately licensed product with its own release cadence, so absence from the core notes is not proof that nothing is coming. It does mean you cannot plan around it, and it does mean the deck and the notes are describing different quarters.

The thing that did ship got less attention and matters more. The Winter '27 Platform notes introduce API Catalog, which centralises services including MCP servers, activates Salesforce hosted servers for use with Agentforce and external clients, and registers external MCP servers including MuleSoft ones. Registration is live and the risk scoring is not, and that gap is where your org sits right now.

The uncomfortable part is how little friction registration involves. A user with Manage AI Agents can point Agentforce at any reachable HTTPS endpoint, choose no authentication, allowlist a set of tools, and have those tools appear as agent actions minutes later. There is no approval workflow, no vendor assessment step, and no risk score. The only control is an admin reading tool descriptions.

Common questions this article answers:

What actually happens in my org when someone registers a third-party MCP server?
Can I tell which user's request triggered a call to an external vendor's server?
How do I stop a registered MCP server without breaking every agent that uses it?
Which of the Winter '27 agent governance features can I use today?

Quick Answer

Third-party MCP servers enter your org through Setup, then Agentforce, then Agentforce Registry, or through Setup, then API Catalog, then MCP Servers, and the two views show the same registrations. Registering one requires Manage AI Agents plus your agent type's permissions, in Enterprise, Performance, Unlimited or Developer Edition. The server must be reachable and must use the Streamable HTTP transport; HTTP+SSE is unsupported. Authentication is limited to none or OAuth 2.0 client credentials, so there is no user-level authentication and no per-user attribution on outbound calls. When you create the registration, Salesforce validates the connection with a ping and creates a named credential, an external credential, and a permission set named "ServerName Permission Set" that it assigns to you; delete that permission set or remove it from your user and you lose the ability to manage the server. You then allowlist individual tools, and Salesforce flags any tool whose description contains bidirectional or decorative Unicode, invisible characters, or mixed scripts as high risk and asks you to review the text in a plain editor before allowing it. Allowlisted tools become agent actions in Agentforce Assets under the Actions tab, named "Tool Name ServerName". Ongoing control lives in Agentforce Gateway policies under Setup, then Policies, which has an MCP Servers tab and attaches policies either by matching criteria or by manual selection. Treat registration as a vendor assurance decision, not a configuration step, because it is the only point where a human reviews what the vendor can do.

Two directions, two very different security models

Most of the confusion in this area comes from collapsing two opposite flows into one word. They deserve separate names in your head.

Inbound: an AI client acts inside Salesforce. This is Salesforce Hosted MCP Servers, which Salesforce's developer blog announced as generally available in April 2026. Claude, ChatGPT, Cursor or a custom agent connects to your org through an External Client App. Salesforce's documentation is explicit that this path gives you per-user authentication so that agent actions respect each user's existing Salesforce permissions, using OAuth 2.0 with PKCE, with tools that respect field-level security and sharing rules. Servers are configured and activated deliberately in API Catalog rather than being on by default.

Outbound: your Agentforce agent calls a vendor's server. This is MCP for Agentforce. Your agent reaches out to a third party's tools, and the vendor's server does whatever it does with the request. Here the documented ceiling is much lower.

The asymmetry is worth laying out side by side:

	Inbound (Hosted MCP Servers)	Outbound (MCP for Agentforce)
Auth model	Per-user OAuth 2.0 with PKCE	None, or OAuth 2.0 client credentials
User attribution	Every action runs as the authenticated user	Not supported
Salesforce permissions	CRUD, FLS and sharing enforced per user	Not applicable; the vendor decides
Unsupported flows	n/a	Authorization code, JWT bearer, PKCE, CIMD, DCR
Granularity	Per user, per permission set	Per registered server, per allowlisted tool

Salesforce's own considerations page is blunt about the consequence: user-level authentication is not supported, and use cases requiring individual user IDs or personalised responses do not work. The example it gives is that you cannot use MCP for Agentforce to give an individual user a refund, but you can use it to get all of your customers' invoices.

Read with a security hat on, the supported use case is the bulk one.

The four ways a server gets registered

API Catalog documents four sources, and they do not all pass through the same hands.

Source and type	Who creates it	Where it becomes visible
Salesforce, custom	You, in API Catalog	API Catalog, optionally added to Agentforce Registry
Salesforce, standard	Salesforce, automatically	Appears in your catalog on its own
External, MuleSoft	A MuleSoft admin in Anypoint Platform, then synced	All synced servers in API Catalog; only active ones in Agentforce Registry
External, manual	Anyone with Manage AI Agents, in API Catalog or Agentforce Registry, or by installing an AgentExchange package	Both views

Three of those rows should change how you monitor this.

Standard Salesforce servers appear without anyone doing anything. They are inert until activated, but their presence in your catalog is not a decision your team made. Review the list rather than assuming everything in it was put there deliberately.

MuleSoft servers are created outside Salesforce entirely. If your integration team runs Anypoint, the person deciding which servers exist is not the Salesforce admin, and the sync makes them discoverable in Salesforce afterwards. That is a legitimate division of labour and a real gap in your change control if nobody has mapped it.

AgentExchange packages are the least examined of the lot. Installing a package registers servers whose connections are then configured in Named Credentials. A package install is a familiar action that most orgs already have a review process for, but that process was written for Apex and objects, not for outbound agent tooling.

To see everything in one place: from Setup, enter API Catalog in Quick Find, select MCP Servers, then switch between the Salesforce Servers and External Servers tabs. For headless inventory, API Catalog Connect REST API exposes the same data, which is what you want if you are folding this into an existing audit script like the one in Audit Your Agentforce Footprint.

What registration actually creates

Walk the flow once and note the side effects, because they are the part that outlives the person who clicked through it.

From Setup, enter Agentforce in Quick Find, select Agentforce Registry, click New. You can register from scratch or browse pre-packaged servers from AgentExchange. You supply a server name, description and URL, then choose an authentication method: no authentication, or OAuth 2.0 client credentials. Choosing OAuth means supplying an identity provider URL, an optional comma-separated scope list, a client ID and a client secret.

Click Create and Continue and three things happen that are worth knowing about:

Salesforce pings the server to validate the connection. That is a live outbound call from your org to a URL a user just typed. If your organisation restricts egress or requires vendor endpoints to be reviewed first, this is the moment it happens, and it happens before anyone has approved anything.
Salesforce creates a named credential, an external credential, and a permission set. The permission set is named "ServerName Permission Set" and is automatically assigned to you. You do not need to assign it to other users or to the agent's user record for the agent to use the tools. It exists to let you manage the server.
That permission set becomes a single point of failure for administration. Salesforce's documentation warns directly: if you delete the permission set associated with a registered server, or remove it from your user record, you will not be able to edit or manage the server, including allowlisting or removing tools. An org doing routine permission set cleanup can lock itself out of managing an active vendor connection while leaving the connection running.

The credentials Salesforce creates for you are ordinary named credentials and external credentials, so they stay visible, deployable and auditable through the paths you already use. That helps, because it is the hook for folding MCP servers into whatever review you already run over named credentials. If you have not done that pass recently, the legacy named credentials migration post covers the inventory query.

The tool allowlist is the actual control

After the connection is created, you select which of the server's tools your agents may use. This is the only step in the whole flow where a human evaluates capability rather than connectivity, and Salesforce's guidance around it is unusually direct.

The documentation says to allow only tools you trust, and to carefully review tool names and descriptions before allowlisting so you understand their function and scope. Then it describes a specific warning:

If you see a warning that one or more tool descriptions contain bidirectional or decorative Unicode characters, invisible characters, or multiple languages or scripts, these tools are considered high risk. Before allowlisting, copy and paste the tool descriptions into a text editor and manually review them.

That warning is doing more work than its placement suggests. Tool descriptions are read by the reasoning engine, not just by you. A description containing invisible characters or right-to-left override marks can render one way in the Salesforce UI and mean something else to the model, which is the mechanism behind published MCP tool-poisoning research. Salesforce has built the detector but not the response, which is why the instruction ends with "copy and paste into a text editor".

Practical version of that instruction, because "review it manually" is easy to skip:

Paste each description into an editor that shows invisible characters. On a Mac, pbpaste | hexdump -C | head -40 is enough to see whether the bytes match what the screen showed you.
Compare the character count you see with the character count the file has. A description that renders as 80 characters and contains 140 is telling you something.
Read the description as if it were an instruction to your agent, because it is one. If it says anything about ignoring prior instructions, fetching additional context, or including data it does not need, that is the finding.
Allowlist the minimum set of tools that make the use case work. Every tool you allow becomes an agent action that the reasoning engine can choose to call.

The tools you allow appear in Setup under Agentforce Assets, on the Actions tab, named "Tool Name ServerName" with their own icon. That naming pattern is your inventory hook: anything matching it came from an MCP server rather than from a flow or Apex class.

The mechanism here is the same one behind the ForcedLeak research, where content the org treated as data was read by the agent as instruction. If that framing is new, Post-ForcedLeak: Hardening Agentforce Against Prompt Injection covers it properly. The lesson transfers exactly: the agent's own instructions are not the control that matters.

Agentforce Gateway policies

Ongoing control lives somewhere most admins have not looked. From Setup, enter Policies in Quick Find and select Policies. The Agentforce Gateway Policies page has an APIs tab and an MCP Servers tab.

Open a policy, click Open in Policy Builder, and select Target Entities from the sidebar. Protection attaches two ways:

Matching criteria, which apply automatically to any server meeting the conditions. This is the one to invest in, because it covers servers registered after you wrote the policy. A rule that catches everything registered without authentication, for example, does not depend on anyone remembering it exists.
Manual selection, where you use the dropdown next to a specific API connection or MCP server to change or remove its protection.

Save Policy commits the change. During registration, any manually available policies can be applied to the new server, and rule-based policies apply automatically when the server meets their conditions.

This is the closest control you have to the Agent Kill Switch that the Release in a Box deck describes. Worth being precise about the difference: that feature is a MuleSoft one, on the MuleSoft Omni Gateway, and it is a separate product and a separate licence. If you do not run MuleSoft, Agentforce Gateway policies plus deleting the registration is the whole of your emergency response, which is a reason to work out the deletion sequence before you need it.

The order of operations for removing a server

Deleting a registration in a hurry breaks agents, and Salesforce documents the sequence to avoid that. Changes to a server registration, or to the server itself, can break the MCP tool actions inside an agent. Before making any change, including deleting the registration:

Remove the associated actions from your agent.
Delete the associated agent actions from the asset library.
Delete the server registration.

To bring the server back, register it again and add the new MCP tool actions to the agent. Re-registering produces new actions rather than restoring the previous ones.

Write that sequence down somewhere your on-call person will find it. In an incident, the instinct is to delete the registration first, and that is the step that leaves broken actions wired into a live agent.

The limits that decide whether this is safe to enable

Salesforce's considerations page is one of the more honest pieces of documentation in the platform. The items below are the ones with security or operational consequences.

The connected status is not a health check. When an MCP server is out of sync or unavailable, the Registrations list view and the server record page currently show the server as connected. Salesforce says a fix is on the way. Until then, that column tells you a registration exists, not that it works, so do not build alerting on it.

Registration metadata is not packaged. Salesforce supports packaging and deploying agents that contain MCP tool actions, but the MCP server registration metadata itself is not packaged, so the tool actions do not work out of the box in the target org. You register the servers and allowlist the tools in each environment before deploying, then swap the agent's actions for the new ones from that org's asset library. Inconvenient for release management, and good for security in a way nobody advertised: an MCP server approved in a sandbox does not silently follow the package into production.

Transport and protocol are fixed. Streamable HTTP only. HTTP+SSE and other transports are unsupported, as are MCP prompts, resources and server apps, so only tools work. That narrows the attack surface, and it means a vendor advertising rich MCP support may deliver very little through this path.

Timeouts are short. The MCP client timeout is 60 seconds and the Atlas reasoning engine timeout is 120 seconds across multiple server calls. A vendor server that is merely slow reads as a failure, and a failure mid-conversation is a user-visible one.

It is metered. Agent actions referencing MCP tools bill at the same rate as any other agent action, with usage reporting in Digital Wallet. A chatty agent calling a third-party tool in a loop is a cost incident as well as a data one, and Digital Wallet is where you will see it first.

Legacy Builder agents are excluded. MCP for Agentforce is not supported for agents created in the legacy Agentforce Builder, because of data model and Atlas reasoning engine differences. If your pilot agent predates the current builder, this does not apply to it at all.

Schema support is shallow. Agentforce Builder handles primitive values and shallow field access well. Top-level objects, top-level object properties and top-level arrays of objects are supported; nested properties, arrays of objects and dynamic object payloads are not supported end to end. Tools returning complex JSON are more likely to fail your use case than to endanger it, so test the response shape early.

A review gate you can actually run

None of the above is a process on its own. The following is, and it fits in a change ticket.

Before registration:

Who is the vendor, and does an existing vendor assurance record cover this endpoint? The registration ping is an outbound call to their infrastructure from inside your org.
Does the server use OAuth 2.0 client credentials? If the answer is no authentication, that decision needs a named approver behind it.
Which specific tools does the use case need? Name them in the ticket before anyone opens Setup.
Which environment first? Salesforce recommends starting in a sandbox with a new agent, then recreating in production once the agent performs reliably. Since registrations do not package, you were going to do it twice anyway.

At registration:

Record the auto-created named credential, external credential and permission set names in the ticket.
Review every allowlisted tool description in a plain text editor, and record who did it.
Confirm which Gateway policies applied, whether by rule or manually.

After registration:

Confirm the new actions in Agentforce Assets match the allowlist exactly, with no extras.
Check the agent user's permissions have not been widened to accommodate the new tools. The agent user is still the blast radius, as covered in Agentforce Agent User Least Privilege.
Add the server to whatever runs your recurring audit, and do not rely on the connected column.
Set a review date. Rug-pull attacks work precisely because a server that was safe at registration is not the same server six months later, and Salesforce is not currently rescanning it for you.

One more item for your Winter '27 planning: the Agentforce release notes record that Agentforce Platform is enabled by default for new orgs created in Winter '27, with existing orgs following on a rolling basis starting September 2026. Enabling the platform is not the same as enabling agents or MCP servers, but it does mean the surface arrives in orgs whose admins did not ask for it. Pair this with the enforcement work in Salesforce Winter '27 Security Readiness.

Frequently Asked Questions

Q: Can I see which user caused my agent to call a third-party MCP server?

A: Not at the vendor's end. MCP for Agentforce does not support user-level authentication, so outbound calls carry a single client-credentials identity rather than the individual user. Inside Salesforce you can still reconstruct the conversation from Agentforce Session Tracing, which lands in Data 360 objects governed by data space permission sets and either attribute-based or role-based access policies. That gives you the session, the agent and the action. It does not give the vendor anything to log about the individual, and it does not let the vendor apply per-user authorisation. If your use case requires either, MCP for Agentforce is the wrong mechanism for it today.

Q: Is "MCP Risk Scores in Security Center" real, and should I plan for it?

A: It is a named feature in Salesforce's Winter '27 Release in a Box deck, on the Platform: Salesforce Guardian page, described as scanning every server at registration and continuously afterwards to surface Low, Medium or High risk scores. It does not appear in the Winter '27 Security, Identity, and Privacy release notes as published on 7 September 2026, and Security Center is a separately licensed add-on with its own release cadence. Treat it as announced rather than available: do not build a control around it, and do check Security Center's own release notes rather than the core ones when you go looking for it.

Q: What is the fastest way to stop a third-party MCP server that is misbehaving?

A: Agentforce Gateway policies under Setup, then Policies, on the MCP Servers tab, using Policy Builder to remove protection or change the target entity. If you need the server gone entirely, follow the documented order: remove the actions from the agent, delete those actions from the asset library, then delete the registration. Deleting the registration first leaves broken actions wired into a live agent. Note also that the registration list showing a server as connected proves nothing, because Salesforce documents that it shows connected even when the server is unavailable or out of sync.

Q: Does registering an MCP server give the vendor access to my Salesforce data?

A: Not directly, and the distinction matters. Your agent calls their tools and sends whatever arguments the reasoning engine decides to send, so the exposure is defined by which tools you allowlisted and what your agent passes to them, not by a standing grant over your objects. That is different from Salesforce Hosted MCP Servers, where an external client authenticates into your org per user and reads data under that user's field-level security and sharing. Outbound, your controls are the allowlist and the agent's instructions; inbound, your controls are the platform's.

Q: We install agents from AgentExchange. Does that route skip any of this?

A: It skips the part where a human types a URL, not the part where servers get registered. Installing a package can bring MCP server registrations with it, with connections configured through Named Credentials, and the servers become visible in both API Catalog and Agentforce Registry. Most orgs' package review processes were written for Apex, objects and permission sets. Extend yours to ask which MCP servers and tools a package registers, because that is now part of what a package can add.

Key Takeaways

Registration is a vendor decision, not a config step. Manage AI Agents is all it takes, there is no approval workflow, and the validation ping reaches the vendor before anyone has assessed them.
The auth ceiling is the headline risk. No authentication or OAuth 2.0 client credentials only, with user-level authentication unsupported, means outbound MCP traffic has no user attribution and no per-user authorisation at the far end.
The tool allowlist is your real control. Salesforce detects the Unicode tricks behind tool poisoning and then asks you to do the review by hand, so build that review into the change ticket rather than the moment.
Gateway policies with matching criteria beat manual selection, because they catch servers registered after you wrote the policy.
The connected status is documented as unreliable. Do not build monitoring on it.
What the deck promises and what the release notes ship are different quarters. API Catalog is real now; MCP risk scoring is not in the Winter '27 security notes.

What's Next?

Recommended reading:

Action items:

Open Setup, then API Catalog, then MCP Servers, and read both the Salesforce Servers and External Servers tabs. Do this before you decide whether you have a problem, because standard servers appear without anyone adding them and MuleSoft servers arrive by sync.
For every external registration you find, record the authentication method and the allowlisted tools, and re-read each tool description in a plain text editor.
Write one Agentforce Gateway policy with matching criteria rather than manual selection, so that servers registered next quarter are covered by it.
Add the removal sequence (agent actions, then asset library, then registration) to your incident runbook.
Extend your package review checklist to ask which MCP servers and tools an AgentExchange install registers.

Resources & References

Written by the team at CloudCounsel — builders of Paywren and Mehfil.

Responses

Checking your session.

Loading responses.