“Are you sure?”
Yes, bro. About what, exactly?
A confirmation button isn't much help if the user cannot see the action, destination or likely effect.
As assistants gain tools, the interesting question isn't whether they can run commands. It's which decisions we are comfortable delegating, under which conditions.
Don't classify risk by how short the command looks
A long query might only read a local test table. A tiny command might change a production permission.
Likewise, “read-only” does not always mean harmless: reading a credential file and sending its contents somewhere can expose a secret without changing the original file.
I would start an approval design with these questions:
- Which environment is affected?
- Is the action reversible through an ordinary, tested process?
- Could it expose confidential data?
- Does it alter access, billing, availability or persisted records?
- Is the target bounded, or can it expand unexpectedly?
A proposed decision table
This is a starting policy to adapt, not a universal permission standard:
| Example action | Possible treatment |
|---|---|
| Read synthetic lab logs | Allow within a scoped tool |
| Inspect production service health | Allow only through approved, limited access |
| Prepare a deployment diff | Allow preparation; review before applying |
| Change production access rules | Require specific human approval |
| Delete retained customer records | Require the authorised workflow and explicit approval |
| Send logs to an external service | Review the contents, destination and data-sharing permission |
OWASP's AI Agent Security guidance discusses scoped tools and human oversight. The practical challenge is turning those principles into permissions your system actually enforces.
Make approval a decision, not a reflex
A useful request would say:
“Apply this reviewed configuration change to the staging service. It changes these two values. The rollback is this previous configuration.”
That gives someone a decision they can inspect.
Compare it with “Proceed?” after a wall of terminal output. That's less informed approval and more an endurance test.
I would also bind approval to the reviewed action. If the target, payload or permissions change, the old approval should not become a blank cheque.
Where would you draw the boundary for your own team: what can an agent execute independently, and what must always return to a human? A concrete example is more useful than “never trust AI” or “automate everything.”
Draft prepared with AI support. The table is an illustrative policy discussion, not a record of a deployed access-control system.
#AI #Security #DevOps #Discuss
