The agent is an identity
Most AI risk conversations start with the model. I think they should start with the credentials. An agent can only do what its identity allows — so govern the identity.
AI risk conversations tend to start with the model: is it aligned, can it be jailbroken, does it hallucinate. Those are real questions. But when I review an agent going to production, my first question is a different one: what can it sign in as?
An agent can’t delete what it can’t reach. Whatever the model decides, the damage is capped by the permissions of the identity it uses. That makes identity the most dependable control we have, and the one security teams already know how to run.
The non-human identity problem was already here
Service accounts, service principals, API keys, and workload identities have outnumbered people in most environments for years. Many of them have no owner, never expire, and hold far more access than they need. Agents add to that population, with a difference: they decide what to do with their access at runtime, based on input that an attacker may control.
A service account that runs a nightly job does the same thing every night. An agent with the same credentials does whatever its context window persuades it to do.
What I apply to agent identities
I extended our identity governance to cover machine, service, and agent identities with the same discipline we apply to people, plus a few rules specific to agents:
- One agent, one identity. No shared service accounts across agents. If you can’t tell which agent took an action, you can’t investigate it or revoke just that one.
- A named human owner. Every agent identity has a person accountable for it, who reviews its entitlements on the same cycle as privileged human access.
- Scope to the task, not the team. An agent that reads invoices doesn’t get write access to the finance system “in case it’s needed later.” Tool scoping and entitlement scoping are the same conversation.
- Short-lived credentials. Tokens that expire in minutes, issued per task where possible. Credentials go in a vault, never in a prompt or config file.
- Act on behalf of, not as. When an agent acts for a user, it should carry that user’s delegated context, so it can’t do more than the user could. An agent acting as a broadly privileged identity for anyone who asks is a confused deputy waiting to happen.
- Treat high-impact actions as step-up actions. Just as a human needs re-authentication for sensitive operations, an agent’s destructive operations route through an approval gate.
Why this matters more than the model
Models will keep changing, and every few months the jailbreak techniques change too. The identity layer is stable. It’s auditable, it’s already in your SIEM, and your access reviews and Conditional Access policies already apply to it.
If I could only get one control in place before an organization deploys agents broadly, it would be this: every agent has its own identity, its own owner, and only the access its task needs. The guardrails, gateways, and tracing all matter, and I run all of them. But they work best on top of an identity layer that already limits the damage.