HiveKey
All guides
Fundamentals 7 min read

Least privilege for AI agents

How to scope an agent down to exactly the capabilities its job requires — and why, for agents, 'denied' isn't enough and capabilities should be invisible.

Least privilege is an old principle: give any actor the minimum access it needs, and nothing more. For AI agents it’s not just good hygiene — it’s the single control that shrinks the blast radius of every future mistake at once. This guide shows how to apply it.

Start from zero, not from “everything”

The default for most agents is backwards: they’re handed a raw key with the full powers of an account, and you’d subtract access if you ever got around to it. Least privilege inverts this. A new agent starts with zero capabilities and earns each one deliberately.

This matters more for agents than for people. You can lean on a human’s judgment to not abuse access they happen to have. An agent will use whatever’s in front of it — including when a prompt injection points it at a tool you forgot to remove. The empty default is the only safe default.

Map the job to capabilities

Scope an agent by describing its job, then listing the minimum capabilities that job requires.

A support agent that drafts replies and looks up orders needs:

  • crm_read — look up the customer and their orders
  • mail_send — send the reply (to approved domains)

It does not need crm_delete, payments_pay, vault_get, or deploy. Those aren’t part of the job, so they aren’t part of the role. Write the list down explicitly; the act of writing it surfaces the powers you were about to grant by accident.

Use roles, not per-agent grants

Don’t configure capabilities on each agent. Define a role — a named bundle of capabilities for a job — and assign it. Ten support agents wear Support · L2; change the role once and all ten update. This is how least privilege survives past three agents. (See RBAC for AI agents on the blog for the full model.)

role: Support · L2
  capabilities:
    - mail_send        # approved domains only
    - crm_read         # no PII export
  # everything else: not granted → invisible

For agents, invisible beats denied

Here’s the part that’s specific to agents and easy to get wrong. With humans, a denied action is fine — they see a grayed-out button and move on. With an agent, a visible-but-denied capability is an attack surface. A prompt injection can keep instructing the agent to call it, probing for a gap.

So ungranted capabilities should not merely return “denied.” They should be filtered out of the agent’s tool manifest entirely. The agent never sees vault_get, so a prompt-injected “reveal the API key” request has no tool to call. Denied becomes nonexistent.

Least privilege for agents has two layers: don’t grant what the job doesn’t need (scope), and don’t even show what you didn’t grant (invisibility). The second layer is what closes the prompt-injection door.

Scope arguments, not just tool names

A capability is sometimes too coarse. crm_read might allow reading PII you’d rather the agent never export; db_query might allow DROP as easily as SELECT. Tighten at the argument level:

  • crm_read → allow, but block exports of PII columns
  • db_query → allow SELECT only
  • deployenv="staging" allowed; env="production" requires approval

This is where scope hands off to guards (covered in the spend-caps guide). The boundary between “what’s grantable” and “what’s allowed in this specific call” is exactly the boundary between scope and guard.

Review and right-size over time

Least privilege isn’t a one-time setup; it’s a habit.

  • Watch the denial log. Frequent denials for a capability an agent legitimately needs mean the role is too tight — add it. Frequent denials for something it should never do mean someone’s trying — investigate.
  • Prune the unused. A capability granted months ago and never called is pure risk. Remove it.
  • Review roles, not agents. Quarterly, read your handful of roles. Far easier than auditing hundreds of agents.

The payoff

When every agent is scoped to its job and ungranted tools are invisible, you stop having to predict every way an agent could be tricked. You only have to ensure that when it is tricked, the dangerous action simply isn’t on the table. That’s the whole value of least privilege: it makes your worst case small, on purpose, in advance.

Put every agent your company runs under one policy.

Watch HiveKey scope, guard, and block a live action on your own agents — 30 minutes, no slides, no commitment.