The fastest way to get an AI agent doing useful work is to hand it your credentials. The fastest way to end up explaining an incident to your board is the same move. If an agent acts on live systems, it is a workload, and it deserves the same identity discipline we finally learned to apply to every other workload.
I hold both roles in this argument. I build and run multi-agent systems against live production infrastructure, and I wrote my company's AI Agent IAM Policy, now in production. The builder in me wants the agent to do more. The policy author in me is the reason I can let it.
The shared-credential trap
Most agent projects start the same way: a personal API token pasted into an environment variable, a service account borrowed from another system, a bot user with broader scopes than anyone remembers granting. It works in the demo. Then the agent is useful, so it runs continuously. Now you have an autonomous process holding human-grade credentials, invisible to your joiner-mover-leaver processes, unattributable in your audit logs, and unrevokable without breaking something you've come to depend on.
None of that is a hypothetical failure of the model. The model never has to go rogue. Ordinary bugs, prompt injection, or a compromised dependency will do, and the blast radius is whatever the credential could reach.
Agents are workloads, so treat them like workloads
We already know how to do identity for non-human actors. Cloud platforms give us workload identity, scoped tokens, and managed secrets. The shift is deciding that an agent is not a script you run, but a workload you operate, with an identity of its own.
In practice, that has meant a few working rules for me:
- The agent never holds raw credentials. In my own stack, a credential proxy backed by Azure Key Vault brokers every secret. The agent asks for a capability; the proxy holds the keys. Compromising the agent's context gets you a request path, not a credential dump.
- One identity per agent, per environment. A development agent using a personal account is a liability waiting for production. Service identities, separated by environment, make access reviewable and revocable the way employee access is.
- Scope to the task, not to the platform. An agent that files tickets needs to create issues. It does not need project administration. Every scope beyond the task is blast radius you are donating to your next incident.
- Bound the network, not just the API. A DNS-aware egress proxy means the agent can only reach the places it has a declared reason to reach. Identity controls what it may do; egress control limits where it can do it.
- Log the agent as itself. If actions appear in audit trails under a human's name, you have lost attribution exactly where you need it most.
The payoff is autonomy, not paperwork
Here is what surprised people when I presented this thinking internally: the identity work is what lets the agents do more, not less. When I can show precisely what an agent can reach, through which brokered credentials, with what egress bounds and what audit trail, extending its authority is a bounded decision instead of an act of faith. My own chief of staff agent runs continuously against my company's work systems precisely because it was built this way from day one.
The same logic runs in reverse. If you cannot say what your agent can reach, you cannot safely say yes to the next capability it needs, so every request becomes a fight between the people who want value and the people accountable for risk.
Where to start
If you have agents running today on shared or personal credentials, start with an inventory: every agent, every credential it holds, every scope on that credential. Then pick the agent with the widest reach and give it a real identity: its own service principal, brokered secrets, task-scoped access. Write down the pattern as policy once it works; policy that codifies a working pattern gets followed, policy that imagines one gets routed around.
An agent with an identity is a system you can govern. An agent with your credentials is a liability with a chat interface. The difference is a few weeks of engineering, and it is the difference between scaling autonomy and revoking it.