It happens in about forty seconds, usually on a Thursday.
You are wiring a sync in a sandbox. The write fails on a permission you did not expect. You have three other things to do that day, so you grant the integration user a broader role to get past it, make a mental note to narrow it later, and ship.
Nobody narrows it later. Narrowing it has no deadline, no ticket, and no owner, and the integration works, which is the whole problem. Working software generates no pressure to change.
Two years on, that account can read every record in the system, write to objects the sync has never touched, and in a few cases delete. It has no password rotation, no expiry, and a name like api_user_2.
The part that is actually new
Over-privileged service accounts are an old problem, and the old advice has been available for decades. What changed is the volume and the attack surface.
CyberArk's 2025 Identity Security Landscape, a survey of 2,600 security decision-makers, put machine identities at 82 for every human identity, with 42% of them holding privileged or sensitive access. In the same survey, 88% of organisations still define "privileged user" as a human being. So the majority of privileged accounts in a typical company sit outside the definition that governs privileged accounts.
Then agents arrived, and they differ from a cron job in one way that matters here: their instructions come from content they read at runtime. A scheduled sync does the same thing every night. An agent summarising an inbox is executing partly on the contents of that inbox, and anyone who can get text in front of it gets a vote. That is not a hypothetical risk class, it is the first entry in the OWASP LLM Top 10.
An over-privileged cron job is a bug waiting for an edge case. An over-privileged agent is a bug waiting for someone to write it a message.
Four things that break, in order of how quietly they break
Blast radius. The sync was supposed to update one field on one object. With a broad role, a bad loop can touch anything the account can reach. The permission set is the only thing standing between a logic error and your whole database, and you removed it on a Thursday.
Attribution disappears. If three workflows share api_user_2, your audit log records that api_user_2 changed a close date. It cannot tell you which workflow, which run, or what triggered it. You are now debugging by correlating timestamps, which is the worst kind of Tuesday.
You cannot revoke one thing. Shared credentials mean revocation is all or nothing. Something misbehaves, you check what else uses that account, discover it is four things including one finance cares about, and you do not revoke it. You open a Slack thread instead.
Credentials outlive their purpose. The workflow gets deprecated. The key does not. It sits there, valid, attached to a system nobody runs, until an audit finds it or something worse does.
The fix is one identity per workflow
Not one per integration, and definitely not one per company. One per workflow, scoped to exactly the objects and fields that workflow touches.
# Before: one account, everything, forever
- scopes: [ crm.objects.contacts.*, crm.objects.deals.*,
- crm.objects.companies.*, tickets.*, files.*, settings.* ]
- owner: (unset)
- expires: never
# After: one per workflow, scoped to what it actually does
+ workflow: post-call-crm-update
+ scopes: [ crm.objects.deals.read,
+ crm.objects.deals.write:close_date,
+ crm.objects.deals.write:stage ]
+ owner: platform-team
+ expires: 90d
The mechanics exist in every platform worth integrating with. Salesforce gives you permission sets and field-level security, so an integration user can be granted edit on two fields rather than an object. HubSpot private apps take granular scopes rather than a role. Most OAuth providers let you request narrow scopes and simply are not asked to.
Three rules make it stick:
Scope to fields, not objects, wherever the platform allows it. "Can edit Opportunity" and "can edit Opportunity.CloseDate" are different blast radii, and the second one is usually what you meant.
Give every identity a human owner and an expiry. An account nobody owns is an account nobody revokes. An expiry forces a five-minute review you would otherwise never schedule, and if renewing it is annoying, that is the system telling you something true.
Put the workflow name in the identity. post-call-crm-update in an audit log answers the question. api_user_2 starts an investigation.
The test
Pick your most recently shipped integration and answer this: can you turn it off, right now, without a meeting?
If revoking one workflow's access means checking what else breaks, you do not have scoped identities. You have a shared admin account with extra steps, and every agent you point at it inherits the whole thing.
SailPoint's 2025 survey found only 44% of organisations have any policy for securing the AI agents they already run. The gap is not usually knowledge. It is that scoping permissions produces nothing you can demo, and Thursday you had three other things to do.
The longer version of this argument, including how per-workflow identity makes writes attributable and reversible rather than just contained, is written up here: giving each agent its own scoped identity. The vocabulary for the account type itself is non-human identity, which is worth knowing because it is what the tooling and the compliance frameworks call it.
I build approval and audit layers over agents that write to production systems at Mindlyft.
What is the broadest permission you have found on an account nobody could explain? Mine was a reporting integration with delete.
