Restricting the Salesforce Model Context Protocol server to specific objects and fields

Define the boundary before configuring anything

An access boundary is easier to implement and verify when it is written as explicit rules. NIST describes attribute-based authorization as the evaluation of attributes of the subject, the object, the requested operation and, in some cases, environment conditions against policy. That structure maps cleanly onto an MCP tool call. The subject is the agent and its integration identity. The object is a CRM object or field. The operation is read or write. The context is the workflow or environment in which the call occurs.

For each agent use case, write down the objects and fields it may read, the objects and fields it may write, and the conditions that apply. If you plan to write rules by sensitivity or regulatory category, define the attribute first: a name, a set of allowed values, and an owner. NIST also notes that a subject should hold only the permissions of its active role. Treat each agent use case as one narrow role rather than reusing a broad one.

Apply the native Salesforce layers first

Native controls set the ceiling for what any tool call can reach. Configure them so the ceiling matches the boundary you wrote, then add further layers beneath it. The sequence below applies whichever MCP server implementation you use.

• Dedicated integration identity: Create one identity per use case. Do not reuse a shared administrative account or a named employee's credentials.
• Permission sets: Grant only the objects and operations in the boundary. Keep read and write access separate, and grant write only where the use case needs it.
• Field-level security: Review every sensitive field against that identity. Hide fields the use case does not need rather than relying on the agent to ignore them.
• Connected app and OAuth scopes: Request the narrowest scopes the server requires. Do not rely on scopes alone to express object and field limits.
• MCP server configuration: Expose only the tools the use case needs. Where the server supports object and field allow-lists, use them. Disable write tools for read-only agents.

What remains exposed after native controls

Native restrictions bound what the identity may access. They do not describe what a particular agent should request in a particular interaction. Three gaps are worth testing for.

The first is tool parameters. If a tool accepts an object name, a field list or a record filter as an argument, the agent chooses those values. An allowed identity can still be asked for a legitimate but unnecessary combination of objects and fields, and the model's choice can be influenced by instructions inside the content it reads.

The second is broad query tools. A tool that accepts a free-form query lets the agent construct the request, so the server's tool list says little about which objects and fields are actually touched. Prefer narrowly defined tools with fixed shapes where you can, and treat any open query tool as needing its own control.

The third is returned content. Permitted fields can still contain values you do not want in a model's context, such as identifiers or free-text notes holding sensitive details. Field permissions decide whether a field is visible, not whether a specific value should be passed on. NIST's guidance on content and structure filters is a useful precedent: it describes restricting which data structures and content pass through a boundary, including limits on field lengths.

Enforce policy on tool calls in the execution path

A runtime layer addresses the gaps above by evaluating each tool call as it happens. NIST's service-level authorization guidance describes permitting or denying operations on designated methods of a service. Applied to MCP, that means a decision on each tool and its arguments before the request reaches Salesforce, and a decision on the result before it reaches the model.

Trussed provides this layer. It enforces policy in the execution path on MCP server tool calls, with allow, redact and block decisions enforced at runtime, not reviewed after the fact. It can also rate limit and escalate a call for human approval. A policy can allow a call that targets approved objects and fields, redact a sensitive value in a result, or block a call that reaches outside the boundary. Enforcement operates on individual interactions and tool calls, and Trussed can be deployed self-managed in the customer cloud with configurable retention and data residency.

This layer complements the native controls and does not replace them. If the runtime layer is unavailable or misconfigured, the Salesforce permission model should still hold the ceiling.

Evidence, ownership and tradeoffs

An auditor will ask what the agent was permitted to do and what it did. NIST ties authorization to attributes and rules evaluated against policy, so retain the inputs and the outcome of each decision: agent identity, tool, target objects and fields, operation, the rule that applied, and whether the call was allowed, redacted or blocked. Trussed generates audit-ready evidence from enforcement itself, mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act and NIST, so the record reflects what was enforced rather than a reconstruction afterward.

Assign owners for the sensitivity classification of each object and field and for the policies built on it. Keep permission sets, attribute definitions and policy rules under change control, since policy is only as accurate as the attributes behind it.

A runtime layer adds a dependency in the call path. Decide in advance how it behaves on failure, and consider failing closed for write operations and for objects holding regulated data.