Giving an AI agent permission to act

Every agent project reaches the same meeting. Someone says the agent should be able to actually fix the problem, not just describe it, and everyone nods. Then somebody asks what happens if it is wrong at three in the morning, and the room goes quiet.

That question deserves an architectural answer, not a prompt.

Risk tiers, declared at the tool

The model we keep returning to is simple: every tool the agent can call declares its own risk tier before the agent ever sees it.

Read tools run freely. Fetching logs, reading a config, querying metrics. Worst case the agent wastes tokens.

Write tools run but are logged with the full arguments and the reasoning that led to them. Creating a ticket, posting a message, adding a record. Recoverable, but you want the trail.

Destructive tools stop and wait for a human. Deleting, scaling down, rotating credentials, spending money, touching production data. No exceptions and, critically, no bypass.

That last point matters more than it sounds. The tempting optimisation is a "trusted mode" where a well-behaved agent skips the gate. An agent that can skip the gate under some condition will skip it during the exact incident where the gate mattered, because incidents are where conditions get weird.

Approval has to carry context

A permission prompt that says "the agent wants to run delete_snapshot, approve?" is not a safety mechanism. It is a button that people learn to press.

Useful approval requests carry three things: what the tool will do in plain language, what state the agent believes it is in, and what it expects to happen afterwards. That third one is the valuable one. When the agent's stated expectation does not match your mental model of the system, that mismatch is the signal, and it surfaces before the action rather than after.

Scope the credentials, not just the prompt

Prompts are guidance. Credentials are enforcement.

If your agent holds a role that can drop tables, then the only thing standing between you and a dropped table is text in a context window, and text in a context window is negotiable. The agent's IAM role, database user, and API scopes should make the dangerous actions impossible rather than discouraged. The permission tier in your application is the second layer. The credential boundary is the first.

This also makes the blast radius legible. You can hand someone the agent's policy document and they can tell you exactly what the worst case is, without reading a single prompt.

Audit everything, including the refusals

Log the actions the agent took. Also log the actions it proposed and did not get approval for, and the ones it considered and discarded.

The rejected proposals are the most useful data you will have. They tell you where the agent's judgement diverges from your team's, which is precisely what you need in order to decide whether to widen its permissions later. Teams that only log successful actions end up with no evidence base for that decision and either stay permanently cautious or expand access on vibes.

The goal is not an agent you trust completely. It is an agent whose failure modes you have already decided how to survive.