Capping Bulk SOQL Exports Through the Salesforce MCP Server

Where the bulk-export risk sits in an MCP architecture

When an AI agent or coding assistant queries Salesforce through an MCP server, the SOQL query becomes a tool call. A single call can return a large record set, and a rapid series of calls can return far more. Conventional exports and reports usually carry their own volume controls. A tool call made by an agent often does not pass through those controls, so the MCP path can become an exfiltration route that nobody sized for volume.

There are four risk points. The first is result size: how many rows and how many bytes one call can return. The second is field scope: whether sensitive customer fields come back in results the agent only needed for a narrow task. The third is query shape: whether the agent can write free-form queries with no meaningful filter. The fourth is call frequency: whether many small calls, each within a cap, add up to a large export.

None of these is solved by instructing the agent in a prompt. An instruction can be ignored, misread or overridden by injected content. The control has to sit where the call is made and apply the same decision regardless of what the model intended.

Three enforcement points and what each can do

Limits can be applied in three places. Each has a different strength, and none replaces the others.

• Source system permissions and limits: Bound what the connecting identity is allowed to read. They are the outer boundary, but they decide visibility, not how much permitted data a given agent session pulls over time.
• MCP server configuration: Controls which tools exist and how queries are constructed. Useful for narrowing the surface. Capabilities vary by server, so confirm what yours enforces before relying on it.
• Policy enforcement in the execution path: Evaluates each tool call and its result between agent and server. Suited to row caps, redaction, per-identity counters and escalation. Scope is the individual call, not the wider business process.

Define a layered cap strategy

Start with a per-call row cap and a response size cap. NIST guidance on API protection recommends payload limits that enforce maximum request and response sizes, and its illustrative examples include 1,000 records per request and a 2 MB request body. Those figures are examples, not requirements. Set yours from the real size and sensitivity of the objects agents need, and expect to tune them.

Next, restrict fields. NIST describes the authorization check as asking whether data should be visible to external callers. Apply the same question to agents. Decide per tool which fields an agent task needs, then redact or block the rest, keeping that decision separate from rate limits. A call that stays under the row cap can still be a leak if every row includes sensitive fields.

Then control query shape. NIST recommends limiting the queries that can be executed, favouring approved or predefined queries, and capping outbound calls per query. For SOQL, that means preferring predefined query templates for common agent tasks and applying explicit rules to free-form queries, such as requiring a filter, rejecting unbounded selects, and bounding time ranges. NIST's example is limiting a recent-events view to the last 30 days rather than allowing a query from 1972 onward.

Finally, add cumulative per-identity limits and escalation thresholds. Count rows returned per user, agent or assistant over a time window, and rate limit when the counter passes a set value. Above a higher threshold, hold the call and route it for human approval. Per-identity limits only work if agents have distinguishable identities, so resolve that before you set the numbers.

• Per-call row cap and response size cap
• Field allow-list, redaction or block rules per tool
• Query-shape rules: templates, required filters, bounded time ranges
• Cumulative rows per identity per time window, with rate limiting
• Escalation threshold that routes the call to a human approver

Chunked and repeated calls, and the trade-offs

The pattern most likely to defeat a simple cap is chunking. An agent that cannot retrieve a full table in one call can request it in slices, using paging clauses, shifting filters or alphabetical ranges, each call within the row cap. A per-call limit cannot see this. Only a cumulative counter tied to an identity, together with query-shape rules that flag sequences of near-identical queries with moving boundaries, addresses it. Keep the counter outside the model's context so the agent cannot reason its way around it.

Every cap has an operational cost. Tight caps produce false positives when an analyst or agent has a legitimate need for a larger pull, such as a quarterly reconciliation. Predefined queries reduce risk but limit flexibility for coding assistants that explore data. Redaction can break downstream tasks that assumed a field would be present. Escalation adds latency and depends on approvers who respond quickly and understand what they are approving.

The practical response is to run new caps in a monitor-only mode first, review what would have been blocked, then tighten. Define the approval workflow before enforcement starts, so a capped task has a clear path forward instead of prompting people to look for workarounds. Review thresholds on a schedule, because agent usage shifts.

Evidence that the caps were applied

A cap that cannot be demonstrated is hard to defend in an investigation or audit. For each SOQL tool call, record enough to reconstruct the decision: timestamp, calling identity, tool name, the query or its normalized shape, the policy that applied, the decision (allowed, redacted, blocked, rate limited or escalated), rows requested and returned, fields redacted or withheld, the cumulative counter at decision time, and the approver and outcome for escalations.

This matters for regulatory reasons as well. If the FTC Safeguards Rule (16 CFR Part 314) applies to your organization, it requires regular testing or monitoring of the effectiveness of key controls, including those that detect actual and attempted attacks or intrusions. It also requires notifying the FTC no later than 30 days after discovery of a notification event involving the information of at least 500 consumers, as of November 2026. Confirm applicability against the full rule. If it applies, per-call records are what let you scope what data left and test whether your caps fire as designed.

Write evidence at the moment of enforcement, not assembled afterward from scattered application logs. Records produced by the enforcement point itself are consistent and tied to the policy version in force, and retention can be set to match your obligations.

Where runtime policy enforcement fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants. For SOQL tool calls, that means each call is evaluated at runtime, not reviewed after the fact, and the outcome is allow, redact, block, rate limit or escalate for human approval. Row caps, field redaction, per-identity rate limits and approval thresholds are policy decisions applied at this point, and each enforcement generates audit-ready evidence mapped to frameworks including HIPAA and NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

The scope is individual interactions and tool calls. This layer does not replace Salesforce permissions or sound MCP server configuration, and it does not trace a whole business process across tasks and agents. It is the point where volume and field decisions can be enforced consistently and proven, which is the gap that permissions and server settings leave open. The approach is useful whichever tooling you use to implement it.