Salesforce MCP Authorization Scoping for Autonomous Sales Agents

Salesforce MCP authorization gives autonomous sales agents the permissions of the user they connect as. That makes existing over-permissioned roles an agent security problem. Access must be narrowed at the tool and request level, then agents’ actual activity monitored, before inherited access becomes automated exposure.

How Salesforce MCP authorization actually works — and what it silently assumes

Salesforce’s GA announcement describes a deliberate inheritance model. Every MCP transaction runs as the authenticated user, with that user’s identity, permissions, and accountability. OAuth and PKCE govern the connection, while the user’s permissions govern access to SOQL queries, SObject CRUD, Flow execution, Apex REST, and other operations. The agent gets no separate permission surface by default. Salesforce’s Summer’26 release documentation says custom MCP servers “respect the full sharing and security model you have configured for your Salesforce org.”

That model preserves existing controls over records and fields. It also records the human user’s name on agent-initiated changes, treating the agent as a proxy whose actions belong to that user. A name in the audit trail identifies the account under which an operation ran and leaves human approval of that particular operation unverified.

The MCP specification leaves important authorization decisions to implementations. Authentication is optional, role-based access control is not defined, and the protocol does not specify how requests map to verifiable enterprise identities. HTTP servers that enable authorization must follow specific OAuth requirements, but those requirements do not say what an agent is allowed to do for the business. Meanwhile, Agentforce supports approximately 20 simultaneous MCP tools per agent for context management. Teams therefore have to curate tools, although a context limit does not tell them which combinations are safe.

Why inherited permissions become a structural hazard when agents replace human interaction

Human roles accumulate access because granting permissions is easier than auditing and revoking them. Security practitioners call that accumulation permission debt. A sales representative with broad object access may rarely use most of it, so everyday habits act as a rough, unofficial restraint. An autonomous agent can process reachable data and invoke available tools at machine speed, without fatigue.

The distinction is between authorized access and necessary access. A user’s role describes what that person may do across a range of responsibilities, while an agent may exist to complete one narrow task. When both have the same access, the agent can use the broader role in every decision it makes. The account can be correctly authenticated and still be overpowered for the job. Nothing has to bypass the permission system for that mismatch to cause harm.

Scope sprawl makes the mismatch harder to see. An agent built for lookups gets Flow execution, then record updates, then queries across related objects as it takes on more tasks. Without a formal permission review, these additions can give the agent broad CRM access that nobody chose to approve as a whole. The tool limit becomes a capacity target. With the’27 release’s auto-enablement arriving in October 2026, organizations that relied on Agentforce being opt-in face this inherited access without a platform-level off switch.

What ForcedLeak showed about over-permissioned agents in practice

Noma Labs disclosed ForcedLeak in September 2025, documenting how an indirect prompt injection could turn reachable CRM data into an exfiltration target. The vulnerability received a CVSS rating of 9.4. An attacker could place hidden instructions in a publicly accessible Web-to-Lead “Description” field, which allowed 42,000 characters. When a sales representative asked Agentforce about that lead, the agent could execute the embedded instructions.

Those instructions could direct the agent to extract email addresses from reachable CRM records and embed them in image requests to an attacker-controlled server. The injected text supplied the direction. The connected user’s permissions supplied the reach. The agent inherited the user’s broad contact-read access, exceeding what was necessary to answer a question about the lead.

The patch closed the specific injection vector without shrinking that permission surface. Scoping the agent to records relevant to its task would have left unrelated addresses outside its reach, even though permission scoping would not itself solve prompt injection. That distinction separates prevention of an attack from containment of its consequences. Broader MCP authorization failures reinforce the same pattern, with absent or overly coarse server boundaries allowing a single authentication failure to expose full tool access.

What the NSA's MCP guidance requires and why most current deployments fall short

The NSA’s May 20, 2026 guidance, “Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation”, identifies gaps in MCP design, implementation, and operational safeguards. Its requirements go beyond authenticating a connection. Each tool invocation should use a least-privilege credential permitting only what that action needs. A read operation on one table should not arrive with authority to write or access other tables. Each agent should also have a distinct identity that downstream systems can audit, rate-limit, and revoke independently of the human user.

The MCP specification’s July 28, 2026 update changes the surrounding infrastructure. It requires clients to validate the authorization server’s issuer, addressing OAuth mix-up attacks, while removing protocol-level sessions and the Mcp-Session-Id header. The protocol core becomes stateless, but applications can still keep state by passing explicit handles as tool arguments. Even with stronger authentication, the audit trail does not get richer on its own. Platforms or monitoring layers must preserve the context needed to reconstruct related actions.

Cloud Security Alliance’s 2026 findings show how poorly equipped many organizations feel for this work. It reports that 92% of respondents are not confident their legacy identity and access management solutions can effectively manage AI and non-human-identity risk. Still, it helps explain why inherited human permissions fall short as the default for work that agents do on their own.

Forrester’s “least agency” framing names the broader design problem. Agents need the minimum permissions, capabilities, tools, and decision-making authority required for specific tasks, bounded by time and approval scope. Access is only one part of that boundary. A human role cannot, by itself, express which decisions an agent should make or when it should stop and seek approval.

