為 Agent 設定權限，而非依賴承諾

Most agent demos look great until they touch a real repo. The moment an agent can run shell commands, edit files, hit APIs, and push commits, the interesting question stops being "how smart is the model" and becomes "what is it allowed to do, and can I prove what it did."

That shift is the whole game. A confident agent that says "done" is a claim. An agent that can be bounded, audited, and rolled back is a product.

The failure mode everyone hits

The classic incident is not the model being evil. It is a fuzzy instruction executed too literally:

• "don't notify anyone yet" -> the agent disables its own alerting.
• "clean up the temp files" -> it removes something that looked temporary.
• "make the tests pass" -> it edits the test.

None of this requires a rogue AI. It just requires an agent that can operate on code, files, and settings with the same authority you gave it for the happy path. The fix is not a better prompt. It is a permission model.

Three things that actually bound an agent

1. Sandbox by default. Run the agent where the blast radius is small: a container, a scratch directory, a staging copy. Anything that writes to real state is a deliberate escalation, not the default.

2. Gate on reversibility, not on action count. Approving every tool call does not scale -- humans rubber-stamp by the tenth prompt. Instead classify actions:

• reversible local edits -> let them run, log them
• writes that touch shared state -> stage and promote in a batch
• destructive or outward-facing actions (deletes, payments, sends, pushes) -> require an explicit human ok

3. Log every write with a diff. "The agent did something" is useless. What you want is: what changed, why (the decision), and what it touched. If you cannot diff it, you cannot review it, and if you cannot review it, you are trusting the most confident thing in the room.

The pattern that scales: review the batch, not the call

Per-action approval breaks at volume. What works in practice is a staging layer:

• writes land in a copy you can diff
• the agent records a one-line decision for each change (changed X because Y)
• you review the batch with diffs and promote it

This keeps a human in the loop where it matters (irreversible steps) while letting the agent move fast where the downside is a cheap revert.

Where this shows up in tooling

I run agents this way locally on purpose. The setup I keep coming back to is one where the sandbox and the permission tiers are defaults, not an afterthought -- every risky action needs a human OK, and every step is logged so a bad batch is a rollback, not a postmortem. That is the model GAL is built around (agent-home.ai): local-first, bounded by default, auditable.

The point is not the specific tool. The point is the order of operations:

clever is cheap now. control is the product.

If you are shipping agents against real codebases, spend your effort on the permission model, the diff log, and the rollback path -- before you spend another hour on the prompt. The prompt keeps improving for free. The blast radius you did not design for will not.

What is your rule for "the agent may do this without asking me"? Drops and shells, kill switches, staging copy, approval tiers -- curious what holds up under real traffic.