How to Scope Each Tool an Agent Can Call

A tool's name describes its intent, not its reach. "Search documents" can mean a scoped index or a full-text scan across every tenant. The failure is silent, which is why the Zscaler writeup on agent access is blunt about it: a support agent authorized for a CRM should be scoped to the records its current task involves, not the whole tenant's data and not other tenants' (Zscaler).

Read the implementation and answer five questions in writing for each tool.

• What does it read? Name tables, fields, document sets, and any join or filter that quietly widens the result.
• What does it mutate? Writes carry more risk than reads and deserve tighter scoping; the write path should get the tightest scoping of all (Arthur AI).
• What does it emit beyond its return value? Logs, audit events, webhooks, emails, queue messages and outbound HTTP are all side effects.
• What is the blast radius of one bad call? If a single incorrect invocation could expose data, move money or change production, you are doing blast-radius engineering and should design for bounded impact rather than best-case behavior (Oso).
• What does it cost per call? Rate limits and spend caps are scope too; a loop on a metered API is a scope violation with an invoice attached.

A worked example shows how wide the gap can be. A support agent holds a get_customer tool that takes a numeric customer ID. The name implies a narrow lookup. The implementation applies no ownership filter, so it reads every customer in the tenant. The true data reach is the entire customer table, and the correct contract restricts the query to the customer matching the authenticated session, caps results at one record and refuses any other ID.

Do the same trace for memory and retrieval. Poisoned memory means future sessions inherit compromised context, and retrieval bias can shift planning before any tool is called, which is why per-component reviews miss it (Christian Schneider). A retrieval tool is a data-reach question even though it looks like plumbing.

The contract is the artifact this procedure exists to produce. It is a machine-readable record per agent-tool pair with five fields: data scope, verbs, argument constraints, confirmation gates and limits. OWASP's agentic threat work places least privilege and human approval for high-impact actions among the core mitigations against tool misuse, the case where an agent stays inside its permissions but chains calls into data destruction or record export (Idan Habler, OWASP ASI).

The governing principle fits in one line: the model proposes actions, policy authorizes them. If the agent's reasoning becomes your authorization logic, you have deployed an incident generator (Oso). Write the contract so a runtime, not the prompt, makes the decision.

Five fields, filled in for one tool

An argument constraint outperforms a paragraph of prompt text. With status drawn from an enum, an injected instruction to close every ticket fails validation instead of relying on the model to decline.

Read and write belong in separate contracts even when one tool offers both, because they are different risks granted independently (Zscaler). Identity is the foundation underneath. Give each agent its own discrete identity rather than a shared service account inherited from the deploying team, or attribution and revocation stop working (Okta).

Enforce it where the call is built

The contract must execute at the invocation point. A pattern that holds up: a policy map keyed by agent identity and tool name, consulted inside the same function that assembles the request.

SCOPE = {
    ("support-agent", "update_ticket"): {
        "fields": {"status", "priority", "assignee"},
        "status_enum": {"open", "pending", "resolved", "closed"},
        "needs_human": lambda args: args.get("status") == "closed",
        "max_calls_per_session": 20,
    },
}

def call_tool(agent_id, tool, args, session):
    contract = SCOPE.get((agent_id, tool))
    if contract is None:
        raise PermissionError("no contract for this agent-tool pair")
    unknown = set(args) - contract["fields"]
    if unknown:
        raise PermissionError(f"fields outside scope: {unknown}")
    if "status" in args and args["status"] not in contract["status_enum"]:
        raise ValueError("status value outside enum")
    if contract["needs_human"](args):
        return request_human_approval(agent_id, tool, args)
    if session.calls(agent_id, tool) >= contract["max_calls_per_session"]:
        raise PermissionError("session call cap reached")
    return invoke(tool, args)

Notice what the code never does: it does not ask the model whether the call is appropriate. Deny-by-default means a new agent starts with zero tool permissions, each one added per persona and approved, and the policy engine rather than the model decides what is reachable (Skyrelis). A missing entry is a denial.

