The permission problem nobody solves before deploying agents

The fastest way to get an AI agent working is to hand it a broad API key and let it call whatever it needs. It's also the fastest way to end up with an agent nobody can safely expand, because nobody can say precisely what it can already do.

This is the part every demo skips. A prototype that reads from one spreadsheet and drafts one email doesn't need much thought about permissions — the blast radius is small enough that it doesn't matter. The moment that same agent starts writing to a production system, sending external communications, or touching customer records, the same shortcut becomes the reason the security review stalls the whole project.

A shared credential isn't an identity

"Identity," in the context of an AI agent, isn't a philosophical question. It's a practical one: is this agent provisioned as its own principal, with its own scoped credentials, or is it borrowing a key that some other system — or person — also uses? If the answer is the latter, you don't actually know what the agent can do. You know what the key can do, and the agent is one part of that surface.

That distinction matters the first time something goes wrong. If an agent with its own scoped identity does something it shouldn't, you can trace the action to that identity, see exactly what permissions it held, and revoke or narrow them without touching anything else. If it was running on a shared key, the same incident means auditing everything else that key touches, and rotating a credential that other systems depend on.

Read-only until read-only isn't enough

The default we build to is narrow first, expand deliberately. An agent gets read access before write access, and write access to the specific systems and actions its role actually requires — not the account it happens to be running under. Scope grows as the audit trail proves the agent is behaving as expected, not on a rollout deadline. And when an agent is retired or a policy changes, its credentials revoke instantly, rather than lingering as an old key nobody remembers to clean up.

None of this slows down what the agent can eventually do. It changes the order: instead of building the automation and hoping the permissions turn out fine, the permission boundary is the first thing that gets designed, and the automation is built inside it.

The question to ask before the first workflow goes live

If you're looking at an agent that's about to get access to a real system, ask what it's actually running as. If the honest answer is "an API key someone already had lying around," that's the thing to fix before scope, not after.

Written by Andrew Dainty, founder of Blackwall Labs.