AI agents can inherit the authorizing user’s access and then retrieve entire records, attachments, and query results at machine speed. In Salesforce, that often includes PII, PHI, financial data, credentials, and source code. The risk grows because the response is passed into the model context without inspection unless a dedicated MCP-layer control is in place.
Why AI Agents Through MCP Raise Salesforce Exposure
AI agents connected to Salesforce through MCP do not just “look up” data, they can inherit a user’s effective access and then retrieve far more than a human would in the same session. That matters because Salesforce often holds PII, PHI, financial records, customer attachments, case notes, and embedded secrets. The risk is not only overbroad access, but fast, programmatic collection into model context where downstream inspection is limited. Current guidance from OWASP Agentic AI Top 10 and NHIMG’s OWASP Agentic Applications Top 10 treats this as an authorization and data-handling problem, not a simple integration issue.
NHIMG research on agent behaviour shows the operational reality is worse than policy documents suggest: in the AI Agents: The New Attack Surface report, 80% of organisations said agents had already acted beyond intended scope. In practice, many security teams encounter excessive Salesforce exposure only after an agent has already queried and forwarded sensitive records at scale, rather than through intentional testing.
How the Risk Works in Practice
MCP can make Salesforce feel like a governed tool, but the control plane is often thinner than teams assume. The agent authenticates through a user or service account, invokes Salesforce tools, and receives raw responses that may include full object records, related child objects, notes, or file metadata. If the MCP layer does not enforce tool-level scoping, field filtering, row limits, and content inspection, the agent can collect more data than the original workflow requires.
This is why static IAM is a poor fit for autonomous or semi-autonomous agents. Human users have predictable paths; agents chain actions, search broadly, and retry with slight prompt variations. Best practice is evolving toward intent-based or context-aware authorization, where the request is evaluated at runtime based on the task, the data class, and the current risk. NIST’s NIST AI Risk Management Framework supports this kind of governance, while the OWASP Non-Human Identity Top 10 reinforces the need to treat machine identities as first-class access subjects.
In practice, teams reduce exposure by combining:
- Just-in-time credentials with short TTLs so tool access expires after the task.
- Workload identity for the agent, rather than long-lived shared secrets.
- Field-level and object-level allowlists for Salesforce queries.
- Response filtering before model context receives the payload.
- Logging that records what was requested, returned, and actually used.
Those controls align with lessons in NHIMG’s 52 NHI Breaches Analysis, where credential misuse and excessive privilege repeatedly turn integration convenience into data exposure. These controls tend to break down when the agent is allowed to perform broad ad hoc searches across multiple Salesforce objects because the returned dataset becomes too large and too sensitive to inspect reliably in-line.
Common Variations and Edge Cases
Tighter tool scoping often increases setup overhead, requiring organisations to balance agent flexibility against data minimisation. There is no universal standard for this yet, especially when the agent must handle mixed sensitivity data, cross-object joins, or attachments that may contain unstructured secrets. Current guidance suggests that teams should treat these cases as exceptions requiring explicit approval, not as a default permission model.
One common edge case is a support or sales agent that legitimately needs broad read access for a narrow time window. In that scenario, JIT provisioning helps, but only if the agent’s workload identity is bound to the exact task and the returned context is still screened for restricted content. Another edge case is prompt injection or tool chaining, where the agent is manipulated into querying unrelated records. NHIMG’s Gemini AI Breach — Google Calendar Prompt Injection and CoPhish OAuth Token Theft via Copilot Studio show how quickly agent workflows can be steered into unauthorized access paths.
For organisations comparing controls, the CSA MAESTRO agentic AI threat modeling framework is useful for identifying where the MCP boundary should sit, and the NIST Cybersecurity Framework 2.0 helps map governance and monitoring responsibilities. The practical limit is simple: these safeguards weaken when Salesforce data is returned as large, unstructured result sets that the agent can immediately ingest, transform, and redistribute without a human checkpoint.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Covers excessive agent autonomy and unsafe tool use in MCP workflows. |
| CSA MAESTRO | GOV-02 | Addresses governance for agentic systems and tool-mediated access paths. |
| NIST AI RMF | Supports runtime risk evaluation and accountability for AI-enabled access decisions. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Relevant to secret sprawl and overprivileged machine identities in MCP integrations. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management directly reduces Salesforce exposure through agents. |
Inventory MCP credentials and replace shared long-lived secrets with scoped identities.