Run this checklist before shipping any contract.

Contracts can each be correct while the composition is dangerous. OWASP's multi-agent threat guide describes attack patterns that end with an agent orchestrating sequences of legitimate tool calls into an unauthorized outcome, and StRIDE-style component reviews miss them because no individual component is broken (Christian Schneider). Treat chaining as a scoping problem in its own right.

Three patterns to hunt down:

• Read then send. Any tool returning sensitive data paired with any tool reaching the outside world. Restrict the send tool to allowlisted addresses or domains and cap message size.
• Read then write. A lookup feeding an update. If the lookup returns records the caller does not own, the update inherits the overreach. Scope the lookup, not just the write.
• Grant then act. A permission-granting tool paired with a tool that uses the grant. Gate the granting tool every time with a human.

Delegation adds a second layer. In multi-agent systems a sub-agent's output is consumed by the orchestrator with less scrutiny than a user input, so an adversarial payload can cross trust boundaries between agents (DeepTeam). The scope rule is intersection, not union: a delegated task runs with the overlap of parent and child contracts, never with whatever the child happens to hold. A read-only research sub-agent cannot pass a write instruction to an executor holding broader grants unless the parent holds them too.

Volume needs governing as well, not only verbs. An agent can stay entirely inside its authorized permission set while querying records one at a time below any threshold, in ways inconsistent with its purpose, and that gap is exactly what least-agency thinking addresses (Zenity). Practical counters: per-session call caps, per-tool record caps, and alerts when a session's call pattern departs from its baseline.

Tool calls must also be tested adversarially, not assumed safe because scope looks tight. Red teaming an agent means probing what it does rather than what it says, because a compromised agent will act without raising an error: it deletes files, leaks credentials or makes unauthorized calls while looking helpful (Fiddler).

A contract in a wiki is documentation. A contract in the request path is a control. Three enforcement points, in order of preference:

1. The tool wrapper. Every invocation passes a single function that loads the contract and validates. Cheapest to build, easiest to audit.
2. The MCP server or connector. For tools you host, validate server side so no client can bypass the rule. The OWASP agentic initiative maintains a practical guide for securing MCP servers, the connection point between assistants and external systems, alongside its broader resource set (OWASP ASI).
3. The identity layer. Discrete per-agent identities, short-lived per-session tokens instead of standing credentials, and revocation that actually revokes (Okta).

Logging needs four fields on every call: agent identity, tool name, the contract version that authorized it, and the outcome (allowed, gated, denied). Add argument keys rather than values, so a denial is diagnosable without copying sensitive data into logs.

Two alerts pay for themselves quickly. A denial spike on one agent-tool pair means someone is probing or a prompt changed. A first-ever call from a pair the inventory marked unused means an unreviewed grant went live. Microsoft's red teaming tooling takes the same posture, supporting scheduled adversarial runs after deployment rather than only before it, with findings logged and tracked over time (Microsoft Foundry).

Calendar reviews miss the thing that actually changes agent risk: the tool surface. Trigger re-review from events, with a slower scheduled sweep as a backstop.

Scope creep is the predictable failure. Research from Entro Security cited by Zenity found that 97 percent of non-human identities carry excessive privileges, a pattern that accumulates through deadline pressure and missing governance checkpoints rather than one bad decision (Zenity). Industry survey work points the same way: Gartner found 74 percent of IT application leaders regard AI agents as a new attack vector into their organization (Okta). Your re-review is where that drift gets caught.

Give every contract a named owner and require a written justification to keep scope. The review question is not whether the agent still works but what one incorrect call could do under this contract, and whether that is still acceptable. If you want the inventory or the enforcement design pressure-tested before the next change window, a free 30-minute discovery call with Quanta Consulting is a low-cost second opinion (https://quantaintelligence.ai/calendar). Where several models sit behind one gateway and you want contracts enforced consistently across vendors, Quanta Inference offers text, image, video, audio and embedding models through one OpenAI-compatible API key (https://quantaintelligence.ai/inference).