What “approval-gated” means
An approval gate is a deliberate checkpoint before an action crosses a defined risk boundary. Low-impact reads may proceed directly, while changes such as deleting a file, sending a message, changing system configuration or elevating privileges can require a preview and confirmation.
The point is not to interrupt every click. The point is to align the amount of friction with the possible consequence.
Good gates operate on concrete actions
“Allow AI access” is too broad to be useful. A stronger request names the action and target: read this folder, run this executable with these arguments, edit this file, create this firewall rule, send this prepared message. The user or supervising policy can then understand what is being approved.
Four controls that work together
Scope. Restrict files, tools and network targets to what the task needs.
Preview. Show the intended change or command before high-impact execution.
Confirmation. Require explicit approval when the consequence is difficult to undo, security-sensitive or externally visible.
Audit. Record the tool, target, result and time so later review is possible.
Reversibility matters as much as permission
A confirmation dialog does not make a destructive design good. Prefer reversible operations: archive before permanent delete, record an existing firewall state before changing it, checkpoint source before a risky edit and preserve the previous configuration when rollback is practical.
Why unrestricted shells are hard to govern
A general shell is attractive because it can do almost anything, but that flexibility makes policy enforcement harder. Narrow tools with typed targets and explicit arguments create a smaller, more understandable surface. General execution can still exist for expert workflows, but it should be treated as higher authority.
Human approval is not the only gate
Policy can reject an action before a person ever sees it: outside an approved directory, unsupported executable, missing timeout, unsigned module or operation that violates a standing rule. The goal is to make safe actions easy and unsafe ambiguity visible.
This is the design direction behind ARKTOR: a small auditable core with modular capabilities and explicit boundaries. The historical SC Node project remains an open-source proof of the earlier controlled-runtime approach.
When should an agent ask?
- Before destructive or difficult-to-reverse changes.
- Before sending data to a new external destination.
- Before using elevated privileges when standard rights are insufficient.
- Before acting on behalf of the user in externally visible systems.
- When the target is ambiguous or broader than the original request.
For the operating-system side of this model, see What Can an AI Agent Access on Windows?. Good agent control is ultimately an authority-design problem, not a prompt-writing trick.