Credentials: standing keys against task grants

Credentials: standing keys against task grants

The standing grant in C1 and C2 is what most systems do: one broad credential for the whole session. It holds five permissions, including payments:refund and tickets:close, and it is valid whenever the session is.

The task grant in C3 is minted by a small broker for one purpose: "view" gets tickets:read; "note" adds tickets:append; "refund" gets payments:refund plus a cap and one allowed change. It also expires:

t=0:   allowed (ok)
t=299: allowed (ok)
t=300: denied (grant expired)
t=900: denied (grant expired)

Why this is better, in plain terms: the question to the broker ("what does this task need?") is asked before the model reads any untrusted text. The grant is then fixed. Text that arrives later, however persuasive, cannot widen it.

Approval is a control only if people can use it

The gateway can ask a person before close_ticket and refund. Whether that helps depends on how often it asks and what the person sees. Prompts per 100 tasks, for an assumed mix (60 views, 25 notes, 10 closes, 5 refunds; I made the mix up, so use your own):

A person shown 100 prompts a day will click "yes" on the 100th without reading it. That person is the rubber stamp of setup C2. The design aim is to ask rarely, and only when it matters:

• Do not ask for what code can refuse. If a cap or a scope would say no, say no, and spare the person.
• Do not ask for what is harmless or undoable. Reads and appended notes need no prompt. (Appending is undoable by an operator; "edit any note" is not, and would be a different tool.)
• Ask for the irreversible or the costly: closing, refunding, sending, deleting.
• Show what will happen, in words, with the arguments: "Close ticket 5 ('Duplicate charge') for Ben Okoye". Not "the agent wants to run close_ticket. Approve?"
• Say no safely. A rejection comes back as text: the person did not approve this action; do not retry it; tell them what you wanted to do and why. The model must not loop on a "no".

Which control is doing the work?

Start from C2 (standing grant, a person who approves everything) and switch off one control at a time, then run the same eight requests:

Three lessons:

1. Each control stopped something the others did not. There is no single magic one. That is why the gateway has ten gates and not one.
2. The person was the weakest control here (and in a real team, always check how much it is worth). The hard limits (cap, scope, row, quota) did the work.
3. This is a toy experiment with a scripted attacker. It shows what each control is for, and not how much real protection each gives.

A refusal should help the model do the next right thing

When the gateway says no, the model reads the text and decides what to do. A good refusal says what was wrong and what to do; it does not leak internals. From the example:

Compare with a raw database error or a stack trace, which tells a model nothing useful and tells an attacker how your system is built. (Module 6 covers the same for an MCP server: tool errors should tell the model what to do next.)

The cost of narrow tools, and how to pay it

C did 6 of 7 honest tasks. The seventh ("open tickets on each plan") needs a report, and there is no tool for it. You have four honest options:

1. Add a narrow tool for that report (open_tickets_by_plan()), run through the same gateway. This is the normal answer; tool lists should grow by need.
2. Expose a prepared view with only safe columns, through a tool with a fixed query. (Exercise Medium 3.)
3. Hand off to a person or a different, more privileged workflow that has its own approvals. The support agent says "I can't do that; here is who can".
4. Offer a broad tool, behind a strong gate, for a different, trusted audience (for example a data analyst working through their own read-only replica with their own credentials). Not for the agent that reads customers' tickets.

Lint the tool list

Many of these problems can be found by reading the tool list, before any run. lint.py checks a list of tools for smells:

Results: the SQL tool trips three rules (free-form-input, broad-description, and for the read-write version write-without-approval); the narrow set trips none. A tool list such as transfer(account_id, amount) with no scope, no cap and no approval, run_shell(command), delete_ticket(ticket_id) and get_user(user_id) trips ten findings, six of them rated high.

A linter is not a proof. It finds the shape of a problem; it cannot tell you that a tool's own code is wrong. Use it as the first review, and in continuous integration so that a new tool cannot arrive without a scope and a row check.

A checklist

1. Narrow tools: one job each, no free-form code or query fields, no argument the model need not choose.
2. Read-only by default. A write is a separate tool with its own permission.
3. Reads are not free: limit what is returned (columns, rows), not only whether writes are possible.
4. Scopes: every tool names the permission it needs; a grant lists the permissions it has.
5. Row scope comes from the grant, set by your code, not from model-chosen arguments.
6. Limits in code: caps, quotas, rate limits. Check them before asking a person.
7. Grants per task, short-lived, with an expiry and an audience.
8. Approval for the irreversible or costly, shown in words, asked rarely, and a "no" returned as guidance.
9. Refusals say what to do next and leak nothing.
10. Log every call, allowed or denied, with the reason.
11. Lint the tool list in CI and test the controls with attack tasks, not only happy paths.

Levels 9 and 10 return to measuring and attacking all of this: a poisoned ticket is prompt injection, and the combination of private data, untrusted text and a way to send data out is the case that most needs these controls.