Blocking mass record deletes and updates through the Salesforce MCP server

Where mass-operation risk comes from

An MCP server exposes tools that an AI agent or coding assistant can call. Any tool that deletes or updates records is a potential mass-operation path. The risk is not the existence of the tool alone. It is the parameters that decide how many records one call touches.

When you review your server's tool inventory, classify each tool by operation (create, read, update, delete) and then read its input schema. Three parameter patterns matter most. A list of record IDs sets the count explicitly. A query or filter expression sets the count implicitly, so the real number depends on what the filter matches at execution time. A batch or bulk input multiplies the effect of a single call. A delete with a broad filter or a large batch is the highest-risk combination.

Native Salesforce permissions and API scoping decide whether the connected identity may delete or update a given object. They do not evaluate the intent or volume of each individual tool call. A mis-scoped prompt, or a manipulated one, can therefore produce a call that is fully permitted by the platform and still destructive. That gap is what runtime policy on the tool call is meant to close.

Layer one: least privilege on the Salesforce side

Start by shrinking what a runaway call can do. Run the MCP server under a dedicated integration identity rather than a shared or administrator account, so every action is attributable and the permission set can be tuned to the agent's actual job.

Grant only the operations the use case needs. If an agent summarizes accounts and drafts updates to a few fields, it does not need delete permission on any object. Where updates are required, limit them to specific objects and fields, and keep sensitive objects out of scope entirely unless there is a documented need. Review the sharing and API limit settings that apply to this identity as part of the same exercise.

Treat this layer as necessary but not sufficient. It defines the outer boundary. It cannot tell the difference between an update to five records and an update to fifty thousand when both are inside that boundary.

Layer two: define a mass-operation policy

A mass-operation policy states, in advance, which tool calls are acceptable. General access control models help here. Attribute-based access control, as NIST SP 800-162 describes it, evaluates attributes of the subject, the object, the requested operation and sometimes the environment against policy. A mass-operation policy maps naturally onto those attributes, although that mapping is a design choice and not a prescribed standard.

The thresholds are yours to set. No standard supplies a correct record count, so start from the largest legitimate batch your workflows perform and set limits just above it. Apply the following conditions in order of strictness.

• Operation type: Block delete tools for agent identities by default, following the long-standing practice of denying a specific application command, such as the HTTP delete example in archived NIST firewall guidance.
• Record count: Set a maximum per call for updates. Block calls above it, or escalate those in an intermediate band.
• Unbounded filters: Treat a filter-based delete or update with no explicit ID list or limit as high risk, because its count cannot be read from the request.
• Object sensitivity: Apply lower thresholds, or mandatory approval, to objects holding regulated or business-critical data.
• Call rate: Rate limit repeated calls so that many small updates cannot add up to a mass update.
• Approval escalation: Route calls that exceed thresholds but have a plausible business reason to a human approver before execution.

Enforcing policy in the execution path

A written policy only matters if something enforces it at the moment of the call. NIST SP 800-228 describes the general pattern for APIs: a policy enforcement point in the request path, such as a gateway, can control data flow, block traffic based on monitored data such as payload pattern or anomaly score, and apply rate limiting. The same placement logic applies to MCP, where the enforcement point sits between the agent and the server and inspects each tool call before it reaches Salesforce.

Trussed enforces policy in the execution path across agents, tools, MCP servers and coding assistants. The actions available are allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. In this use case, a delete call above the configured threshold is blocked at runtime, not reviewed after the fact. An update that exceeds the approval threshold is held for a person to approve. A call carrying sensitive values can be redacted before it proceeds.

Scope matters. This is enforcement at the level of the individual tool call. It is not a view of an entire business transaction across tasks and agents, so design thresholds around what a single call and its recent call history reveal.

Two-person control is a useful model for the approval path. NIST's enhanced security requirements draft describes dual authorization as reducing insider-threat risk. Extending it to agent actions is a design decision on your side, but the pattern fits: the agent proposes, a human authorizes.

Tradeoffs and rollout decisions

Several decisions deserve explicit sign-off before rollout. The first is failure behavior. If the enforcement point is unavailable, a fail-open design keeps agents working but removes the control, while fail-closed protects data at the cost of availability. For destructive tools, fail-closed is the more defensible default.

The second is count determination. A filter-based call does not state how many records it will touch. You can require explicit ID lists for destructive tools, require a bounded limit parameter, or block unbounded filters outright. Pick the approach before you set thresholds, because every threshold depends on it.

The third is approval load. If thresholds are too low, reviewers face a stream of requests and begin approving by habit. Begin in a monitoring posture, review the recorded decisions to see what legitimate traffic looks like, then tighten thresholds. Keep a containment option ready as well: NIST SP 800-228 describes blocking an individual user or credential as an effective response during an ongoing incident.

Finally, document the agent connection path, including its usage and connection restrictions, as you would for any other remote access route. A written policy for that path makes later audit review much simpler.