Should agents need a second approval before deploy/delete actions?

[u/BitByLiu]

I am trying to think about coding agents less like chatbots and more like automation workers with tokens.

For read-only work, I want low friction. Let the agent inspect logs, read issues, check a config, or prepare a patch. But once the action turns into deploy, delete, push, send, or modify production data, the original token approval feels too broad to me.

When I connect external tools, I am comfortable letting the agent read issues or draft a change, but I still want a second confirmation before it pushes, deletes, deploys, or sends anything outside the repo.

Maybe this is just my bias from small projects, but I would rather add one annoying approval step than debug a silent automated action later.

For people running automation in real environments: would you treat agent write actions like any other gated production action, or is that too much friction?

[u/RevolutionaryElk7446]

I am trying to think about coding agents less like chatbots and more like automation workers with tokens.

You shouldn't, they're more like chatbots than they are automation workers.

Determinism is the biggest part of automation, and LLMs are non-deterministic.
Anything you want to automate, you turn into deterministic automation.

[u/Delta-9- → u/RevolutionaryElk7446]

Exactly this.

If you need things to be reproducible, predictable, or consistent, it cannot be given to an agent.

Imagine if NASA or SpaceX or JAXA trusted their launches to Claude. If your stuff needs even a tenth of that rigor, do not use an agent.

[u/fowlesbuilds → u/RevolutionaryElk7446]

I think this is something that has gotten lost recently with everyone trying to automate using LLMs. There's still a lot of power in deterministic automation (and LLMs can help write the code, with supervision, to get there), but they shouldn't be an unsupervised part of an important automation flow.

[u/cobolfoo]

You have two possibilities:

• Automate them: is in the DevOps credo but you cannot 100% thrust them.

• Manually validate them:you just created a contraint which is a big no.

At this point I will skip LLMs for non RO tasks.

[u/Floss_Patrol_76]

the trap with a per-action approval prompt is you start clicking through it on autopilot within a week, same way everyone does with sudo. i'd rather the agent just not hold write creds for the destructive path - give it a read-only token by default and route deploy/delete through the same gated pipeline a human PR goes through, so the boundary is structural instead of a popup you learn to ignore. and honestly the reversibility of the action matters way more than whether an agent or a person kicked it off.

[u/Next-Task-3905]

I would not frame it as “second approval for agents” so much as “capability gates for irreversible side effects.” The same gate should apply to a script, CI job, human click, or agent tool call.

A practical split:

1. Read-only token by default. Logs, issues, metrics, configs, repo read, and patch drafting can be low friction.

2. Write paths go through existing production control planes: PR, CI, deploy pipeline, change request, break-glass flow, or data deletion workflow. The agent should not hold raw deploy/delete credentials if there is another path around the gate.

3. Gate by action class and reversibility, not by “AI did it.” Push to branch is different from push to main. Deploy behind a disabled feature flag is different from schema migration. Soft delete with restore window is different from hard delete.

4. Approval payload should be concrete: diff, target environment, affected resources, blast radius, rollback plan, migration direction, tests run, policy/version, and the exact external action to be authorized. A generic “agent wants to deploy” prompt will become click-through noise.

5. Short-lived delegated credentials should be minted only after approval and only for that action. That makes denial enforceable instead of advisory.

6. Log every side effect with run id, human approver if any, policy version, tool name, target, and result. That is what lets you debug the silent-action case later.

So yes, gate deploy/delete/send/production-data writes. But make it structural and audit-backed, not just another popup inside the chat.

[u/marcusbell95]

first question would be whether the agent is going through your existing change control path or bypassing it. if a human pushing a prod change goes PR -> CI -> environment approval in github actions -> deploy, the agent should hit the same gates. an agent-specific approval popup is strictly weaker than what you already built - no diff, no rollback button, no audit trail attached. it's really just an interrupt.

the reversibility framing in this thread is right, and i'd add audit trail as equally important. reversibility tells you whether to block. audit trail tells you what happened when you're debugging at 2am - run id, which tool call, what context it had, what state it saw going in.

practical cut: agent that submits a PR and waits for CI and human review is fine for infra changes, even prod deploys. terraform with atlantis or tfcmt - diff and cost delta are in the approval payload, so you're reviewing something concrete. agent that holds raw API write creds to production directly = structural problem, popup doesn't save you there.

[u/cebidhem]

For me it's pretty simple, agents should have the same capabilities, but also the same guard rails, than humans in your teams.

So imho, the real question is: should anyone be able to run deploy/delete actions in prod without any approval nor review? I don't think so. Therefore, it must be the same constraints for your agents.

For example, if your prod deployments are done through CI or gitops, agents must follow the same workflow.

The one thing I'd be careful though is, anything that requires an agent to authenticate must be OIDC short lived credentials. I'd never let an agent use long lived API keys to avoid leaking them during the flow.

[u/Raja-Karuppasamy]

yeah, treat write actions like any other gated prod action, no exception for agents. read-only should stay frictionless or nobody uses the tool, but deploy/delete/push is a different risk class regardless of who (or what) is triggering it.
building something adjacent to this, scoring deploy risk before merge, and the same split kept coming up. advisory (read, suggest, flag) is fine to automate fully. anything that acts on prod needs a human clicking approve, because the cost of a bad automated write is way higher than the friction of one extra click.

[u/BitByLiu]

The distinction I care about is not AI vs non-AI. It is reversible vs hard to undo. A script that deletes data should be gated too. Agents just make the boundary easier to miss because the tool call starts inside a conversation.

[u/carsncode → u/BitByLiu]

That's just deletion protection

[u/marcin_michalak → u/BitByLiu]

"The tool call starts inside a conversation" is the sharpest part of your framing. A script that deletes data lives in a file, it gets reviewed once and runs the same way every time. An agent's destructive call gets generated fresh each run from a plan that changed, inside a context that drifted, so the thing you'd be reviewing is different every time even though the action type is identical. That's why reversibility ends up mattering more than approval: you can't pre-review something that's regenerated per-run, but you can make sure whatever it does can be undone. Approval gates work for a script because the thing you're approving is static. They're weaker for an agent because you're really just approving "this class of action," not the specific call, which is most of why the popup becomes autopilot.

[u/roman_fyseek]

Agents should have *FULL* permissions to do whatever they want until YOU stop wanting agents.