Relynt
Back to blog
Policy Patterns

Least privilege for agent tools: a practical checklist

14 min read

When an AI agent can call tools, least privilege is the difference between a safe product and a future incident. What to scope, what to deny, when to require approval, and how to keep automation usable.

When an AI agent can call tools, "least privilege" stops being a nice security principle and becomes the difference between a safe product and a future incident.

Most teams fail here in predictable ways:

  • one shared bot token
  • broad tool scopes "so it works"
  • no field-level boundaries
  • no approval gates
  • logs that cannot answer "why was this allowed?"

This checklist is the practical version of least privilege for agent tooling: what to scope, what to deny, when to require approval, and how to keep automation usable.

The goal

Least privilege for agent tools means:

An agent should only be able to perform the minimum set of actions necessary, on the minimum set of resources, under the minimum set of conditions, with higher-risk actions gated and provable.

The "agent" here includes:

  • the model-driven agent runtime
  • any tool connector credentials it uses
  • any delegated user authority it may receive

1) Inventory and classify your agent actions

Start by listing the actions your agent can perform. Do not list "tools." List verbs.

Examples:

  • create_ticket
  • update_ticket_status
  • update_deal_stage
  • add_crm_note
  • create_issue
  • merge_pull_request
  • provision_user_access

Then classify each action by risk:

  • Low risk: reversible, limited impact, internal-only
  • Medium risk: affects workflow state, touches customer data
  • High risk: money, access, production config, irreversible state transitions

If you cannot classify actions, you will over-approve or over-deny.

2) Scope by action first, not by tool

Tool-wide scopes ("crm.write", "jira.edit") are too broad for agents.

Least privilege for agents should start with:

  • allowed actions (what verbs)
  • mapped to tool operations behind the scenes

This makes policy stable even if your tool integration changes.

3) Scope by resource with explicit boundaries

For every action, define what resources it can touch.

Good scoping:

  • "Deals assigned to this team"
  • "Tickets in project X"
  • "Repos in org Y, excluding production repos"
  • "Users in tenant Z"

Bad scoping:

  • "All deals"
  • "All tickets"
  • "Any repo"

Practical patterns:

  • by project, team, tenant, or namespace
  • by tags/labels (e.g., only tickets labeled "agent-managed")
  • by environment (staging-only by default)

4) Restrict fields and state transitions

This is where most agent deployments either become unsafe or unusable.

Field-level controls

Define:

  • writable fields (allowlist)
  • sensitive fields (denylist)
  • validation rules (format, length, allowed values)

Examples:

  • allow update to status, priority, notes
  • deny update to billing_email, discount_rate, role, permissions

State transition controls

Some changes are high risk because they carry business meaning:

  • "Closed Won"
  • "Resolved"
  • "Refunded"
  • "Provisioned"

For these, require:

  • approval, or
  • additional conditions (ticket reference, manager role, etc.)

5) Add thresholds and guardrails that preserve automation

Approvals should be the exception, not the default.

Use guardrails that keep routine work automatic:

  • max value changes (e.g., amount change limit)
  • rate limits (per hour/day)
  • batch limits (max items per run)
  • time windows (only during business hours)
  • anomaly flags (spike in changes triggers approval mode)

These reduce risk without creating approval bottlenecks.

6) Separate "prepare" from "commit"

A powerful least-privilege tactic is making agents do prep work automatically, but gate the irreversible write.

Pattern:

  • prepare: gather info, draft changes, propose diff
  • commit: execute write after approval (or tighter policy)

Examples:

  • draft customer email → human sends
  • propose incident resolution summary → commander closes
  • create PR with changes → reviewer merges

This keeps the agent useful while containing blast radius.

7) Require approvals only for truly high-impact writes

Approvals should trigger when:

  • the action is irreversible or expensive to undo
  • it crosses a trust boundary (access, money, production)
  • it changes business-critical state
  • it touches sensitive data fields
  • it deviates from normal behavior (anomaly)

Also ensure approvals are:

  • routed to the right owner group
  • presented with clear context and a diff-like summary
  • recorded as evidence

If approvals are noisy, they will be bypassed.

8) Make identity and delegation explicit

Least privilege collapses if you cannot say who the agent is and what authority it is using.

At minimum, be able to answer:

  • which agent performed this action
  • which run/instance
  • whether it was acting for a user or as itself
  • who owns the agent

Even if your product does not support full delegation, your audit trail should clearly show whether the agent operated under user context or system context.

9) Centralize tool credentials and minimize their scope

A common failure is giving the agent a powerful tool token because it is convenient.

Practical guardrails:

  • store tool credentials centrally (not in the agent runtime)
  • rotate credentials
  • limit tokens to the smallest tool permissions possible
  • separate tokens by environment and by action class if needed

You want the agent runtime to be unable to bypass your controls by calling the tool directly.

10) Make every decision provable

Least privilege is not only about preventing actions. It is about showing evidence that controls were applied.

You should have a record for:

  • denied actions (and why)
  • approved actions (and who approved)
  • executed actions (and whether they succeeded)

This turns "we think we are safe" into "we can prove it."

A practical checklist you can use in reviews

Action scope

  • List all agent actions as verbs (not tools)
  • Categorize each action by risk

Resource scope

  • Define explicit resource boundaries (tenant/project/team)
  • Default to staging-only unless justified

Payload constraints

  • Allowlist writable fields
  • Denylist sensitive fields
  • Restrict state transitions

Guardrails

  • Threshold limits for amounts and counts
  • Rate limits per run/day
  • Prepare vs commit separation

Approvals

  • Approval required only for high-risk actions
  • Approval routing to correct owners
  • Approval prompt includes context and diffs

Identity and credentials

  • Clear agent identity and ownership
  • Centralized tool credentials
  • Tool tokens are scoped and rotatable

Evidence

  • Every attempt is recorded (allow/deny/approval)
  • Investigation can answer who/what/why quickly

If you can check these boxes, you will pass most enterprise "agent safety" scrutiny—and you will avoid the trap of shipping an agent that only works in demo environments.

Closing

Agents are powerful because they can take action. Least privilege is how you let them take action without turning your systems into an experiment.

Start with action-level scope, narrow the resource surface, constrain payloads, add guardrails, and reserve approvals for true exceptions.

That's how you keep automation alive while keeping risk bounded.

All posts