TL;DR
- Permission drift occurs when the access users actually hold diverges from the access anyone intended them to hold.
- An agent operating without a current permission map fails in two directions: it errors on actions it should be able to take, or it succeeds on actions it should not. The second failure is quieter and worse.
- Fixing this is not a months-long access review; it is making effective access legible.. for the agent to reason about, and for the agent itself as a new identity in your org.
*****
A user in your org has Modify All Data.
She got it in 2022 for a data migration that took three weeks.
The migration ended. The permission didn't.
She's since changed roles twice, and her effective access is now a geology of grants: a profile from her first job, four permission sets from her second, two permission set groups from her current one, plus the migration-era elevation that nobody remembers and nothing flags.
Ask what she can actually see and do in the org, and the honest answer is that no one knows without running the audit, and the audit takes weeks, so no one runs it.
This is permission drift: the steady divergence between the access your org grants and the access anyone intended.
Permission sets accrete.
Users get elevated access for a project and keep it forever. Profiles hold legacy permissions that predate the current security model. The intended permission model exists in someone's head or a stale spreadsheet; the actual permission model exists only as the sum of every grant ever made, minus the few that were ever revoked.
For an agent, this produces two distinct failure modes.
First, a agent working from an assumed permission map will fail on actions it should be able to take… it believes a user can't edit a record that they can, builds logic around the wrong constraint, errors out. That failure is loud. You see it, you fix it.
The second failure mode is the agent succeeding on actions it should not: reading data through an over-permissioned integration user, surfacing records to someone whose access was supposed to end in 2022, executing a change under an identity that was never meant to hold write access to that object. That failure produces no error message. It produces a correct-looking result built on access that shouldn't exist. Both are failure modes; one is just easier to spot than the other.
The scale of the underlying drift is well measured, and the numbers are worse than intuition suggests. Microsoft's ongoing analysis of cloud permissions across major platforms found that identities use only about 1–2% of the permissions they've been granted, that more than half of identities qualify as "super identities" with access to essentially everything, and that over 60% of identities holding permissions are completely inactive.
While that's not a Salesforce-specific finding, it's the measured shape of what happens to any permission system administered by busy humans over years.
Granting is always easy and urgent.
Revoking is hard and never urgent.
Why permission models drift instead of decay
Drift is built into the mechanics.
Salesforce's permission architecture is additive: profiles set a baseline, permission sets stack on top, permission set groups bundle the sets, and effective access is the union of everything. Nothing in that structure wholly subtracts. A grant made for a temporary need has no natural expiration (assignment expiration dates exist now, but almost nothing granted before their arrival uses them), so temporary access becomes permanent by default… through inertia, not decision.
The auditing burden seals it. Resolving one user's effective access means walking their profile, every assigned permission set, every group, object-level permissions, field-level security, and the sharing model underneath all of it. Doing that for one user is tedious. Doing it for the org is weeks of work that produces a snapshot already stale by the time it's finished. So the audit gets scheduled annually, or after an incident, or never, and between audits, the drift runs uncorrected.
The people who granted the access leave. The projects that justified it end. The permission sets remain, named things like Q3_Migration_Access and Temp_Admin_DO_NOT_DELETE, assigned to users who couldn't tell you why.
The silent failure mode has data behind it
The loud failure (agent errors on blocked actions) is annoying but self-announcing.
The sneaky one is the one worth being afraid of, and it's now measurable. When Salesforce's own AI research team benchmarked leading models in realistic CRM environments, task accuracy was the headline finding, but the sharper result was buried in the confidentiality testing: agents showed near-zero awareness of what they shouldn't share.
Models freely disclosed sensitive customer data, internal metrics, and proprietary information simply… when asked.
Explicitly instructing them to respect confidentiality helped… GPT-4o's detection of confidential data went from zero to 34.2%, but at the cost of task performance, and even then, two-thirds of sensitive requests still got through.
Reading that finding through a permissions lens and it’s clear the agent doesn't decide what it can access; its identity does. An agent with no innate sense of "should" inherits its entire notion of "can" from the permission model it operates under.
If that model has drifted, if the integration user it runs as holds View All Data because someone needed a quick fix in 2021, the agent will use that access, correctly, confidently, and without any signal that anything is wrong.
The confidentiality research says the model won't catch it. The drift means the permission layer won't either. Nothing in the stack knows the access is a mistake, because the mistake was made years ago and ratified by silence ever since.
What an agent needs from the permission layer
Safe agent operation requires three things drift has destroyed: the structural context of effective access (what each identity can actually do right now, resolved across profiles, sets, groups, and sharing — not what the documentation claims), the ability to reason about access in context (an agent answering "who can see this field?" needs the real answer, because it will act on whatever answer it has), and a properly scoped identity of its own.
That last one deserves its own paragraph, because agents don't just read the permission model… they join it.
Every agent in your org is a new identity holding grants, and the early evidence says organizations are repeating the drift pattern at higher speed: a 2026 survey of security professionals found that 46% report AI-powered tools already have access to critical systems and data, while 76% say those identities aren't consistently governed under privileged access policies.
The most common setup failure is the obvious one… the agent gets assigned an admin profile or an existing over-permissioned integration user because that's what makes the demo work.
How an indexed permission model closes the gap
Sweep's Metadata Graph treats the permission layer as first-class metadata, indexed alongside the schema and automation it governs: profiles, permission sets, permission set groups, object and field-level access, and the assignments connecting them to actual users. The practical effect is that effective access becomes a query instead of a project. "What can this user see?" and "who can edit this field?" get grounded answers in seconds. The same answers a weeks-long manual audit would produce, without the weeks or the staleness.
That legibility works in both directions at the moment of action. An agent operating in Build Mode consults the indexed permission model before executing changes, it knows which permission sets govern an object before it updates a rule, and its own actions run through impact analysis rather than through inherited, unexamined access. And for the humans governing agents, the index is what makes the "before" state visible: you can't right-size an agent's identity against a permission model you can't read.
Before you give an agent an identity in your org
Resolve effective access for your riskiest identities. Integration users, API users, and anyone holding Modify All Data or View All Data. If producing the real list takes more than a day, agents will be operating on access nobody has verified.
Find your expired-project grants. Permission sets assigned for initiatives that ended. Sort assignments by created date and ask what each one was for; the ones nobody can answer are your drift inventory.
Check what your existing integration users can do. These are the identities agents most often inherit, and they're historically the most over-permissioned in any org — granted broad access once, during setup, by someone solving a connection problem rather than designing a security model.
Scope the agent's identity deliberately. A dedicated identity, minimum permissions for its actual tasks, and expiration dates on anything elevated. If the vendor's setup guide says "assign the System Administrator profile," that's a finding about the vendor.
Make access reviewable continuously, not annually. Drift is a rate, and any audit cadence slower than the granting cadence loses. The fix is making effective access cheap to check, so checking becomes routine.
Permission drift as a category of risk
Drift belongs alongside the other structural risks we've named in this series because it shares their signature: the model can be capable, the action can be well-intentioned, and the failure still happens — in the gap between the access that exists and the access anyone meant to exist. It also has the longest fuse. Schema misreads and automation cascades announce themselves in days. A permission problem can sit silent for years and only becomes visible as an incident.
The management of it is, once again, infrastructure.
Effective access that can be queried is effective access that can be governed for every human identity that's drifted over a decade, and for every agent identity you're about to create.
The permission model your org intends and the one it actually runs have been diverging since the day the org was born.
Agents don't cause that divergence.
They're just the first thing fast enough, and literal enough, to act on all of it at once.
