Rifty Notes
Glossary

Least privilege

Least privilege is the practice of granting an agent only the minimum access required for its current task—read before write, one resource before a whole class—and widening scope only when a specific, justified need appears. It shrinks the damage any single action, model error, or hijacked step can cause.

How it works

Least privilege treats every capability you hand an agent as a grant that has to be earned, not a default that ships on. You start from the smallest set of permissions the current task needs, and you widen only against a named reason.

In practice it's a scoping loop:

  • Enumerate the task's actual actions — read this file, query that endpoint, write one record.
  • Grant read scopes before write scopes, and write to one resource before write to a whole class.
  • Bind each credential to the narrowest surface it can do the job on: one project, one bucket, one repository path, one table.
  • Give the grant an expiry or a revocation path so it stays temporary rather than accreting into a permanent standing right.
  • Expand only when a blocked action produces a specific, logged justification — not because broad access is convenient.

The important shift is that permission becomes a function of the task, not a property of the agent. A summarization step gets read-only retrieval. A deploy step gets write to one environment. The agent that files an issue never holds the token that can delete the repo. When the task ends, the grant ends with it, so unused authority doesn't sit around waiting to be misused.

Why it matters in an agent harness

An agent is a stochastic process wired to real side effects. It will occasionally take a wrong action — a bad tool call, a misread instruction, a step steered by injected content in a retrieved page. Least privilege decides how expensive that moment is.

The payoff is containment. If a compromised or confused step only holds read access to one namespace, the worst case is a bad read, not a wiped database. Scoping is the input-side twin of rollback: rollback limits damage after the fact, least privilege limits how much damage was ever reachable in the first place.

It also makes the harness legible. When each step carries a narrow, named grant, your logs answer "what could this agent have done here?" without you reconstructing a sprawling ambient permission set. That legibility feeds evals and audits — you can reason about a trajectory because its reachable actions were bounded. Prompt injection loses most of its leverage when the hijacked step simply cannot reach the destructive tool. And narrow grants tighten model routing and delegation: a subagent inherits only what its slice of work requires, so handing work down doesn't quietly hand down authority too.

Least privilege vs blast radius

These get conflated because they point at the same fear, but they are different levers and belong at different points in the design.

Least privilegeBlast radius
Question it answersWhat can this agent touch?What breaks if it misfires?
When it actsBefore the action, at grant timeThe consequence, measured or bounded after
Primary leverScoping credentials and tool surfaceIsolation, quotas, rollback, sandboxing
Failure signalAn over-broad token or wildcard scopeWide, hard-to-reverse damage from one step

Least privilege is a cause you control; blast radius is the effect you measure. Tightening grants is usually the cheapest way to shrink blast radius, but the two are complementary — you still want isolation and reversible actions for the authority you genuinely must grant.

The Rifty take

We treat every permission as a liability the operator carries until it's revoked, so we default to the narrowest grant that lets the task finish and make the operator justify each widening, not each narrowing. We'd rather an agent stall on a missing scope — a legible, loggable stop — than succeed by holding authority it never needed. Read-before-write and short-lived, task-bound credentials are the boundary we enforce, because unused privilege is pure downside with no matching upside.

Implementation checks

  • Default every new tool and credential to read-only; require an explicit reason to add write.
  • Scope tokens to a single resource or path, not an account-wide wildcard, and prefer per-task credentials over one shared key.
  • Give grants an expiry or an automatic revocation at task completion so authority doesn't accumulate.
  • Make a denied action a first-class, logged event — the deny trail is where you learn what scope the task actually needs.
  • Ensure a subagent inherits only its slice of permissions, never the parent's full set.
  • Audit for standing grants no active task uses; treat a broad token that nothing exercises as a bug, not a convenience.

Frequently asked questions

How is least privilege different from a guardrail?

Least privilege removes the capability itself — the agent simply lacks the access to act. A guardrail lets the action be attempted, then checks or blocks it at runtime. Prefer removing the capability where you can; use guardrails for authority you must grant but want policed.

Doesn't least privilege slow an autonomous agent down?

It adds friction only when a task reaches for access it wasn't scoped for, and that stall is usually the signal you want. Scope grants to the task's real actions up front and the agent rarely blocks. The tradeoff — occasional legible stops for far smaller blast radius — is worth taking.

How does least privilege help against prompt injection?

Injection works by steering a step toward an action the attacker wants. If that step holds only narrow, read-scoped access, the hijack has nothing destructive to reach. Least privilege doesn't stop the model from being fooled; it caps what a fooled step can actually do.

Where do least privilege and blast radius differ?

Least privilege is an input control set before the action — what the agent can touch. Blast radius is the resulting consequence — what breaks if it misfires. Tightening grants is usually the cheapest way to shrink blast radius, but you still pair it with isolation and reversible actions for authority you must grant.

How should subagents inherit permissions?

By subset, never by default inheritance of the parent's full set. Each subagent should receive only the scopes its slice of work requires, ideally as its own short-lived, task-bound credential. Delegating work should not silently delegate authority, or your narrowest grant becomes the union of everything the tree can touch.

Related glossary terms.

Least privilege