What AI Agents Can Decide on Their Own – and When I Want to Be Asked

An AI agent can read files, run programs and prepare changes. With the right permissions it can also delete data, spend money or publish something. So the question is not just what it can do, but what it is allowed to do for this task.

I work with agents on several machines. One practical rule has emerged: the harder the consequences are to undo, the more important narrow permissions and a deliberate decision become. The approach below is how I work and a starting point for your own rules, not a general security guarantee.

One question before the agent starts

Suppose a machine is short of disk space. An agent finds a large cache and proposes removing it. That sounds harmless. Whether it is depends on who owns the data, what the cache contains and whether a build is currently using it.

In my control room for six machines, I separated proposals from execution. The agents report what they found. Only predefined commands suited to a machine's role can run, and only after my approval. An approval covers a particular proposal and answer.

This does not solve every security problem. I also documented that an open enrolment link for a new passkey presents a risk. A safeguard is only as good as its boundaries and its actual implementation.

Four practical levels

The right boundary depends on the task. For a first overview, I find this distinction useful:

“Local” does not automatically mean harmless: a local file might be the only copy or be in use by another program. Reading a file can expose confidential information too. What matters is the effect, the data and the permissions, not just the tool.

What a useful approval should contain

A simple “May I clean up?” is not enough for me. Before deciding, I want to know:

1. What exactly? Which machine, folder or service is affected?
2. Why? What problem is the action meant to solve?
3. What are the consequences? What will change or be deleted, and what might it cost?
4. What was checked? What evidence supports the proposal, and what remains unknown?
5. How can we go back? Is there a backup or another clear recovery path?

A proposal could read: “The build cache on machine A is taking up a lot of space. I suggest removing only that cache. An active build might be affected, so I will check running processes first. The cache can be regenerated, though that may take time.” Only actual findings turn this into a decision brief; these details are an example.

An agent needs suitable permissions, not just good instructions

An instruction such as “Please do not read secrets” helps coordinate work. It does not replace access control. If an agent can technically access production keys, a mailbox or a payment function, an erroneous action there can have consequences.

For each task, it is worth checking:

• Which files and services does the agent actually need to reach?
• Can it start with read-only access or in a separate working environment?
• Which actions should technical permissions or separate approvals restrict?
• Where are results and failed attempts recorded without unnecessarily logging keys or personal data?
• Who checks the result, and how is a change reversed?

My general approach to credentials is in Keeping API keys and passwords safe when using AI (German).

A green result is not proof of an outcome

When an agent says “done”, I look for suitable evidence. For text, that might be the saved file. For a program, an appropriate test. For a website, the display in the intended environment. A successful build shows that the build ran; it does not prove that a real customer message was delivered.

An approval button does not prove a system is secure either. That requires checking permissions, implementation, possible bypasses and recovery, among other things. The depth of that work depends on the potential harm.

A checklist for your first task

• State the goal and permitted files or services in one sentence.
• Distinguish reading, local preparation and external changes.
• Restrict secrets and personal data to what is necessary.
• Set a specific approval point for deletion, publication, spending and production data.
• Before approval, inspect the affected resources, consequences and recovery path.
• After the action, verify the result in the appropriate place and record open points.

AI agents can take a lot of work off our hands. Responsibility for their instructions and permitted effects stays with us. For me, the answer is clear boundaries and verifiable results, without unnecessary interruptions.

Read next: Six machines, one control room · Using Claude Code and Codex together.