What permissions should an AI agent have in your cloud?
An AI agent should have as few permissions as possible, read-only wherever the task allows, scoped to specific resources rather than broad admin, and tied to its own identity. The guiding rule is to scope permissions around the blast radius if the agent acts unexpectedly, not just around what it’s supposed to do, because an agent will sometimes do something it wasn’t supposed to.
Give each agent its own identity
The first mistake most teams make is running an agent on a developer’s credentials because it’s fast. Now the agent can do everything that developer can, and your logs can’t tell them apart. If the agent drops a table, the trail says the developer did it.
Give each agent its own identity, a dedicated IAM role or service account. That makes its actions attributable, and it lets you scope and revoke that one agent without touching anyone else. This is the same reasoning behind deciding who should hold production access at all, applied to a non-human.
Least privilege, read-only by default
Start from deny-all and add only what the agent demonstrably needs. In practice that means read-only wherever the task allows, since most agents need to look far more than they need to change, and scoped tokens rather than account-wide access: a specific bucket, a specific database, a single project.
This is just least privilege applied to agents, and the same honest caveat applies. Working out the exact permissions is tedious, and under a deadline it’s tempting to hand over a broad role “just to make it work.” That broad role is what turns a confused agent into an expensive incident.
Why scoping isn’t enough
Scoping shrinks the blast radius, but it doesn’t remove it, because the permission an agent needs to do its job is often the same one it can misuse. Give an agent write access to a bucket so it can publish, and it can also empty that bucket. You can’t scope your way out of that, because the dangerous action and the intended action use the same permission.
So least privilege is necessary and incomplete: it decides what an agent can reach, not whether a specific action it takes with that access is fine or catastrophic.
Make it time-bound
Permissions shouldn’t be permanent either. An agent that needs write access for a task doesn’t need it forever. Just-in-time access grants it for the task and expires it, so there’s no standing agent credential sitting around to be stolen or misused between runs.
Where Korvalis fits
Korvalis handles the two parts scoping leaves open. It grants access that expires on its own, so agent permissions don’t linger, and it watches the live session and cuts off a destructive action before the command finishes, even when the permission technically allowed it. That covers the case least privilege can’t: the intended permission used for an unintended, destructive action. For the wider decision on whether to grant agent access at all, see is it safe to give an AI agent access to your cloud.
Frequently asked questions
What permissions should an AI agent have? As few as possible, read-only where the task allows, scoped to specific resources, and tied to its own identity.
Should it have its own IAM role? Yes. An agent on a shared or human credential is indistinguishable from that human in your logs and inherits everything they can do.
Is least privilege enough? Necessary but not sufficient. The permission an agent needs to do its job is often the same one it can misuse, so scoping should be paired with watching what the session does.
If scoping agents is on your list, see how Korvalis guards the actions too or join the waitlist.