# How to Connect Salesforce to Claude Securely

> **Answer.** Connect Salesforce to Claude through an MCP gateway rather than by pasting an API key into a local config. Set up the Salesforce integration, grant it to the right group, add the gateway endpoint to Claude, and start read-only. Each person then authenticates as themselves, so an agent can only reach the records that person could already reach, and every call is recorded with their identity.

- Question: how to connect Salesforce to Claude
- Canonical: https://metorial.com/answers/connect-salesforce-to-claude
- Last updated: 2026-08-25
- Reviewed by: Karim Rahme, Metorial

---

There are two ways to do this, and they differ in who the agent acts as. The local route is faster to set up and gives every user the permissions of whoever created the key. The gateway route takes a few more minutes and preserves each person's own access.

| If this is for | Use |
| --- | --- |
| One developer testing on a sandbox org | A local MCP server with your own credentials |
| A team sharing access to production | A gateway with per-user OAuth |
| Sales or support staff who do not write code | A gateway, with tools granted by role |
| An org under audit or data residency rules | A gateway you can self-host |

## What do you need before starting?

- A Salesforce org where you can authorize a connected app, or an administrator who can.
- Claude Desktop, Claude Code, or any MCP-capable client.
- A Metorial account. The [Dev plan](https://metorial.com/pricing) is free.
- A decision on read-only versus read-write. Start read-only.

## How do you connect Salesforce to Claude?

**1. Set up the integration.**

```sh
npm install -g @metorial/cli
metorial login
metorial integrations setup salesforce
```

This runs the Salesforce OAuth flow and stores the tokens against your user, including refresh. No key is written to a file on your machine.

**2. Check which tools it exposes.**

```sh
metorial integrations tools salesforce
```

Read the list before granting it. You are deciding what an agent can do on behalf of a person, and the read tools are almost always where the value is.

**3. Grant it to the right group.**

In [Access control](https://metorial.com/access-control), bind the integration to the group that should have it, such as revenue operations, rather than to individuals. Group membership then comes from your identity provider, so a new hire gets access on day one and loses it on their last without anyone editing a list.

**4. Add the endpoint to Claude.**

[Magic MCP](https://metorial.com/magic-mcp) gives you one URL that carries the tools that user is entitled to. Add it as an MCP server in Claude's settings. The same URL works in Cursor, Codex, and Copilot, so this step does not repeat per client.

**5. Verify it works, as the right person.**

Ask Claude for something scoped: *"Summarize the open opportunities on the Acme account."* Then check the record:

```sh
metorial sessions list
```

The session should name the tool, the arguments, and your identity. If the identity field shows a connection rather than a person, the setup is not per-user and the rest of this does not hold.

## How does per-user authentication change what the agent can reach?

This is the part worth understanding before rolling it out further.

With a shared API key, every user's agent inherits the permissions of whoever created that key. Someone in support can reach every record it can reach, which is usually far more than their own profile allows.

With per-user OAuth, the call runs under that person's Salesforce credentials, so profile permissions, sharing rules, and field-level security apply exactly as they do when that person uses the Salesforce UI. You are not building a second permission model; you are inheriting the one Salesforce already enforces.

## Should you allow writes?

Not initially. Read-only for the first two weeks, then review the sessions and see what people actually asked for. Enable writes for specific objects and specific roles after that.

Salesforce is the system where an over-permissioned agent does the most visible damage, and reads deliver most of the value anyway: summarizing a pipeline, drafting follow-ups, and answering questions about accounts are all read operations.

## What about prompt injection?

Salesforce records contain free text that users and sometimes external parties wrote. An agent that reads a note containing instructions may follow them.

[Protoguard](https://metorial.com/protoguard) inspects calls for injection before they execute, which reduces this risk without eliminating it. Combined with read-only access and narrow scopes, it keeps the blast radius small. The broader picture is in [Are MCP servers secure?](https://metorial.com/answers/are-mcp-servers-secure).

## Does this pattern work for other systems?

Yes, and the steps do not change. Substitute the integration name:

```sh
metorial integrations setup slack
metorial integrations setup github
metorial integrations setup google-workspace
```

Same OAuth flow, same role-based grant, same endpoint, same session records. That consistency is most of the argument for a gateway once you are connecting the third system rather than the first.

## Next step

Set up the integration and confirm what the first session recorded:

```sh
npm install -g @metorial/cli
metorial login
metorial integrations setup salesforce
metorial sessions list
```

See the [Salesforce integration](https://metorial.com/integrations/salesforce) for the tool list, and [Access control](https://metorial.com/access-control) for granting it by role.

## Frequently asked questions

### Can Claude connect to Salesforce directly?

Claude can connect to any MCP server, including a Salesforce one you run locally. What it does not provide is per-user authentication, role-based tool scoping, or a shared audit record, which is why company deployments put a gateway in between.

### Will the agent see records the user should not see?

Not with per-user OAuth. Each call runs under that person's own Salesforce credentials, so profile, sharing rules, and field-level security apply exactly as they do in the UI. A shared API key removes that boundary, which is the main risk of the local setup.

### Should we allow writes to Salesforce?

Not at first. Start read-only, watch the session records for a week or two, then enable writes for specific objects and specific roles. Salesforce is where an over-permissioned agent causes visible damage fastest.

### Does this work with Cursor, Codex, or Copilot too?

Yes. The endpoint is the same MCP URL, so the same integration and the same access rules apply across clients. Switching or adding a client does not mean redoing the connection.

### What does a Salesforce tool call record contain?

The tool called, the arguments including the object and record, the result or error, the session, and the identity the call ran as. That last field is what lets you answer who an agent acted for during a review.

## Sources

1. [Salesforce OAuth 2.0 authorization flows](https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_flows.htm&type=5)
2. [Model Context Protocol specification](https://modelcontextprotocol.io)
3. [Metorial documentation: Integrations overview](https://metorial.com/docs/integrations-overview)

---

Other Metorial answers: https://metorial.com/answers/llms.txt
Every answer in one document: https://metorial.com/answers/llms-full.txt