Agent permissions and approvals.

What least privilege means for an AI agent

Least privilege for an agent means the system limits what a fooled or mistaken agent can do, instead of trusting the model to behave. The OWASP Top 10 for LLM Applications 2026 ranks Excessive Agency third, as LLM03:2026 (it was LLM06 in the 2025 edition), and names three root causes: excessive functionality, excessive permissions and excessive autonomy. Each maps to a design question you can answer per tool:

The cheapest control is a tool that does not exist. A mailbox summariser that cannot send mail cannot be talked into forwarding the inbox, which is the first attack scenario OWASP describes for LLM03. The tool contract rules in AI tool calling in production give every tool a side-effect class; this guide turns those classes into permissions.

Whose identity does the agent act as

Every agent action needs an identity you can attribute later, and the right model depends on who the agent works for. OWASP’s ASI03 Identity and Privilege Abuse describes the “attribution gap” when an agent has no governed identity of its own.

The rule we design to is simple: effective permission equals the agent’s grant, intersected with the requesting user’s rights, intersected with the current task’s scope. Credentials should be short-lived and task-scoped, and checked again at execution time, because a user’s rights can change between plan and action. OWASP calls this time-of-check to time-of-use drift. For MCP-based integrations, the protocol’s security best practices add scope minimisation: no wildcard scopes, no advertising every scope up front, and no treating a scope claim as sufficient without server-side authorisation logic.

Action tiers and approval rules

Classify every action into a tier, and let the tier, not the model, decide what happens. The tier comes from the tool registry, never from the model’s own description of what it is doing.

Two published rules sharpen the table. OWASP’s LLM03:2026 mitigations describe graduated enforcement (audit, warn, block, escalate): a refund issued as store credit is recoverable and can auto-approve, while an external payout goes to a person. And the 2026 list adopts the Agents Rule of Two (Meta AI, 2025) as a floor: an agent that simultaneously reads untrusted input, holds sensitive data and can change state or communicate externally needs per-action human approval, and any two of the three need an explicit risk assessment.

Our property management agent for APL Property, a regional NZ firm, follows the same split: it handles routine administration such as email triage, records, orders and follow-up, while staff keep the decisions.

Enforce policy in code, not in the prompt

“Never send emails without asking” in a system prompt is a request, not a control. OWASP calls the alternative complete mediation: every request to a downstream system passes a policy check in code, independent of the model.

from dataclasses import dataclass

@dataclass
class Action:
    tool: str
    tier: int                       # from the tool registry, never from the model
    tenant_id: str
    amount_nzd: float = 0.0
    payload_hash: str = ""

def decide(action, user, agent, usage) -> str:
    if agent.paused or user.tenant_id != action.tenant_id:
        return "deny"                                   # kill switch, cross-tenant
    if action.tool not in agent.allowed_tools or action.tool not in user.entitled_tools:
        return "deny"                                   # intersection of grants
    if action.amount_nzd > agent.max_amount_per_action_nzd:
        return "deny"
    if usage.spend_today_nzd + action.amount_nzd > agent.daily_cap_nzd:
        return "deny"
    if usage.actions_last_hour >= agent.hourly_action_cap:
        return "escalate"                               # circuit breaker
    if action.tier >= 3:
        return "require_approval"                       # approval bound to payload_hash
    if action.tier == 2 and usage.sampled():
        return "allow_then_review"
    return "allow"

Run this at execution time, immediately before the downstream call, and log every decision with the user, agent, tool, payload hash and outcome in your AI audit log.

Approval design that resists rubber-stamping

An approval step only protects you if the approver can see what will happen and has time to think. OWASP’s 2026 guidance on prompt injection is specific: surface the exact rendered action rather than a summary, because invisible-character smuggling can make the displayed action differ from the executed one, and approval fatigue degrades judgement at volume.

Design rules for the approval screen:

• Show what will execute. Recipient addresses, amounts, account numbers, the rendered message and a diff for edits, with unusual values highlighted (a new recipient domain, an amount well above the usual range).
• Show why. The inbound email or document that triggered the action, so the approver can spot an instruction that came from outside.
• Bind approval to the payload. Store a hash of the exact action; any change after approval voids it, and approvals expire.
• Keep batches small and single-tier. Never mix a payment into a batch of draft replies.
• Separate duties for tier 4. The person who asked the agent should not be the only approver above your value threshold.
• Watch the approvers. An approval rate near 100% with decisions taking a couple of seconds is a signal that nobody is reading.

Queue design, staffing and service levels are covered in our guide to human review queues, and our lesson on automating a simple approval workflow shows the pattern for non-engineers.

Abuse tests to run before launch

Permission designs fail at the edges, so test the edges deliberately. Run these against a staging tenant with realistic data, and repeat them after every new tool or scope.

The injection cases overlap with our prompt injection testing suite; run them together. An independent AI security review is worth commissioning before agents get tier 3 or tier 4 tools.

Where permission designs fail

The failures are usually organisational shortcuts:

• The administrator integration user, created “to get it working” and never narrowed.
• Prompt rules instead of removed tools, which last until the first well-crafted email.
• Approval queues nobody staffs, which end in a blanket approval rule after the backlog grows.
• Logs that record only the service account, so you cannot tell which person or prompt caused an action.
• Approvals without context, where the reviewer sees “Send email? Yes / No” and nothing else.

For staff who need the plain-language version, our lesson on understanding AI tool permissions explains tiers and approvals without code.

• Every tool is justified by the task; open-ended tools are replaced by narrow ones
• Credentials grant no more than the tools expose, with no wildcard scopes
• Each agent has an attributable identity; effective rights are the intersection of agent, user and task
• Tokens are short-lived and rights are re-checked at execution time
• Every tool has a tier from the registry, and the tier decides approval
• Agents combining untrusted input, sensitive data and external actions need per-action approval
• Policy checks run in code before every downstream call
• Approval screens show the exact action, its trigger and unusual values, bound to a payload hash
• Batches are small, single-tier, and tier 4 needs a second approver above a threshold
• Spend, value, rate and recipient caps are set, with circuit breakers that escalate
• The kill switch is checked at execution time and tested on a schedule
• Escalation, fatigue, confused deputy, cross-tenant, mismatch and stale-rights tests pass

Written by the Levy Street team in Wellington. Last updated 19 October 2026.