What should an agent have before it can act in production?

What can it reach?

Before approval even matters, credentials decide what the agent can attempt. Check three things: each step gets only the permissions it needs, it holds them only while the step runs, and text the model reads can never reach a reusable credential. One shape that meets that bar looks like this:

The model never holds a long-lived secret, so a poisoned input can’t walk off with a key. It can still ask for any tool call the step is allowed, which is why the gates on risky actions matter. And the sandbox holds whatever context you gave the step, so treat that as exposed. Where the connected tool supports it, the grant belongs to the person who asked, and a question about production errors runs with that person’s read scopes.

Who approves an action?

The question is whether approval is a property of the action or a habit of the integration. If confirmation is a prompt an integration author remembered to add, the safety of any given action depends on whoever wired that action up, and the next integration starts from zero. The alternative is a gate attached to the action itself and enforced outside the agent asking. Filing a ticket passes a model-judged check automatically, rolling back production waits for a person, and moving one action to automatic touches nothing else.

What does the record keep, and for how long?

Months after an incident, someone asks who approved the rollback. If approval happened only in a chat thread, the scrollback is the record. Check which parts survive, and whether the acting agent can edit them. A dashboard of token counts is not the record; the record is the action, the analysis behind it, the approver and the cost, together under one ID:

With that, “who approved the March rollback” is a lookup. Without it, someone pieces the decision together from chat scrollback.

What can a run spend?

There are two answers that sound the same and aren’t: cost that is reported, and cost that is enforced. A dashboard tells you what a run spent after it spent it. A budget is only a boundary if something stops at it. On a playbook run, where the work is staged before anything executes, the cap halts the run and holds it, so an agent stuck in a loop pauses for a person instead of running up a bill.

What happens when it dies mid-action?

Once an action lands in an external system, there may be no clean way to reverse it. That’s true of anything that acts, including anything you build, and it’s the question demos never answer. One workable shape: runs checkpoint at stage boundaries and resume from the last completed one. A stage that was mid-action when it died checks what landed before it fires again, either by reading the target system back or by making the action safe to repeat. If it can’t prove what landed, it stops and holds for a person in an agent inbox.

Can you stop all of it, right now?

One run pausing at a gate is routine. The day something is wrong, a leaked key or a bad deploy, you need new actions stopped immediately and every active run brought to its next safe boundary without losing state. Ask what happens to external calls already in flight, because no stop can unsend those. A stop should freeze rather than kill: held runs keep their work and their record, so resuming after the all-clear is a decision instead of a rebuild. If the only stop you have is revoking keys, the work in flight is lost and nobody can say when it’s safe to resume.

What happens when the input is hostile?

An agent that acts on what it reads will eventually read something written to manipulate it: an error message, or a ticket filed by a stranger. A smarter model can’t close this, because reading instructions is the job. The protection is structural, and it’s the first two questions doing their work: the stage that reads untrusted text carries as little authority as its job allows, and the actions that matter sit behind gates on the way out. Ask what a poisoned input can reach and what it can trigger. If the answer depends on the model being careful, there is no enforced boundary.

How does it earn more autonomy?

Nothing should launch with the rollback button on automatic. The workable path is per-action: start with every consequential action held, let the record accumulate, and promote one action at a time. Before removing the hold, decide what would restore it: which failure classes the automatic checks must catch, and what error rate sends the action back behind the gate. This is where the record question pays for itself, because those thresholds only mean something against real run history.

How do you know it’s drifting?

Agents fail quietly: a prompt edit makes a judged gate lenient, a model update changes behavior, cost creeps run by run. The signals live in the record, if the record is real: gate rejection rates, held-action rates, cost per run over time. Baseline them by playbook and model version. Run the same fixed cases across a change before it ships, and decide in advance which shifts put an action back behind human approval. Watch the trends the way you watch error rates on a service.

Where the answers live

Five of the nine belong to each run:

The other four sit above any single run: the fleet-wide stop, the trust boundary around untrusted text, the per-action autonomy dial, and the trends in the run history. For what a receipt looks like on a real run, the seven-models review post shows one end to end.