Authorize agent tools outside the model

A model can propose a tool call because of a user request, a retrieved document or an attacker-controlled response (see /domains/ai-emerging/llm-security/prompt-injection-boundaries/). The tool gateway must decide independently whether the authenticated user and agent may perform it. A system prompt saying “only act when authorized” cannot substitute for that decision. The OWASP Top 10 for LLM Applications 2026 ranks this Excessive Agency (LLM03:2026), and the Agentic Top 10 calls the same failure Tool Misuse and Exploitation (ASI02:2026).

List each capability by its actual effects: reading records, sending information, modifying state, spending money or executing code. Separate narrow operations instead of giving one generic shell or unrestricted HTTP tool enough authority to do all of them. The model must not choose its own authenticated principal or expand its credential scope.

The user approves payment P7 for invoice I7: 5000 cents to recipient V1, under invoice version 4. Store those details with the authenticated user, tenant and expiry. A later proposal for 9000 cents or recipient V2 is a different action. Comparing only the tool name or invoice ID would let a material change pass under the old approval.

Current authorization remains necessary. If the user loses payment authority after approval but before execution, the old approval must not override that revocation. The code below puts every condition in one UPDATE ... RETURNING statement inside a BEGIN IMMEDIATE transaction: the approval must be unconsumed and unexpired, every argument and the invoice version must match, and the user must still hold the pay permission. Only if that statement changes a row does the transaction insert the operation. Two workers that both read consumed=false separately could otherwise both execute.

The local transaction guarantees at most one authorized operation, but the external payment needs its own idempotency. A crash after the provider commits and before the worker stores the result is not solved by asking the model to avoid retries. Send the operation ID as the provider’s idempotency key, for example an Idempotency-Key header, and reconcile ambiguous outcomes by querying the provider with the same key. Approval, concurrency control and external idempotency solve related but different problems.

Keep the approval display trustworthy: it must show the same target and values the gateway binds. A model-generated summary saying “pay the approved invoice” can conceal a changed recipient. The execution service loads authoritative values instead of accepting a model-selected user or tenant field.

import sqlite3
import uuid

SCHEMA = """
CREATE TABLE permissions (
  user_id TEXT, tenant TEXT, action TEXT, PRIMARY KEY (user_id, tenant, action)
);
CREATE TABLE approvals (
  id TEXT PRIMARY KEY, user_id TEXT NOT NULL, tenant TEXT NOT NULL,
  invoice_id TEXT NOT NULL, invoice_version INTEGER NOT NULL,
  amount_cents INTEGER NOT NULL, recipient TEXT NOT NULL,
  expires_at INTEGER NOT NULL, consumed_at INTEGER
);
CREATE TABLE operations (
  id TEXT PRIMARY KEY, approval_id TEXT NOT NULL UNIQUE, status TEXT NOT NULL
);
"""


def claim_payment(db, call, now):
    """Consume approval and create the operation in one transaction.

    `call` holds the authenticated user and tenant from the session plus the
    proposed arguments.
    Returns the operation id, which is also the provider's idempotency key, or None.
    """
    db.execute("BEGIN IMMEDIATE")  # take the write lock before reading the approval
    try:
        row = db.execute(
            """UPDATE approvals SET consumed_at = :now
               WHERE id = :approval_id AND consumed_at IS NULL AND expires_at > :now
                 AND user_id = :user_id AND tenant = :tenant
                 AND invoice_id = :invoice_id AND invoice_version = :invoice_version
                 AND amount_cents = :amount_cents AND recipient = :recipient
                 AND EXISTS (SELECT 1 FROM permissions
                             WHERE user_id = :user_id AND tenant = :tenant
                               AND action = 'pay')
               RETURNING id""",
            {**call, "now": now},
        ).fetchone()
        if row is None:
            db.execute("ROLLBACK")
            return None  # changed, expired, revoked, foreign or already used: no effect
        operation_id = str(uuid.uuid4())
        db.execute(
            "INSERT INTO operations (id, approval_id, status) VALUES (?, ?, 'pending')",
            (operation_id, call["approval_id"]),
        )
        db.execute("COMMIT")
        return operation_id
    except BaseException:
        db.execute("ROLLBACK")
        raise


def connect(path):
    # isolation_level=None: the code above issues BEGIN, COMMIT and ROLLBACK itself.
    return sqlite3.connect(path, isolation_level=None, timeout=10)

Derive caller identity from the trusted request channel and validate tool arguments against a closed schema that rejects unknown fields. Then perform resource and action authorization against current application state. Schema validity establishes shape, not permission: a well-formed invoice identifier may still name another customer’s invoice.

