Most AI agents in production right now run on someone's API key. Usually a developer's, sometimes a shared service account created during the pilot and never revisited. The agent reads from the CRM, writes to the ticketing system, and sends emails, all under a credential that also happens to authenticate a human, a cron job, or three other integrations nobody remembers building.
That's not an identity. It's a costume. And it's a governance failure waiting for the moment someone asks a question your logs can't answer.
The log says "API key 7f3a," not "the agent"
When an agent shares credentials with a person or a generic service account, every action it takes is indistinguishable from every other action taken under that same key. Your access logs show a client ID and a timestamp. They don't show whether a human clicked a button or an agent decided, on its own, to do something.
This fails in three specific ways. First, you can't revoke the agent without also revoking whatever else uses that key, so when something goes wrong the fix is "turn everything off" rather than "turn off the one thing that misbehaved." Second, you can't scope the agent's permissions independently of the service account's permissions, so the agent typically inherits far more access than its actual task requires, because narrowing it would break the other things riding on that key. Third, when a customer, auditor, or regulator asks why a specific record changed, you can't produce an answer that names the agent as the actor, because the system of record never knew the agent existed as a distinct entity.
None of this shows up in the demo. It shows up three months later, when the agent has quietly accumulated write access to six systems it touches twice a year, and nobody can say why.
The agent should authenticate as itself
A scoped agent credential is a separate identity, provisioned for one agent, one purpose, with permissions that map to the specific actions that agent needs to take and nothing else. If an agent's job is to draft responses to inbound support tickets and escalate anything involving a refund, its credential should read the ticketing queue and write drafts. It should not also have standing access to the billing system just because the same integration platform happens to offer it, or because it was faster to grant broad scopes once than narrow ones repeatedly.
This is the identity principle, and it's the foundation the other four depend on. Governance policies that decide what an agent can do without human approval only mean something if the system enforcing them can tell, with certainty, which agent is asking. Audit trails that log "who did this and why" only hold up if "who" resolves to a specific credential, not a shared one three other things could have used. In practice this means: a distinct credential per agent, permission scopes defined by the agent's actual task rather than the platform's default grant, and revocation that takes exactly one agent offline without touching anything else. When we design a deployment, we start by mapping every action the agent needs to take against every system it touches, then provision access at that granularity, before the agent runs once. If a task later needs broader access, that's a deliberate change to the credential, not a side effect of reusing one that already had it.
The practical effect shows up the first time something goes wrong. If an agent starts taking actions it shouldn't, you disable one credential and everything else keeps running. If a regulator asks who modified a customer record, the answer is a named agent identity with a defined scope, not a shared key with six plausible authors.
Scoping is a judgment call, and narrow isn't always right
Least-privilege sounds absolute in principle and is a trade-off in practice. Scope an agent too tightly and it can't complete ordinary variations of its own task without kicking every third action to a human for approval, which defeats the purpose of deploying it. Scope it too broadly and you've recreated the shared-key problem with extra steps.
Getting this right takes actually understanding the workflow, not just listing the systems involved. It also means revisiting scopes as an agent's role changes, the same way you'd revisit a human employee's access after a role change, rather than letting permissions accumulate silently because narrowing them felt like unnecessary friction at the time.
The question worth asking
Pull up the credential your AI agent currently uses. Is it provisioned for that agent specifically, or is it a key that also authenticates something else? If you had to revoke the agent's access in the next five minutes, could you do it without breaking anything else that happens to share the same key?
If you're not sure, that's worth a closer look. Book a diagnostic call and we'll walk through what a scoped identity would actually look like for the agents you're running.