How to Block Restricted Objects and Fields from Salesforce MCP
Sales and success teams want Salesforce in Claude, ChatGPT, and Cursor for account research and pipeline reviews. Leadership wants agents kept away from a compensation object, strategic-account notes, and personal fields on custom objects, even though some reps can see them. Until both requirements can be met, the Salesforce MCP server stays switched off.
This guide covers where Salesforce’s own controls stop and how a custom rule engine on MCP Manager’s gateway can block or redact named objects and fields for AI agents only, while the person keeps their Salesforce access unchanged.
Key Takeaways
- Salesforce Hosted MCP Servers run every tool call with the authenticated user’s permissions, so an AI agent can query every object and field its user can see.
- Salesforce’s native controls apply to the user, not to the agent acting for that user.
- Feature provisioning and other tool-level controls cannot separate objects, because Salesforce’s query tools are generic and the object name sits in the query string, not the tool name.
- An MCP gateway rule closes the gap with two legs: a request-leg rule blocks queries that name a restricted object, and a response-leg rule deletes or redacts restricted fields and nested records before results reach the client.
- This is a custom rule engine, a webhook your team writes, hosts, and maintains.
Where Salesforce User Permissions Stop Working for Agents
Salesforce states that every hosted MCP tool call runs with the same permissions as the user who authorized the connection: object-level CRUD, field-level security, and sharing rules all apply. That is the right floor, and it is also the ceiling. Every object a rep can open in Lightning is an object their agent can query.
A rep opens one Opportunity on purpose. An agent answering “prep me for the Acme QBR” runs SOQL and SOSL across every object in scope and passes the results to a model. Free-text fields are untrusted content the model processes, so an instruction planted in a record can steer an agent that has write tools or other servers connected.
The native fixes both cost the person something. Removing an object from a permission set removes it from the rep’s own work. Deactivating the server removes Salesforce from every AI workflow.
What Salesforce’s Native MCP Controls Cover
Salesforce’s hosted MCP servers became generally available in April 2026 for Enterprise Edition orgs and above, and they ship with real controls. Start with these controls. Scope what your users can reach in Salesforce itself, then add an MCP gateway rule for the part Salesforce can’t express. A gateway rule backs up source-side scoping and does not replace it.
The native controls fall into three groups:
- Server activation: all hosted servers are inactive by default. The read-only
sobject-readsserver exposes query and read tools without create, update, or delete. - Client access: Salesforce’s security guidance covers restricting the External Client App to users with specific profiles or permission sets, IP restrictions, shorter refresh token lifetimes, and the dedicated
mcp_apiOAuth scope, which avoids granting full API access. - Custom servers: admins can curate custom servers per persona, combining standard tools with Flows, Apex actions, and Named Queries.
Each of these controls answers one of two questions: who may connect, and which tools exist. None of them answers a third: what a tool may touch when an agent calls it.
- Same identity: the agent runs as the user, so object permissions, field-level security, and sharing rules return the same data to both. Salesforce has no setting that lets a user read
Compensation__c(a custom object holding pay data, in this example) while their agent cannot. - No agent-only account: hosted servers support only the authorization code flow, and Salesforce calls a shared integration user an anti-pattern. Every session stays tied to a person.
- Generic query tools:
soqlQueryandfindreach every object the user can see. Narrower tools built on Named Queries or Apex fix this at the source, at the cost of one maintained tool per use case.
If purpose-built tools cover your use cases, they are the strongest boundary. When agents need the generic query tools, what is missing is a checkpoint that sees each query and each result and can apply a policy that differs for the agent.
An MCP gateway is that checkpoint. It sits in the path of every tool call, so a rule can read the SOQL before it reaches Salesforce and the records before they reach the model, without touching the user’s Salesforce permissions.
Curious how an MCP gateway fits into your AI rollout? Book a demo with MCP Manager and see how rules, identity, and logs work together.
Where a Gateway Rule Steps In on a Salesforce Tool Call
MCP Manager’s gateway sits between the AI client and the Salesforce hosted MCP server and brokers each user’s own Salesforce identity. A gateway rule hands each tools/call to your custom rule engine on the request leg, the response leg, or both. The engine receives the JSON-RPC body plus metadata such as serverGuid, toolName, userEmail, and direction, and answers with pass, block, modify, or error.
The Object Lives in the Query String
The 2026-07-28 MCP spec requires the Mcp-Method and Mcp-Name headers on Streamable HTTP requests, so MCP gateways can route and authorize on the tool name without parsing the body. For Salesforce, that header reads soqlQuery whether the query targets Account or Compensation__c. The object name sits inside the query argument, and in the result it can appear nested under a parent record. Object- and field-level policy therefore requires inspecting the JSON-RPC body on both legs.
Know the Tool Surface
The sobject-reads reference lists tools that reach objects in different ways. soqlQuery and find take SOQL and SOSL strings, listRecentSobjectRecords and getRelatedRecords name the object or relationship path as arguments, and getObjectSchema returns object and field metadata. Custom and write-capable servers add more tools, so build the rule from the live tool list of the server actually connected.
Step-by-Step Guide to Blocking Salesforce Objects and Fields
The setup runs from a list of restricted objects to a tested rule. Apply the rules before the gateway is provisioned to anyone beyond a pilot team, because a gateway without rules applies no content-level policy.
Step 1: Decide What Level You Are Blocking
Before any rule is written, the policy needs a scope. A restriction can apply to a whole object, to single fields on an object, or to individual records. Each scope changes where the rule acts and what it has to parse.
- Object level: a whole object is off limits, such as a custom object that holds pay data. The request leg blocks queries that name it, and the response leg strips it from nested results.
- Field level: agents can read Account, but not individual fields such as annual revenue or an internal notes field. The response leg deletes or redacts those fields.
- Record level: agents can read Opportunities, except those flagged as strategic. The response leg filters on a field value, so a field that reliably marks those records is required.
Collect API names, not labels. Object Manager in Setup shows each API name, and custom objects and fields end in __c. Sensitive data buried in free-text fields such as case comments is a different problem. A field list can’t find it, because the field is allowed and only some of its content is not. That takes content detection, such as a Presidio or regex rule layered on top.
Step 2: Connect the Salesforce Hosted MCP Server
Register an External Client App with PKCE and JWT-based access tokens enabled, activate the servers you need, and add the server URL in MCP Manager, as described in the Connect Salesforce guide. Detection lands on OAuth with client pre-registration, so you supply the app’s Consumer Key and Consumer Secret, and each user approves the Salesforce consent screen. Salesforce’s own setup documentation is the reference for OAuth scopes and server URLs, and it is worth checking again before each rollout.
Gateway rules only apply to traffic that passes through the gateway, so work through the MCP Enterprise Lockdown Checklist.
Step 3: Create the Gateway and Capture Real Payloads
Create a gateway for the team that will use Salesforce, assign the Salesforce server, and choose per-user identity so every call stays attributed to the person. Then trim the tool surface with feature provisioning:
- Start read-only. Connect
sobject-readsbefore any write-capable server. - Hide tools agents don’t need. If
getObjectSchemaisn’t required, hiding it stops agents from learning the field structure of restricted objects. - Block prompts and resources unless needed. Gateway rules inspect
tools/calltraffic only.
Step 4: Set Up the Engine Skeleton
Every custom engine shares the same contract. Before writing any Salesforce logic, the webhook needs four things:
- Authentication first: verify the shared secret from the engine’s headers before parsing anything.
- A pass for everything else: the engine sees every
tools/callon the gateway, so anyserverGuidortoolNameit wasn’t written for passes immediately. - Useful comments: every verdict can carry a
comment, which lands in the logs. Name the tool and object, so the logs show which branch fired. - A correct modify response: a modify verdict must be a complete JSON-RPC response, with
metadata.requestIdechoed as theid. A mismatch leaves the client waiting until it times out.
Here is the full guide on how to build the engine: Building a Custom Rule Engine. It covers the webhook contract, TypeScript types, and a working Express example.
Step 5: Build the Request-Leg Rule
The request rule fires before a call reaches Salesforce. It reads body.params.arguments and blocks calls that name a restricted object:
listRecentSobjectRecordsandgetRelatedRecordscarry the object or relationship path as a plain argument.soqlQueryandfindcarry it inside a query string. Match on theFROMclause, subqueries, and SOSLRETURNINGclauses. Use a real SOQL parser rather than a regex, because relationship paths, aliases, and nested subqueries defeat simple patterns.- A call that should name an object but can’t be parsed is blocked.
On write-capable servers, this leg also enforces per-object read-only access.
Step 6: Build the Response-Leg Rule
Some restricted data never appears in the query. A relationship query on Account can pull child Opportunities, getRelatedRecords can traverse into a restricted child object, and polymorphic lookups such as an activity’s What field can return a related record’s name. The response rule catches these.
The field-stripping recipe shows the pattern, using ssn, creditScore, and compensation as examples. It offers two strategies:
- Delete: the key disappears, and the model never knows the field existed.
- Redact: the key stays with a placeholder. The model can see the value was withheld, which stops it from assuming the data is missing and retrying the call another way. Redaction does confirm the field exists.
Salesforce results are rarely flat, so the response-leg rule needs to handle more than the recipe shows. Check each of these against captured payloads:
- Nested records: child records and parent relationship objects can carry restricted fields below the top level.
- Counts and pagination: any field that reports a result total should match the filtered list.
- Schema output: restricted objects and fields should disappear from
getObjectSchemaresults. - Unparseable results: a result from a covered tool that cannot be parsed is blocked, not passed.
Step 7: Put the Engine in the Path
Host the engine on a public HTTPS endpoint that returns HTTP 200 for every verdict and handles retries idempotently. Register it under Rule Engines with the Custom provider and run the Test action as a smoke test. Then add a rule on the Salesforce gateway with the hook set to Both, so one request rule and one response rule are created. Keep the failure mode at Block.
Troubleshooting tip: A registered engine filters nothing until a rule on that gateway references it.
Step 8: Test with a Pilot Team
Following the safe rollout sequence, provision the gateway to two or three admins only and exercise each path:
- Query a restricted object directly with
soqlQuery. - Query a permitted parent with a subquery into the restricted child.
- Run a SOSL search whose
RETURNINGclause includes the restricted object. - Read an Account and confirm restricted fields are deleted or redacted.
Confirm each verdict in the logs, where blocks appear as policy_enforced_abort and rewrites as policy_enforced_mutation. Widen access only after every path behaves as intended.
Build Your Own vs. Managed
A Salesforce object and field rule is code your team owns. Building it includes a webhook with a SOQL and SOSL parser and the four verdicts, a monitored public endpoint, tests against captured payloads, and updates when Salesforce adds tools or servers.
The build is only the first of three jobs.
- Keeping coverage current: Salesforce can change a connected server’s tool list, and admins can edit a custom server’s tools at any time. Allowlist the tools your rule was written for in feature provisioning, so anything new stays hidden until someone has checked it against the parser. An engineer on your team should own that check, since Salesforce admins are often not the people who maintain web services.
- Passing a security review: the engine reads every query and every result that agents exchange with Salesforce. InfoSec will review it like any service that handles that data. Test cases, captured payloads, and log entries are the evidence, and leaving header forwarding off keeps user access tokens out of its reach.
- Running it in production: the engine sits in the path of every call on its gateway. With the default Block failure mode, an outage pauses Salesforce MCP for everyone on that gateway, so it needs monitoring and an on-call owner.
A coding agent can draft most of the engine from the MCP Manager docs for agents, and the custom rule engine tutorial covers registration. Review the result like any other code before it enforces policy.
There is no managed Salesforce engine today, unlike the managed Google Drive Folder Blocker. The engine is only a detection method on a gateway rule, so it can be replaced later without rebuilding the gateway.
Real-World Scenarios for Blocking Salesforce Objects
The same few prompts run all day in a Salesforce rollout. These show where each one goes wrong without a rule, and which rule fixes it.
- Prepping for a customer call: a rep asks, “Find everything related to Acme Corp: contacts, opportunities, and open cases.” The agent pulls the Account with its related records, including an internal
Margin_Notes__cfield the rep can see but leadership does not want in a prompt. A response-leg rule redacts that field, so the agent says the value was withheld instead of guessing. - Reviewing the pipeline: a sales manager asks, “What are the top 10 opportunities by amount in the pipeline?” Some Opportunities are flagged as confidential deals. A response-leg rule removes the flagged records, and the manager still sees them in Salesforce.
- Summarizing the week’s cases: a support lead asks for a summary of cases opened in the last 7 days. The agent also reaches a custom object holding legal escalations. An object rule blocks queries that name it, and a Presidio rule set to Replace turns emails and phone numbers in the remaining case text into typed tags such as
<EMAIL_ADDRESS>. - Cleaning up deal data: an ops user asks the agent to bulk-update close dates. On a write-capable server, a request-leg rule blocks updates to Opportunity while reads pass, so the agent can analyze the data without changing it.
The sales and finance teams can share one Salesforce server and still see different data. Each gets its own gateway, and the finance gateway simply omits the rule that blocks the billing object.
Salesforce MCP Without the Exposure Risk
Every object a rep can open is also an object their agent can query. Salesforce’s controls set the floor, and a custom rule engine on MCP Manager’s gateway adds the agent-only boundary that floor can’t express: named objects blocked, named fields deleted or redacted, and different policies per team.
If your organization is holding back Salesforce MCP because of a few objects and fields, book a demo with MCP Manager and scope the rule that unblocks it.
FAQ
Which Salesforce editions support the hosted MCP server?
Salesforce’s GA announcement ties Hosted MCP Servers to Enterprise Edition and above. Confirm current licensing with your Salesforce account team. MCP Manager also governs a self-built Salesforce MCP server, as long as it serves Streamable HTTP and uses one of the supported authentication methods.
Does a gateway rule replace Salesforce field-level security?
No. Field-level security, object permissions, and sharing rules still apply to every call. The gateway rule adds an agent-specific layer on top, and it can only narrow what the user’s permissions already return.
Can feature provisioning block an object without code?
No. Feature provisioning hides or allows tools, and the Salesforce tools are generic across objects. It does reduce what the rule must cover, for example by hiding getObjectSchema or write tools.
Why not run agents as a dedicated integration user?
Hosted MCP servers don’t support it: each session is tied to the user who authorized. On a self-built server, an integration user would replace each person’s sharing rules with one shared set of permissions and attribute every call to the same account.
What happens if my custom rule engine goes down?
Custom engine rules default to the Block failure mode. If the engine is unreachable, slow, or returns an invalid response, the call is blocked and no unfiltered data reaches the client.
Can I combine object blocking with PII redaction on the same gateway?
Yes. Rules run in order within each detection hook, and a block stops processing, so place the object rule before PII rules.
