Salesforce MCP Security Checklist: Identity, Access, Audit

Salesforce MCP Security Checklist: Identity, Access, Audit

Securing a Salesforce MCP connection comes down to four questions. Who is connecting, what are they allowed to reach, which actions need a person to confirm them, and could you reconstruct afterwards exactly what happened. Everything else in this article is detail underneath those four questions.

The connection itself is not the hard part. Salesforce Hosted MCP Servers are a managed endpoint, and enabling one is a Setup task. The hard part is that you have just given an external AI client a standing, discoverable list of things it can do inside your system of record, and the client decides which of those things to call. That is a governance problem before it is a technical one.

This checklist assumes you are connecting a client such as Claude, ChatGPT or Cursor to a Salesforce Hosted MCP Server, and that you need to defend the design in a security review.

What MCP actually changes in your threat model

A conventional integration has a fixed contract. It calls the same endpoints in the same order every time, and you can reason about its blast radius by reading the code.

MCP inverts that. The server publishes a set of tools with names and descriptions, and a language model chooses which ones to call and with what arguments, based on what a user typed. You are no longer reviewing a call sequence. You are reviewing a capability surface and trusting that the surface is small enough that any combination of calls is acceptable.

Three risks follow from that, and they are worth naming explicitly in a review document. The first is over-broad exposure, where a server is activated with more tools than the use case needs. The second is unintended writes, where a model interprets an ambiguous request as an instruction to change or delete a record. The third is attribution loss, where activity cannot be traced back to a named person because the connection was set up as a shared service account.

Salesforce's platform design closes the third risk for you by default. The first two remain your configuration responsibility, and that distinction between what the platform enforces and what you configure is the one most security reviews get wrong.

Layer one: authentication and client identity

Salesforce documents the MCP security model as three layers, authentication, authorization and permission controls, with logging alongside them for audit. Each layer depends on the one before it, and you should not try to patch a gap in one layer somewhere else.

Authentication is handled declaratively through an external client app rather than code you write. Salesforce supports only the authorization code flow for Hosted MCP Servers, which means a person authenticates in a browser and their individual Salesforce user account is tied to the MCP session.

One external client app per AI client

Create a dedicated external client app for each MCP client. One for Claude, one for ChatGPT, one for Cursor. Salesforce recommends this explicitly, and the reason is practical rather than theoretical. When you later need to answer which client made a request, revoke access for one tool without disrupting the others, or investigate an unusual access pattern, a shared app leaves you with no way to separate them.

There is no service account, and that is deliberate

Salesforce does not offer a principal-user or integration-user pattern for Hosted MCP Servers, and describes that pattern as an anti-pattern to avoid. Machine-to-machine flows are not on the roadmap. Every MCP transaction traces to a named user, and PKCE is required on the OAuth exchange.

If your architecture proposal depends on a shared identity so that a workflow can run unattended overnight, MCP through the hosted servers is the wrong mechanism for that workflow. That is a design constraint to surface early, not a limitation to engineer around.

Layer two: authorization and least privilege

Authorization is where most of your configuration effort belongs, and where most reviews find gaps.

Start with scope. Salesforce released a dedicated mcp_api scope specifically so that MCP access does not require granting the broad api scope, which would open the full platform API surface including REST, Tooling and Metadata. Granting api when mcp_api would do is the single most common over-permission in an MCP setup.

Then restrict who can connect. By default, any user in your org can authenticate against the external client app. An app policy lets you limit connection to users with a specific profile or permission set, which turns MCP access into something you provision deliberately rather than something everyone inherits. IP restrictions can be layered on top under App Authorization, and trusted ranges can be set org-wide or per profile.

Then shorten the leash. Refresh tokens default to a one-year lifetime. Reducing that in production limits the window in which a stolen token is useful. Salesforce also provides a revocation path through the OAuth Usage page in Setup, where you can revoke individual tokens or run a bulk revoke. Confirm that path works before you need it in an incident, not during one.

Finally, activate only what you intend to expose. All MCP servers are inactive by default. That secure-by-default posture only holds if nobody activates servers speculatively during a proof of concept and forgets to deactivate them.

