Least Privilege for Agents

An agent's blast radius is exactly what its tools can do with the credentials they hold. Not what the prompt asks for, not what the model intends, not what the eval set covers — what the credentials permit at the moment a call executes. Scoping that surface is the most effective security work available on an agent, and it is entirely conventional engineering: scopes, identity, ceilings, rate limits.

It gets skipped for one reason, and it is worth naming because the reason is honest. A single service account with broad permissions makes every tool work on the first afternoon, and nine scoped credentials with nine sets of permissions do not. The work is a day. The alternative is a system where any one tool going wrong reaches everything the other eight could reach.

Per-Tool Credentials

Each tool gets its own credential, with the narrowest permission that lets it do its job. Sundry runs nine, and the discipline shows up most clearly in the read tools: search_orders holds a credential that can look up orders and cannot issue a refund, so a compromise anywhere upstream of it — a bug in the orders service, a bad deploy, a steered model insisting the search tool should also settle the case — produces nothing that moves money.

Read the third column as the actual security posture of the system. Each row is a sentence a reviewer can argue with, and the union of the rows is the worst a fully compromised run can do — which is the blast-radius statement Topic 64 asked for, written out per capability. With one shared service account the third column collapses into a single row that reads "everything in the other rows", and nobody can tell you what a wrong track_parcel is worth any more.

Acting as the Customer, Not as an Administrator

The most valuable single line in this topic is about who a read is performed as. A ticket has a verified customer — they authenticated to open it — and every read the agent performs on that ticket should be authorized against that identity, not against an argument the model supplied. The agent is not an administrator with a directory of 900,000 customers behind it; it is that one customer's session with a language model attached.

def authorize(spec, args, run):
    ctx = run.ticket                          # customer verified at ticket creation

    if spec.reads_orders:
        if not orders.belongs_to(args["order_id"], ctx.customer_id):
            return DENY, "order is not this customer's"

    if spec.name == "issue_refund":
        if args["amount_cents"] > 15_000:      # the $150 ceiling, in cents
            return NEEDS_HUMAN, "above ceiling"
        if run.refunds_issued >= 1 or ctx.refunds_issued >= 1:
            return DENY, "one refund per run and per ticket"
        if fleet.refunds_last_hour() >= 12:
            return NEEDS_HUMAN, "hourly refund cap reached"

    return ALLOW, None

In words: before any order is read, the dispatcher checks that the order actually belongs to the customer on this ticket, and refuses otherwise. No sentence anywhere in the context can make that check pass for somebody else's order, because the customer id came from authentication rather than from the conversation. The same check does a second job for free — it catches Chapter 8's grounding failures, where the model produced SU-88412, a well-formed id one digit from the right one and belonging to a different buyer. One control, two failure classes, and it is four lines.

This is where "the model can be induced to supply a different argument" stops mattering. Authorization by argument asks the wrong question — is this order id allowed — and the answer depends on text. Authorization by identity asks whether this customer may see this record, which is a fact about the world that the conversation cannot reach. Any read tool your agent has should be scoped this way before it goes anywhere near production.

Ceilings in Code

The $150 ceiling has been in this book since Chapter 1 and has moved exactly once — out of the prompt and into the dispatcher, in Chapter 5, the day the code started rejecting those calls. It belongs in the same function as authorization for one reason: the check needs the amount, the ticket and the customer at the same moment, and that moment is when the call executes. The model's own judgement about whether $220 is reasonable in this case is not part of the computation. A ceiling in the prompt is a suggestion one convincing paragraph away from a full refund; a ceiling as an integer comparison on amount_cents has no paragraph-shaped input at all.

Rate and Volume Limits

A ceiling bounds one action. Volume limits bound a bad afternoon. Sundry runs three, at three different scopes: one refund per run, one refund per ticket, and twelve refunds per hour across the whole fleet with a page at eight. The first two stop a single steered or looping run from repeating an action — the double refund of Chapter 3 was a retry rather than an attack, and the same limit catches both. The third is the one that turns a systematic problem into a bounded incident.

Pick the fleet number from the traffic rather than from instinct. Sundry handles about 4,200 tickets a week, roughly 25 an hour averaged round the clock, and refunds land on a small share of them; twelve an hour is comfortably above any legitimate peak and far below what an unbounded compromise would produce in the two hours before somebody looked. When the cap is reached the queue does not stop — refunds route to a human instead — which is the difference between a limit that protects the business and one that takes the support queue down at four in the afternoon.

Human-Only Actions

Some actions are not on the dial at all. At Sundry the agent may never refund above the ceiling, alter a seller's payout or bank details, cancel or modify a seller's listing, delete or merge a customer account, or issue anything in bulk. The enforcement is not a rule in the prompt saying it must not; it is that no tool in the surface does those things and no credential the agent holds can reach the endpoints that do — so when a reviewer approves a refund above the ceiling, that person issues it in the finance system on their own credentials, and the agent's run records the outcome without ever having been able to perform it. A capability the agent does not have cannot be talked into existence, which makes this the cheapest control in the chapter and the one most often replaced with a sentence.

Reviewing the Surface

Chapter 3 established that the tool list is a design artefact and gets reviewed when it changes. This topic adds one column to that review: for each tool, what could this do at worst, answered in writing and kept next to the code. Sundry's document is two pages and the review takes twenty minutes, because most changes touch one row of it. The value is in the rows nobody would have written down otherwise — that message_seller is an outbound channel as much as a communication tool, and that get_order is a read tool that imports a stranger's prose.

Run the review whenever a tool is added, whenever a credential's scope widens, and whenever a new consumer picks up a shared server, because the second consumer inherits the surface without inheriting the reasoning behind it. A tool list that grew by four entries over a quarter with no review is a permission set nobody has read as a whole — and the whole is the only thing an attacker is interested in.