Use scoped credentials and fixed destination policies in the execution service. For delegated tasks, preserve both user and workload limits. Do not let a tool response, downloaded file or agent-to-agent message supply a new authority grant. Record the proposed action, policy decision and resulting effect with sensitive fields redacted.

For operations requiring user approval, show the concrete target, arguments and consequences through a trustworthy interface. Store an approval bound to that action, authenticated user, relevant resource version and expiry. If arguments or material state change, obtain a new decision instead of reusing approval for the old proposal.

Address duplicate delivery and time-of-check/time-of-use changes. Use idempotency keys and transaction-level checks appropriate to the operation. A user approving one payment does not authorize repeated payments after retries, and an approval recorded before account access is revoked should not override the latest policy.

An approval is only as good as what the approver sees. People tend to trust fluent, confident agents, and the OWASP Top 10 for Agentic Applications 2026 lists the abuse of that trust as Human-Agent Trust Exploitation (ASI09): an attacker, or a misaligned agent, steers a person into approving an action or disclosing information they would refuse if they saw the real request, and the person's approval then hides the agent's part in the audit trail.

Render the approval from the stored action, not from the model's explanation: the exact recipient, amount, account, record, diff or command, and the data that will leave. Mark what the agent wrote as agent-generated and show where each input came from. Separate preview from effect, so nothing changes state while the person is still looking. For high-risk actions, ask for independent confirmation, such as re-authentication, a second approver or a check against a record the agent did not supply. Keep approvals rare enough to mean something: let low-risk actions run under policy and send only consequential ones to a person, because a stream of routine prompts trains people to click through. Give users a plain way to report an agent that pressured or misled them, log every request and decision where the agent cannot change it, and compare each agent's actions with its approved workflow so unusual detours stand out. These follow OWASP's ASI09 mitigations.

Feed the gateway controlled tool-call fixtures without depending on model behavior. Test allowed actions, another tenant’s resource, changed approved arguments, expired approval, replay and a revoked user. Inspect the resulting ledger or datastore. A refusal sentence is irrelevant if the tool still executed, while a denial-only implementation is incomplete if it breaks every legitimate action. For an agent that keeps proposing calls after denials, the kill switches and run limits in /domains/ai-emerging/agent-security/agent-failure-containment/ stop it.

A signed approval token can establish integrity of its contents while still being replayable. Integrity, expiry, audience and one-time state are separate properties. Decide whether the operation permits repeated use; for this example it does not.

A gateway that checks tenant from the model’s JSON lets the caller choose the security context it is supposed to constrain. Derive identity and session authority from the trusted channel, and validate resource ownership against authoritative state. Reject extra fields rather than silently accepting a model-supplied principal override.

The OWASP Agent Control Standard (specification v0.1.0, announced by OWASP on 1 September 2026) defines hook methods such as steps/toolCallRequest and steps/toolCallResult, where a separate policy component can allow, deny or modify a proposed call and inspect its result. It is an early specification: use it to place your checks consistently across agent frameworks, not as evidence that they are sufficient. Its reference Guardian proceeds when it cannot reach a decision unless you set ACS_ON_DECISION_FAILURE=deny, so configure it to fail closed.

The checks in this guide map to ASVS v5.0.0 as follows: authorization enforced at a trusted service layer (8.3.1), permission changes applied immediately (8.3.2) and check-and-act performed as one atomic operation (15.4.2). The agent tool gateway lab (/labs/agent-tool-gateway/) and the agent-tool-boundaries project on this page implement the same binding and crash-recovery behavior.

Each row is one proposal against approval A7 and the ledger state that must follow it. The Agent tool gateway lab on this page has you repair a gateway until the same cases pass.

Repair the code

Excessive agency lab: Bind an agent’s action to the approved arguments

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. OWASP AI Agent Security Cheat Sheet
2. OWASP Top 10 for LLM Applications 2026 (LLM03 Excessive Agency). 2026 edition (3 August 2026).
3. OWASP LLM06:2025 Excessive Agency (2025 list; LLM03 in 2026). 2025 edition.
4. OWASP Top 10 for Agentic Applications 2026 (ASI02, ASI03, ASI09). Version 2026 (December 2025).
5. OWASP Agent Control Standard (v0.1.0). 1 September 2026.
6. OWASP Authorization Cheat Sheet

Reference information

Tags

Access controlLLM application securityAI agents and tools

SDLC phase

DesignDevelopment

Role

DevelopersAppSec engineersPlatform engineers and SREs

ASVS 5.0.0 requirements

v5.0.0-8.3.1 · v5.0.0-8.3.2 · v5.0.0-15.4.2

Download this guide as Markdown

Continue exploring