Layer three: permissions, and choosing the right server

Every MCP tool call runs with the permissions of the user who authorized the connection. Object-level access, field-level security and record sharing rules all apply at runtime, exactly as they do in Lightning. If a user cannot do something in the UI, they cannot do it through MCP either.

That inheritance is genuinely useful, but it is not sufficient on its own, because most users have write access to plenty of records they would never intentionally change. Permission inheritance limits reach. It does not limit intent.

This is why server selection matters more than it first appears. Salesforce ships pre-configured SObject servers with different capability profiles, including read-only, create-and-update-without-delete, delete-only, and full access. Selecting a narrower server limits what any agent can do without writing a line of code.

Where you need tighter control than server selection provides, Salesforce documents two further options. A Named Query defines exactly which objects and fields a tool returns, which is the right approach when an agent needs one slice of the data model rather than the full SOQL surface. An Apex class with an @InvocableMethod annotation exposed as a custom tool gives you programmatic control for conditional access, transformation or multi-step logic.

One anti-pattern is worth calling out. Building a custom proxy around the Salesforce REST APIs instead of using the hosted server bypasses the platform's security controls, removes request-level telemetry and creates a maintenance burden that grows as the API surface changes. If a team proposes this, ask what specifically the hosted server cannot do.

Tool definitions are hints, not enforcement

MCP tools carry annotations that describe how they behave, including readOnlyHint, destructiveHint, idempotentHint and openWorldHint. Well-behaved clients use these to decide whether to auto-execute a call or prompt the user for confirmation. Platform tools ship with accurate values, and Salesforce advises setting them explicitly on custom tools backed by Flow, Apex or REST, because the specification defaults assume a tool is potentially destructive.

The critical governance point is the one Salesforce states plainly: annotations are hints, not enforcement, and not every client reads or respects them. They complement access control and human review rather than replacing either.

Treat tool metadata as a usability feature and a documentation surface, not a control. If your only protection against an unwanted delete is that the tool is marked destructive, you do not have a control. You have a suggestion addressed to software you do not operate.

Tool descriptions deserve the same scepticism. A description is prompt input that shapes model behaviour, which means changes to it change behaviour. Put tool definitions under version control and treat a description change as a change requiring review, not a copy edit.

Where human approval belongs

Permission inheritance and scoped servers reduce the size of the mistake. Human review is what stops a specific mistake from becoming a record change.

The useful design question is not whether to add review but where. Reviewing everything produces reviewers who approve without reading, which is worse than no checkpoint because it manufactures an audit trail of decisions nobody actually made. We covered that trade-off in depth in our guide to Salesforce AI approval workflows, and the same reasoning applies to MCP.

A workable default is to auto-execute reads, require explicit confirmation for creates and updates on customer-facing objects, and not expose deletion tools at all. If a deletion genuinely needs to happen through an agent, have the agent create a task or case for a person to action rather than performing the delete itself.

Monitoring and audit

Because every call runs in the authenticated user's context, MCP activity appears in standard Salesforce API logs with full user attribution. Salesforce logs MCP server activity through Event Monitoring, and you can isolate that traffic in the Event Log File Browser by filtering the API Total Usage event type for rows where the client category matches SALESFORCE_HOSTED_MCP.

Those logs tell you which operations ran on behalf of each user, which objects were touched, and when. Salesforce recommends reviewing them for error status codes and for unexpected patterns in user or client IP fields, either of which can indicate a misconfiguration or a genuine security issue.

Two gaps are worth planning for. Platform logs capture the call, not the conversation that produced it, so the reasoning behind an action lives in the client rather than the org. And log review is only a control if somebody owns it on a schedule. Assign that owner by name before go-live.

The production checklist

Use this as the review artefact. Every line needs an owner and a piece of evidence, not just a yes.

Incident response and change control

Two lines in that table carry more weight than the others.

The incident runbook should specify exactly who can revoke tokens, deactivate a server and disable an external client app, and how they do it out of hours. Bulk token revocation and server deactivation are both fast operations, but only if the person on call already knows where they live.

