Least-Privilege Tools

Least-privilege tooling is the practice of scoping every tool and credential an AI agent can call to the minimum access it actually needs for its task, so that a bug, a mistake, or a successful prompt injection can only reach what that narrow scope allows — not everything the underlying system could otherwise do.

The principle predates AI by decades — it's the same reasoning behind not giving every employee an admin password — but it matters more for agents because the thing deciding what to do with a credential is a language model that can be wrong, confused, or manipulated, not a fixed piece of code executing exactly what a developer wrote. Least privilege is the one defense that still works even when everything upstream of it fails.

How it works

Instead of issuing an agent one broad credential that happens to work for everything it might need, issue narrow, task-specific access: read-only where write access isn't required, scoped to one table or one mailbox or one repository rather than the whole system it lives in, with every call logged so misuse is traceable after the fact. The design question for every capability granted isn't "does this let the agent do its job" — it's "what's the worst thing this scope allows if the agent is wrong or compromised," and shrinking that answer as far as the task permits.

Why it matters

This is the backstop that holds when every other defense doesn't: a prompt injection that successfully hijacks an agent's behavior, a bug that sends the wrong request, a hallucinated action taken in good faith — none of them matter as much if the credential behind them literally cannot reach beyond its scope. It's also the cheapest defense available, since it costs nothing at inference time and doesn't depend on the model behaving correctly; it depends on the surrounding system being configured correctly, which is a much easier thing to verify and audit.

A worked example

Two agents perform similar tasks. Agent A holds a credential scoped read-only to a single customer table containing 2,400 rows. Agent B holds an admin credential covering the entire database — 18,000,000 rows across the organization. Both agents are equally likely to make a mistake or be targeted by an injected instruction. If agent A is compromised, the damage is bounded to 2,400 rows. If agent B is compromised, the damage extends to all 18,000,000 — a blast radius 7,500 times larger, from the same failure, purely because of how the credential was scoped beforehand.

How Miatz teaches it

Every agent a learner builds in the curriculum starts with a credential audit as a required step, not an afterthought: before the first tool call runs, learners write down exactly what that credential can reach and justify why it needs that much. War Room incidents include cases where an over-scoped credential turned a minor bug into a major incident, precisely so the blast-radius math in the worked example above isn't abstract — it's the difference between two real, documented outcomes.