Agent permissions and sandboxing

Assume the model will, at some point, decide to do the worst thing its tools permit. Not because it is malicious, but because some text it processed persuaded it, or because it misread a situation.

Once that is the assumption, security stops being about prompt wording and becomes an ordinary authorisation problem — which is good news, because that is a problem the industry knows how to solve.

It is the same move as treating user input as hostile in a web application. Nobody argues about whether a particular user is trustworthy; the input is validated regardless, and agent capability deserves the same unconditional treatment.

Every tool you expose is a capability grant. The common mistake is exposing a general-purpose tool — run this query, call this endpoint, execute this command — because it is easier than writing several specific ones.

A general tool is an unbounded grant. `run_sql(query)` gives the agent your whole database; `get_applications_for_candidate(id)` gives it exactly what the task needs. Specific tools are more work to write and they are the actual security boundary.

The test to apply to each tool is what its worst legitimate-looking invocation could do. If the answer involves data belonging to someone else, or an action nobody could undo, the tool is too broad regardless of how carefully its description is worded.

• Task-shaped tools, never general execution primitives
• Parameters constrained by type and range, validated server-side
• Read and write separated into different tools
• Destructive operations behind an explicit confirmation path
• Nothing that accepts raw code, SQL or shell input

An agent acting for one candidate should hold a credential that can only reach that candidate’s data. Giving it the service account and relying on it to filter correctly means one reasoning error becomes a data breach across every user.

This is the control that turns a catastrophic failure into a contained one. It is also the one most often skipped, because service credentials are simpler to wire up during development and nobody revisits it.

The practical implementation is to mint a short-lived, scoped token per run rather than reading a long-lived secret from configuration. It also gives you revocation and an audit trail for free, both of which you will want during an incident.

If an agent runs code, browses the web or operates a desktop, it needs isolation with nothing valuable inside it: a container or virtual machine, no standing credentials on disk, restricted network egress, and a clean state per session.

Egress restriction deserves emphasis. An agent that can reach any host can exfiltrate whatever it holds, and exfiltration is the goal of most injection attacks. An allowlist of destinations turns a successful injection into a failed one.

Clean state per session matters more than it appears. An agent that retains files, cookies or a browser profile between runs carries one user’s session into another’s, which is a data leak that no amount of prompt discipline prevents.

• A fresh container or VM per session, destroyed afterwards
• No long-lived credentials written to disk inside it
• Network egress limited to an allowlist of required hosts
• Resource ceilings so a runaway process cannot exhaust the host
• No shared browser profile, cookie jar or cache between users

Autonomy needs ceilings that are enforced in code rather than requested in a prompt: maximum steps, maximum tool calls, maximum spend, maximum wall-clock time. A runaway loop is the most likely incident you will actually have.

Also bound repetition. An agent calling the same tool with the same arguments five times is stuck, and continuing costs money without progress. Detecting and halting on that is a small piece of code that pays for itself the first week.

Decide in advance what happens at the ceiling. Stopping silently produces a task that nobody knows failed; escalating with the trace and the partial state produces something a person can finish. The second is barely more work and considerably more useful.

The strongest structural control available is splitting the component that consumes untrusted content from the component that can act on the world. One reads and proposes; the other validates and executes.

The reader holds no tools at all. It returns a typed proposal — this posting, these fields, this recipient — and a separate validator checks that proposal against policy: is the recipient in the allowed set, is the posting one the user selected, is this action on the confirmation list.

This is what makes a successful injection harmless rather than merely less likely. The model can be completely persuaded and still have no path to an action, because the persuaded component was never the one holding the capability.

When something goes wrong the question is always which input caused which action. That is unanswerable unless you logged the assembled context, every tool call with its arguments and result, and the final output.

Retain enough to replay a session. Teams that log only errors discover that the interesting failures produced no error at all — the agent did something wrong, successfully.

Balance that against what the logs now contain. Full agent traces hold personal data and sometimes credentials in tool arguments, so redact at write time and set a retention period deliberately rather than keeping everything indefinitely by default.