Change control matters because the risk profile of an MCP deployment moves without anyone deploying anything. A model update at the client vendor changes how tools are selected. A permission set change alters what an existing connection can reach. A new server activated for one team's pilot widens the surface for everyone with access. Re-run this checklist on a fixed cadence and after any change to permissions, tool definitions or active servers.

A worked example

A support operations team wants agents to answer questions about open cases inside their AI client of choice, and to log a follow-up task when a case needs one.

The narrow version of that design activates the read-only SObject server for case and contact lookups, exposes one custom tool backed by a Flow that creates a follow-up task with a fixed field set, grants mcp_api scope only, and restricts connection to a permission set assigned to the eleven people on the support desk. Task creation is a low-reversibility action on an internal object, so it runs without a confirmation prompt. No update or delete tool is exposed. Log review is weekly and owned by the support operations lead.

The broad version of that same request activates the full-access SObject server because it was simpler, grants api scope because that was the example in a tutorial, and leaves connection open to the whole org. Both versions demo identically. Only one of them survives a security review.

Where ConvoPro fits

ConvoPro is a practical AI workflow layer for Salesforce. Salesforce remains the system of record, and ConvoPro adds the workspace and governed action layer around it.

For teams weighing a direct MCP connection against a managed workflow layer, the honest framing is that they solve different problems. A direct MCP connection gives skilled users open-ended access to a tool surface inside a client they already use, which is powerful and requires exactly the discipline this checklist describes. A workflow layer is the better fit when the same bounded task runs repeatedly, needs consistent structure, and must end in a reviewed record change rather than an open-ended conversation.

ConvoPro accesses only what the authorized user can access in Salesforce, and adds control at the connector and tool level so administrators decide which sources and actions are available. Review-before-create means a proposed record change is reviewable before it becomes a record. You can see how the workspace, admin controls and review points fit together on the ConvoPro product page, and the control points relevant to an admin or security review are documented on the security and governance page.

If you are already running MCP connections, our earlier piece on connecting Claude to Salesforce with MCP covers the governance gap that opens between a working connection and a defensible one.

Next step

Take one workflow you are considering putting behind MCP, and run it through the sixteen lines above with a named owner against each. If more than three lines have no evidence behind them, the workflow is not ready for production regardless of how well the demo went.

If you want a second opinion on the design, you can request the ConvoPro security overview or an architecture review for a single workflow. Current plans and packaging are on the pricing page.

Frequently asked questions

Does MCP bypass the Salesforce security model?

No. Every MCP tool call runs with the permissions of the authenticated user, including object access, field-level security and sharing rules. If a user cannot perform an action in Lightning, they cannot perform it through MCP. What MCP changes is which combinations of permitted actions get attempted, not which actions are permitted.

Can we use an integration user for MCP?

Not for Salesforce Hosted MCP Servers. Only the authorization code flow is supported, a person must authenticate in a browser, and Salesforce describes the shared service account pattern as an anti-pattern to avoid. Machine-to-machine flows are not currently planned.

How do we separate MCP traffic from other API activity in logs?

Filter the API Total Usage event type in the Event Log File Browser for rows where the API client category matches SALESFORCE_HOSTED_MCP. That surfaces the calling user, the objects touched, timestamps and status codes.

Do tool annotations prevent an agent from deleting records?

No. Annotations are behavioural hints that clients may or may not respect. They improve the experience in clients that read them, but the enforceable controls are server selection, permissions and not exposing destructive tools in the first place.

Should we start with a read-only server?

For most first deployments, yes. Read access covers question answering, summarisation and reporting, which is where the early value usually sits, and it removes write risk entirely while you learn how your users actually phrase requests.

How does this relate to a broader Salesforce AI security review?

MCP is one connection type within a wider picture that also covers prompt grounding, agent actions and model providers. Our Salesforce AI security checklist for admins and CIOs covers the workflow-level controls that apply regardless of which connection mechanism you use, and the NIST AI Risk Management Framework is a reasonable structure for documenting risk and controls without committing to compliance language a workflow design cannot deliver on its own.