Agent Permissions and Action Boundaries: Keeping Tool Use Bounded and Reversible

The moment you give an agent a tool, you stop deciding what it does and start deciding what it is allowed to do. The real design question is not "can the agent act?" but "what happens when it acts wrong?"

The Permission Question Is Not About Trust

When builders first wire up an agent with tools, they tend to ask the wrong question: How much do I trust this model? That framing leads to vague hopes, long system prompts begging the model to be careful, and a false sense of safety when the model behaves well in testing.

Here is the reframe that matters: an LLM reasons, but the platform governs. The agent proposes an action; your permission layer disposes of it. Agent safety is decided at the tool boundary, not by hoping the model behaves.

Think of it this way. Tool calling gives the agent the ability to act. This article is about deciding which actions it may take without a human in the loop. Every tool call should pass through a gate that answers one question: Is this action allowed to happen automatically?

The gate has three outputs:

• Allow — the action executes without human review.
• Ask — the action waits for approval.
• Deny — the action is blocked outright.

That simple decision point is the entire game. Your job as a builder is to sort every tool action into one of those three buckets before the agent runs unattended.

Reversibility First: The Test That Sorts Most Actions

Start with the single most useful criterion: Can this action be undone?

Run every tool action through the reversibility test. If the action fails or turns out wrong, can you restore the prior state cheaply? The answer sorts most of your tool surface immediately.

High-reversibility actions are the easy wins:

• Reading data
• Drafting text
• Running a search
• Generating a file in a scratch directory
• Computing something expensive but harmless

Low-reversibility actions deserve gates:

• Sending an email
• Deleting records
• Transferring money
• Publishing content
• Modifying production data

Notice something important: reversibility is not the same as "danger." A destructive action inside a sandbox is fine, because you can throw the whole environment away. A read-only action against the wrong system can leak sensitive data, and leaks are effectively irreversible. So the test is not "is this tool scary?" It is "what happens to the prior state if this action is wrong?"

Reversibility is a property of the action plus its environment, not the tool alone. Deleting a file in a throwaway container is reversible. Deleting the same file in production is not. You cannot classify tools in the abstract; you have to classify them where they actually run.

Impact and Blast Radius: When Reversibility Is Not Enough

Reversibility gets you most of the way, but not all the way. A reversible action can still be costly. Mass emails can be recalled only with embarrassment. Bulk writes can be rolled back, but the rollback itself takes hours. Expensive compute burns money even when the output is discarded.

So add a second axis: impact. If this action goes wrong, how much damage or cost does it create?

Now you have a two-axis model:

Work through a realistic example. A customer support agent has three tools: read tickets, draft replies, and send replies to customers.

• Read tickets — low impact, reversible. Allow.
• Draft a reply — low impact, reversible. Allow.
• Send the reply — high impact, irreversible. Ask.

That third gate is the difference between an agent that helps you and an agent that apologizes to a customer on your behalf. The drafting can be fully automated; the sending needs a human finger on the button.

One common mistake: treating "the agent only reads" as automatically safe. Read access to sensitive customer data is not low impact just because it produces no side effects. The impact is the leak itself. Privacy decisions are their own topic, but the boundary belongs here: a read-only tool pointed at the wrong data is still a high-impact action.

The Matrix Is a Starting Heuristic, Not a Complete Policy

The two-axis matrix sorts the obvious cases quickly. It is not a complete permission algorithm. Real decisions carry constraints that do not fit neatly into a reversibility-and-impact grid.

Treat the matrix as a first pass, then apply an override rule: deny or ask when authorization, target ambiguity, data sensitivity, cost or rate limits, or verification is unresolved.

Consider a few cases where the matrix alone would mislead you:

• Authorization. An action may look reversible and low impact, but the agent has no authority to perform it. Reading a colleague's private inbox is low impact on your systems and trivially reversible. It is still a policy violation.
• Target ambiguity. The agent may be about to act on the wrong target. Deleting a file in a staging directory is reversible and low impact — unless the agent resolved the wrong path and is actually deleting from production.
• Data sensitivity. A read-only lookup can be low impact against a public catalog and high impact against customer records. The same tool, different data.
• Cost and rate limits. A reversible action that triggers thousands of expensive API calls is low impact per call but high impact in aggregate.
• Verification. If you cannot confirm the target, parameters, and intended outcome before execution, unresolved uncertainty should move the action from allow to ask or deny — even when it appears reversible.

