The MCP confused deputy problem: agents call systems like Salesforce with a shared service account, so users reach data they shouldn't. How per-user identity passthrough fixes it - and why identity and DLP are two layers, not one.
It’s the question almost no one asks when they wire up an MCP server. When an AI agent calls the Salesforce MCP server on a user’s behalf, it needs credentials. The path of least resistance is one service account with wide access, shared by every user of the agent. It works immediately — and it quietly removes the single most important control the downstream system has: its own per-user permissions. This is the classic confused deputy: a privileged intermediary (the agent) acting on behalf of a less-privileged party (the user), using the intermediary’s authority instead of the user’s.
Walk the escalation through. Your support agent connects to Salesforce with a service account that can read every account. A support rep — who in Salesforce can only see their own assigned accounts — asks the agent, “summarize our top customers by revenue.” The agent queries with the service account and returns every account, including ones the rep has no business seeing. No permission was violated at the database level, because the query ran as the god-mode account. The user’s own access controls simply stopped applying the moment the agent became the deputy.
| Shared service account | Per-user identity passthrough | |
|---|---|---|
| Who the query runs as | One broad account | The actual user |
| Downstream permissions | Bypassed | Enforced by the system itself |
| Blast radius | Everything the account can reach | Only what the user can reach |
Strac solves this by passing the individual user’s identity through to the downstream system, rather than collapsing everyone into a shared account. When the rep asks their question, the query runs as the rep — and Salesforce’s own permission model returns only the accounts they’re allowed to see. You don’t rebuild access control in the agent layer; you let the system that already has it do its job. This works across connected systems — see the MCP integrations and connectors like the Salesforce MCP server.
It’s tempting to think DLP alone is enough: let the agent fetch whatever, then redact the sensitive parts. That’s a band-aid. If the agent should never have retrieved a record in the first place, redacting a field on the way out still means the data was queried, logged, and briefly in context. Identity prevents the retrieval; DLP protects what legitimately flows. You want both: per-user identity so the agent only ever pulls what the user is entitled to, and MCP DLP so the PII, PHI, and secrets inside that legitimate data are still redacted, masked, or blocked as policy requires.
It's when an AI agent calls a system (like Salesforce) using its own broad credentials instead of the user's. The agent is a privileged 'deputy' acting for a less-privileged user, so the downstream system's per-user permissions stop applying and the user can reach data they shouldn't.
Because every user of the agent inherits the account's access. A user who should see only their own records gets answers drawn from everything the service account can reach - the query never runs as them, so their own permissions are bypassed.
It passes the individual user's identity through to the downstream system so that system enforces its own permission model. The query runs as the user, and they get only what they're entitled to - instead of the agent's god-mode view.
No. DLP protects sensitive fields in data that legitimately flows, but if the agent should never have fetched a record, redacting it afterward is a band-aid - it was still queried and put in context. Identity prevents retrieval; DLP protects what's allowed. You need both.
Yes. Strac passes the individual user's identity through to connected systems and logs every MCP invocation by user, tool, and data - so downstream permissions apply and per-user access is provable for an audit.
An agent with a shared service account is a confused deputy with god-mode. Strac passes each user’s identity through so the downstream system’s own permissions apply — then layers MCP DLP on top of what legitimately flows. Two layers, not one. See MCP security for the full model, or book a demo.
.avif){kind=icon}
.gif)
.webp)
