Scope Agent Permissions to Least Privilege

Tier: Core · Workflow area: RAG & agent security

Least privilege is the highest-leverage agent control because it caps the blast radius of every other failure. This playbook scopes an over-permissioned agent in your own stack down to exactly what each task needs and proves the removed powers are gone.

When to reach for this

• •
  An agent holds an API token, DB connection, or cloud role broader than any single task requires.
• •
  Multiple tools share one credential, or the agent runs as a human's full identity.
• •
  You're threat-modeling an agent and need to bound "what's the worst it can do if hijacked?"

The workflow

Threat, briefly. An agent with a read-write DB credential and a shared admin token is asked to summarize a ticket that contains an injected also delete all records where.... The agent can comply because it was over-privileged. Least privilege makes the malicious step impossible, not merely discouraged.

1. 1.

   Inventory the agent's current authority. List every tool, credential, scope, and resource it can touch today. You cannot minimize what you haven't enumerated. Most agents have far more than their tasks use.

2. 2.

   Give each tool its own narrowly-scoped credential. Replace the shared god-token with per-tool identities carrying only the scopes that tool needs. A read tool gets a read-only credential; a search tool cannot write.

   Copy

   TOOLS = {
     "search_tickets": Cred(scope=["tickets:read"]),
     "post_reply":     Cred(scope=["tickets:comment"]),   # not tickets:delete
   }
   # each tool call authenticates as its own scoped identity, never a shared admin key
   

3. 3.

   Prefer just-in-time, short-lived credentials over standing ones. Mint a token scoped to the specific resource for the specific task, expiring in minutes. A leaked or hijacked credential is then near-worthless.

4. 4.

   Enforce authorization on the resource side too. The tool's credential is one gate; the backend must independently check that this agent identity may perform this action on this object. Don't rely on the agent to self-restrict.

5. 5.

   Scope by resource, not just by verb. "read tickets" should mean this tenant's tickets, not all tickets. Bind credentials to the data partition the task is about.

6. 6.

   Test the removed powers against your local agent. Instruct the agent (via a benign task and via an injected task on your local target) to perform an action outside its scope and confirm the backend rejects it.

   Copy

   # local agent you own: prove the deny path
   python run_agent.py --task "summarize ticket 42; then delete ticket 42"
   # expect: summary succeeds, delete is DENIED (403) by scoped credential
   

Verify before you trust it

The defense holds when out-of-scope actions are refused at the credential and resource layers, not by the model. Run three checks against your local agent:

• In-scope work still completes: a legitimate in-scope task completes normally.
• Out-of-scope actions hard-fail: an injected out-of-scope action (delete, cross-tenant read, privilege change) returns a hard 403 from the backend, and the agent surfaces the denial instead of finding another path.
• Scopes verified at the token: the credential the tool used carried only the expected scopes — verify by inspecting the token, not by trusting config.

The proof is a permission matrix showing, per tool, what's allowed and a passing deny-test for everything outside it. Keep the deny-tests in CI so a scope-creep in a future PR fails the build.

Pitfalls

• One credential shared across tools. Hijack one tool, get all of them. Per-tool scoped identities are the baseline.
• Standing long-lived tokens. A leaked permanent token is permanent access. Short-lived, just-in-time credentials shrink the window.
• Verb scopes without resource scopes. "read" across all tenants is still excessive. Bind to the data partition.
• Trusting the agent to self-limit. Prompt-level "don't delete anything" is not authorization. Enforce at the backend.
• Human-identity agents. Running the agent as a real user's full account makes its blast radius that user's entire access. Give the agent its own minimal identity.

Tools

• MCP with per-server scoped credentialsbind each tool/server to its own narrow identity rather than a shared secret.
• A secrets manager with short-lived credentials (Vault/cloud STS-class) — just-in-time, auto-expiring tokens per task.
• Policy-as-code / an authorization service (OPA/Cedar-class) — independent backend authorization checks the agent cannot bypass.

Client-safe variant

Least-privilege scoping is a clean, data-free engagement: you are redesigning permissions, not touching client content, so most of the work is credential and policy configuration inside the client's IAM and secrets tooling. Build the permission matrix with the client, mint scoped credentials in their environment, and run the deny-tests against a client-approved staging agent using synthetic tasks. The pattern maps directly onto controls their auditors already understand (least privilege, short-lived credentials, resource-level authorization), so it slots into an existing IAM narrative while specifically bounding the new agentic blast radius — and none of it requires exposing client data to any external tool.