The design controls that actually scope agent permissions below the inherited ceiling

Salesforce has tools to narrow agent access, but teams must choose how to put them together for the task. Custom MCP servers are the primary scoping tool. Rather than expose the full CRUD and SOQL surface of a standard SObject server, a custom server can expose only selected Apex actions, Named Query APIs, or autolaunched Flows. An agent summarizing open opportunities can use a Named Query API returning that result set, with no write tools exposed.

This approach requires custom development. InvocableMethod-annotated Apex can put field restrictions inside a tool definition, supplementing the connected user’s field-level controls. Named Query APIs and parameterized SOQL can constrain retrieval to predefined results instead of arbitrary queries across the object model. The purpose is to make the tool itself a narrow authorization boundary. Every exposed tool should have a documented business purpose, with write and export tools separated from read-only tools into different server configurations.

Identity needs its own separation from human sessions. Dedicated connected apps with scoped OAuth provide a minimum starting point, while each agent should have a distinct, revocable identity. Agent Fabric’s Trusted Agent Identity lets actions use the specific user permissions tied to a task. For high-stakes actions, it can send a mobile authorization request to a human before execution. That approval places a deliberate pause between an agent’s decision and a privileged operation.

Agent Fabric’s Controlled Registration lets administrators selectively register agents and tools that meet defined business rules. MCP Bridge adds security and rate-limiting to existing APIs made agent-ready without code changes, which limits how much damage an agent can do at machine speed. Neither mechanism substitutes for narrow data access. Together with custom-server designs using short-lived credentials and explicit per-call scopes, they address three separate layers, which are identity, action, and data.

The shadow-agent and ungoverned-server problem that platform controls alone cannot reach

Approved agents are only part of the permission surface. Citizen-built agents using Claude Desktop or Cursor can connect directly to Salesforce through personal OAuth grants, outside a formal governance review. Carefully scoping the approved fleet does not scope those connections. Agent Fabric’s Expanded Agent Scanners extend discovery to MCP servers and platforms including Amazon Bedrock, Microsoft Foundry, and GoDaddy. Discovery makes these assets visible, but visibility must lead to review.

The Linux Foundation took over MCP governance in December 2025. Its Enterprise Readiness roadmap identifies unresolved work on structured audit trails connected to existing SIEM infrastructure, SSO-integrated enterprise authentication, authorization propagation through gateways and proxies, and configuration portability across clients. These details affect how authorization and evidence carry through from one system an agent uses to the next. Platform scoping thus needs a monitoring layer that can look across individual connections.

Asking whether a user has access is less exact than asking whether this agent should perform this action, through this tool, on this data, at this time. Answering it requires runtime context. Useful audit records must preserve the agent’s business purpose, the trigger, the tool invoked, the policy that allowed it, and the downstream object changed. Without that chain, investigators may struggle to distinguish routine automation from unauthorized access.

The sessionless protocol makes preserving that chain an application responsibility. Continuous discovery and review are also needed to find privilege creep, forgotten test agents, and integrations that outlive their authorization. A one-time inventory becomes less useful as those connections change. Runtime monitoring must do more than store events: it must spot anomalous behavior and support policies that can be enforced at the tool and request level.

What teams should do before Winter '27 auto-enablement reaches their org

The preparation sequence should start with discovery, because configuration cannot protect connections the organization has not found. Teams should inventory every MCP server and Agentforce agent, including endpoints created independently by developers or business teams. Agent Fabric provides automated discovery across platforms. Organizations without it should audit OAuth-connected apps to get a view of which MCP clients are connected. That inventory establishes the permission surface to examine, rather than assuming the approved agent list is complete.

Next, teams should find the connected user for each agent and check that user’s effective permissions. They should check inherited sharing, role hierarchy access, and permission set assignments as part of that review. Comparing the agent’s stated purpose with its effective permissions exposes where a narrow task has inherited broad authority and gives the custom-server work a clear priority. Agents that use contact records, opportunity financials, or cross-object data should move to servers that expose only the tools and query results they need for their tasks.

For read-heavy sales workflows, Named Query APIs and parameterized SOQL provide the scoping primitives. Write operations and Flow execution should use distinct server configurations with explicit registration through Controlled Registration. Teams should then assign distinct agent identities through dedicated connected apps with minimal OAuth scopes, independent of human sessions. Privileged actions need an additional decision point. Trusted Agent Identity’s mobile approval routing can keep a human in charge of approving money movement, bulk export, and cross-team data access without making every operation manual.

Finally, teams should set up runtime monitoring above the platform layer. Salesforce’s audit trail records who did what, but it does not provide fleet-wide detection of anomalous behavior, real-time policy violations, or scope creep. Monitoring must keep watching what agents do, enforce rules at the tool and request level, and keep a full history of their actions even with the sessionless protocol. This is where configuration becomes an operating control. Narrow permissions reduce what an agent can reach, while runtime enforcement addresses whether a particular use of that access should proceed.