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.
The confused deputy problem isn’t carelessness — it’s the path of least resistance. An MCP server authenticates to a downstream system with whatever credential sits in its config: an API key, a service-account token, an OAuth app. Wiring that up once, for the whole agent, takes minutes. Wiring up per-user auth — so the agent acts as whoever is asking — means propagating each user’s identity through the call chain, which most teams never build. So the agent ends up with one broad credential, and every user of the agent silently inherits it.
The blast radius depends on the system, but the pattern is the same: the service account can reach far more than any single user should.
| System | What a shared service account can reach |
|---|---|
| Salesforce | Every account, contact, and opportunity — ignoring sharing rules and role hierarchy |
| GitHub | Every repository the app is installed on — not just the ones the user can push to |
| Postgres | Every row and table the connection can select — not just the user’s tenant |
| Google Drive / SharePoint | Every file the account can open — not just what’s shared with the user |
In each case the downstream system already has a permission model that would return the right answer — it’s just never consulted, because the query runs as the deputy. Per-user identity passthrough puts that model back in the loop for every connector in the MCP integrations.
Getting agent access right isn’t one setting — it’s a stack:
Identity prevents retrieval; DLP protects what’s allowed; audit proves it. Drop any one and you have a gap. See MCP security for how the three fit together across every connected system.
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)
