What it is
Privilege compromise covers two related problems: (1) the agent was given too much — a service account with System Administrator profile rather than a scoped permission set, an OAuth token with full inbox access rather than a single label, an MCP server exposing every tool rather than the few needed for the task; and (2) the agent has acquired more — through token leakage, scope escalation in a connected system, or chained permissions across tools. In both cases, the consequences of any other compromise (prompt injection, memory poisoning, tool misuse) are amplified by whatever the agent's highest privilege happens to be.
Why it matters
The single highest-leverage thing most teams can do for agent safety is enforce least privilege: every agent gets the minimum scope it needs, separated by purpose, with no shared service accounts. This is unglamorous, and teams often skip it because it is faster to ship with a "god mode" service account and tighten later. A common finding when an agent incident is reviewed is that the agent had far more access than its task needed. Treat the privilege boundary as one of the most important design decisions you make.
Key components
- Over-permissioning at grant time — broader scopes than the task requires
- Privilege drift — scopes accumulate as new tools are added, never pruned
- Token / credential leakage — secrets exfiltrated through prompts or logs
- Scope escalation in connected systems — agent inherits more in Salesforce than the API contract suggests
- Mitigation — per-purpose service accounts, scoped tokens, regular access review, separation of duties
How it connects
In Agentforce, this shows up most often as agents built on a System Administrator profile or a connected app granted org-wide OAuth scope — quick to configure, dangerous to leave in place. Salesforce permission sets and named credentials exist precisely to scope access by task, so there is no good reason for a quoting agent and a case-routing agent to share the same identity.
Good to know
Auditing an agent's effective permissions is harder than auditing a human user's, because access is often spread across a profile, multiple permission sets, a connected app, and any external tools the agent calls — review all four layers together, not in isolation.
Related terms
Agent Governance
The policies, controls, and monitoring systems that ensure AI agents operate safely, compliantly, and within business-approved boundaries.
Trust Layer
Salesforce's AI trust and safety framework that ensures agents operate within compliance boundaries, prevent misuse, and maintain data security.
Threat Modeling (AI Agents)
A structured way to identify what could go wrong with an AI agent before it does — mapping attackers, attack surfaces, and impacts so you can build defenses in.
Identity Spoofing
Attacks where an adversary pretends to be a trusted user, agent, or system in order to issue commands or access data the agent would otherwise refuse.
Tool Misuse
Attacks where the agent stays inside its allowed permissions but is tricked into using its tools in damaging combinations or with attacker-chosen inputs.