The matrix gets you to the right neighborhood. The override rule keeps you from implementing a mechanical lookup table.

Least Privilege: Give the Agent the Narrowest Tool It Needs

Reversibility and impact tell you how to gate each action. Least privilege tells you which actions should exist at all.

The principle comes from security engineering, and it translates directly to agents: give the agent the smallest set of tools and scopes that still completes its task. Not the smallest set you can imagine. The smallest set the task actually needs.

Why does this matter beyond accidents? A narrower tool surface means fewer places for a confused agent — or a prompt injection attack — to cause harm. Every tool you grant is another door. Least privilege is the practice of locking the doors the agent does not need.

Concrete scoping moves:

• Use read-only credentials where the agent does not need to write.
• Restrict file access to specific paths, not the whole filesystem.
• Allow-list domains for web access instead of granting open network calls.
• Constrain parameters, not just tools. If the agent needs to send email, restrict the recipients list rather than granting a general send tool.

The tension is real: least privilege costs setup effort, and it can block legitimate tasks when you scope too tightly. That is fine. Scope to the task you actually have, not to the theoretical maximum the agent might someday need. You can always widen the boundaries later, deliberately, when a real task requires it.

The common failure mode is granting broad access because it is easier, then discovering the agent reached a tool you never intended it to touch. The setup time you saved comes due later, with interest.

Approvals Are a Layer, Not a Default

Once you have sorted actions by reversibility and impact, where does human approval fit?

Not everywhere. If the agent asks for confirmation on every step, you have built a slow chatbot, not an agent. The approval prompt becomes noise, and noise trains people to click through without reading. An approval gate that nobody actually reads is worse than no gate at all, because it creates the illusion of safety.

Approval earns its place at the decision boundary where uncertainty, impact, or irreversibility is high. That is the same boundary where human review belongs in any LLM workflow. The difference here is mechanical: you are encoding that review as a permission rule, not deciding where review belongs in the abstract.

The practical pattern is to allow the safe majority of actions automatically, gate the risky minority behind approval, and deny the rest outright. The exact ratio depends on your domain. A research assistant summarizing public documents can run nearly unattended. A support agent that sends messages to customers needs a heavier gate.

Common mistake: Treating "ask every time" as the safe default. Over-approval does not make the agent safer. It makes approvals meaningless.

A Practical Permission Review for Your First Agent

Before you let an agent act unattended, run this review. It takes an afternoon and it will save you from the kind of incident that erodes trust in the whole approach.

Step 1: List every tool. Write down every tool the agent can call and what each action actually does to your system or data. Not what the tool description says. What it does.

Step 2: Run the reversibility test. For each action, in its real environment, ask: if this is wrong, can I restore the prior state cheaply?

Step 3: Estimate impact. Sort every action into the allow / ask / deny matrix. Be honest about blast radius, including data exposure.

Step 4: Apply the override rule. For each action that looks reversible and low impact, check authorization, target ambiguity, data sensitivity, cost or rate limits, and verification. Move the action to ask or deny if any of those conditions is unresolved.

Step 5: Trim the tool list. Remove every tool the task does not need. Narrow the scopes on the tools that remain.

Step 6: Test the boundaries. Decide where approval gates sit, then test the agent against a deliberately wrong or malicious instruction. Watch what it tries to do. Adjust the gates.

There is also a when-not-to-use dimension. If the agent runs in a fully sandboxed, throwaway environment — a container that gets destroyed after every run — you can relax the gates for effects the sandbox actually contains. But isolation only reduces consequences within its own boundary. Deleting a scratch file may be disposable; sending a request, exposing a secret, or spending external resources still needs its own gate. The moment the agent touches production systems, real user data, or anything that outlives the session, tighten the boundaries.

The Durable Rule

Here is the decision rule to carry forward: scope every agent action by reversibility first, impact second, override with authorization and verification checks, and grant the narrowest tool set that still completes the task.

Write down your agent's tool list. Run each action through the allow / ask / deny matrix. Check the edges the matrix cannot see. Then, and only then, let it act unattended. The model will propose plenty of actions you did not anticipate. Your permission layer is what decides which of them ever happen.