Tool Permissions as a Second Line of Injection Defense

A tool permission is only meaningful if it names three things: what action, on what object, with what authority. Most agent frameworks collapse all three into a single "tool" with an inherited credential, which is why a hijacked agent can do far more than the task required.

Split each tool into a verb and a resource. A verb is one of a short closed list: read, list, create, update, delete, send, pay, deploy. A resource is one named object: repo:org/app, bucket:reports-prod, inbox:user-42, payee:vendor-9. The tool surface then becomes a matrix rather than a bag of functions.

The right-hand column is the part teams skip. The reversibility question is what makes a confirmation gate affordable: you only pay the friction on the verbs you cannot undo.

Credentials should follow the same shape. If a tool call names bucket:reports-prod, the credential presented with that call should be scoped to that bucket and nothing else. This is the standard least-privilege argument applied to non-human identities, and it is the same argument practitioners already make for service accounts in ordinary infrastructure: grant only the tools, credentials and data scopes the task needs (Cequence on agent least privilege).

Containment needs an enforcement point. Put a deterministic gate between the model's proposed tool call and the side effect. The gate does not read the model's reasoning; it reads the structured call and the caller's identity, and it decides.

A workable shape, in pseudo-code:

POLICY = {
    ("read",   "repo:*"):            "allow",
    ("update", "repo:*"):            "allow_if_owned",
    ("send",   "channel:*"):         "confirm",
    ("delete", "record:*"):          "confirm",
    ("pay",    "payee:*"):           "confirm_and_cap",
    ("deploy", "service:prod"):      "confirm_dual",
}

def authorize(call, principal, context):
    rule = POLICY.get((call.verb, call.resource.generalized))
    if rule == "allow":
        return Decision.allow(call)
    if rule == "allow_if_owned":
        return Decision.allow(call) if call.resource in principal.owned else Decision.deny("not owner")
    if rule in ("confirm", "confirm_and_cap", "confirm_dual"):
        ticket = open_confirmation(call, principal, context)
        return Decision.pending(ticket)
    return Decision.deny("no policy")

Two properties matter more than the specific rules. First, the default is deny: an unlisted verb and resource pair does not execute. Second, context is operator-supplied metadata, not model-supplied text. If the model can write into the field the gate reads, the gate is decorative.

The empirical case for that split is strong. NetInjectBench evaluated tool-using agents on 240 attack instances across three model families and found naive execution reached an 82.50% unsafe tool-action rate. Prompt-only safety defenses cut that to 25.63%, a two-pass LLM judge to 10.00%, and static allowlisting to 5.00% but blocked every approved change, for 0.00% usefulness on approved cases. A metadata-aware policy gate, under a stated metadata-integrity assumption, produced 0 of 240 unsafe actions with a 95% Wilson upper bound of 1.58%, while keeping 99.17% usefulness on attack scenarios and 100.00% on approved changes (NetInjectBench).

That is the worked example worth internalizing: the best pure detection number in the study was 10%, and the containment mechanism beat it by a wide margin while staying useful. The Wilson bound is the honest caveat. Zero unsafe actions in 240 trials does not mean zero risk; it means the upper bound of the rate is small. Reporting intervals rather than point estimates is the correct way to describe a gate that blocked everything it saw (a note on interval construction for small samples).

"Confirm before acting" is easy to write and easy to fake. The gate is only real if satisfying it requires something the model does not have.

The test is straightforward: can the agent, using only the tools and context available to it in the session, produce a valid confirmation? If yes, the gate is not a gate.

Three confirmation designs pass that test, and they differ in cost:

• Human approval. A reviewer sees the pending action, the identity and permissions it would use, and the expected impact, then approves or rejects. Oversight is only meaningful when the reviewer can see what the agent intends to do and has runtime authority to block it before execution (Sweet Security on human oversight). Approval that happens after the fact is a log, not a control.
• Dual control on independently configured policy. A second check runs under configuration the agent's session cannot modify, with a different owner. The agent cannot satisfy it by writing a plausible justification into its own context.
• Out-of-band proof. A confirmation value delivered to a channel the agent cannot read or write, entered by a human. This is the same principle as a second factor, applied to an action instead of a login.

A fourth design fails the test: asking the model to restate its intent and confirm. The model that was hijacked to call pay will happily confirm that it meant to call pay. Self-confirmation is a formatting step.

The GitInject study of real GitHub workflows makes the failure mode concrete. An attacker adds a provider configuration file such as CLAUDE.md or AGENTS.md to a pull request branch; the CI runner checks it out and the agent loads it as operator-level instruction before processing any PR content. The authors report that all tested providers were susceptible to at least one attack class in their default configuration, and that the most critical vulnerabilities are structural, arising from how CI/CD infrastructure handles credentials and configuration files rather than from any single model's behavior (GitInject).

That is exactly the case where a confirmation step earns its cost. A pull request from an unknown contributor should not be able to reach a deploy verb without a human clicking something.

Most failed containment setups fail for one of five reasons.

The gate reads model output. If the policy decision depends on a field the model fills in, an injected payload can fill it in correctly. Keep policy inputs operator-controlled.

One credential serves every tool. A token that can read the repository and post comments and trigger workflows is a blast radius, not a permission. The lethal trifecta of private data, external communication and untrusted content is precisely what a single broad token creates.

Allowlists without a change path. NetInjectBench's static allowlist blocked all approved changes, giving full overblocking on legitimate work. A gate nobody can pass gets disabled within a quarter. Budget for an approval path from day one.

Confirmation on everything. If every read needs a click, reviewers rubber-stamp, and the control becomes symbolic. Restrict confirmation to the irreversible verbs.

No test in CI. Security tests for LLM features have to run on every change, because prompts, tools and retrieval data all move (on adding LLM security testing to CI/CD). A gate with no regression test drifts.

For teams that want adversarial suites rather than hand-written cases, red teaming guidance covers the payload families worth replaying: instruction overrides in documents, exfiltration attempts through outbound channels, and tool misuse under plausible pretexts (Checkmarx on red teaming LLMs).

Detection metrics ("did the model refuse?") and containment metrics ("what could it have done?") answer different questions, and you need both.

The last row is the one teams forget. Once you accept that some injections reach the tool layer, revocation speed becomes a security property. A gate that stops the call is ideal; a gate that stops the call plus a permission set you can revoke in minutes is what makes the design survivable.

An agent that uses several models through one interface makes this simpler, because the policy gate sees every tool call in the same shape regardless of which model proposed it. Quanta Inference offers text, image, video, audio and embedding models through one OpenAI-compatible API key, which keeps the enforcement point in one place (Quanta Inference).

Sequence the work so the gate arrives before the credentials widen.

1. Inventory every tool and write down its verb and resource. Anything you cannot name in one verb and one resource gets split.
2. Mark each pair reversible or not. The irreversible list is your confirmation surface, and it is usually shorter than people expect.
3. Replace shared credentials with scoped ones per resource. Do this before adding verbs to a tool.
4. Put the gate in the path and default it to deny, then allowlist what already works in shadow mode so you measure the overblocking rate before it can hurt anyone.
5. Add the confirmation flow for irreversible verbs, with an approval path that a human can actually complete in a reasonable time.
6. Replay the payload suite in CI on every change to prompts, tools or retrieval data.

If the backlog of steps two through five is the blocker, a consulting call is often faster than a quarter of internal negotiation, and Quanta builds the site, app or document you need with a specialist working alongside you (Quanta).