Helmwart
← Atlas · Mitigations Tier 2 · Real-composable

MITIGATION · m-tool-jit

Just-in-time tool grants — ephemeral access scoped to a single task

An agent that holds a persistent catalog of invokable tools can reach any of them at any point in its session. If its reasoning is manipulated or its identity is compromised, that persistent surface is fully available to an attacker. Just-in-time tool grants remove the standing surface: a policy broker issues a time-bound, task-scoped grant immediately before the tool is needed and revokes it automatically when the task completes or the window expires.

Last reviewed 2026-05-12 · Status: published · Evidence →

At a glance

MATURITY
Tier 2
Available off-the-shelf or as a documented pattern, but newer or less broadly proven. Expect integration work and some operational nuance.
PLACES ON
node
Restricted to node kinds: agent
COVERAGE
3 threats
T2 · T3 · T16
TRADE-OFFS
LAT
low
COST
low
UX
low
DEV
medium
Latency · cost · UX friction · dev effort.
TL;DR
  • Grant each tool only for the duration of the task that requires it; revoke automatically when the task completes or the TTL expires. Persistent tool access widens the misuse window to the full agent session lifetime; JIT closes it to the duration of a single task.
  • A policy broker (OPA, Cedar, or a custom gate) evaluates a grant request carrying the agent identity, tool identity, and task context, then issues a time-bounded signed token. The tool is callable only while that token is valid.
  • The agent's ambient tool surface is empty or read-only at baseline; executable tools appear only inside an approved grant window.
  • Addresses tool misuse (T2), privilege compromise (T3), and inter-agent protocol abuse (T16) by ensuring no tool can be invoked outside an approved task window, regardless of how the agent's prompt or memory is manipulated.

How it behaves

Orchestrator identifies the tool(s) required for the current task and requests a time-bounded grant from the policy broker.
Broker evaluates agent_id x tool_id x task_id x TTL against policy (OPA/Cedar), issues signed grant, and rejects any call arriving without a valid token or after expiry.
All tools are available for the full agent session. A prompt injection or confused-deputy attack can invoke any tool at any time.
Only the granted tool set is callable during the active window. Expired or out-of-scope tool calls are rejected at the broker before reaching the tool.
Policy evaluation (OPA/Cedar) adds approximately 10-50 ms per grant. Cache decisions per task_id so the cost is paid once per task, not once per tool call: three tools at 50 ms per grant is approximately 150 ms total, negligible against typical task durations of seconds to minutes.

What it is

An agent's tool surface is the set of tools it can invoke at any given moment. In most frameworks, that surface is defined once at initialisation and remains constant for the life of the session. The agent can call any listed tool at any time, constrained only by its own reasoning.

That design is a liability when reasoning fails. A prompt injection, a confused-deputy attack, or a compromised agent identity can cause the agent to invoke tools it should not. The standing surface is available in full whenever the failure occurs.

Just-in-time tool grants address this by making the tool surface dynamic. The agent does not hold a persistent catalog of invokable tools. Before a high-impact tool call, the orchestrator requests a grant from a policy broker, specifying the agent identity, the tool, and the task context. The broker evaluates the request against policy and issues a time-bound, task-scoped token. The tool is callable only while that token is valid. When the task completes or the TTL expires, the broker revokes the grant and the tool returns to the inaccessible baseline.

The key property is that the attack window shrinks from the agent's entire session lifetime to the seconds or minutes of a single task. A compromised agent can only reach tools it has been actively granted for the current task. Tools outside the grant are structurally unreachable, regardless of what the agent's prompt or memory claims.

Detection signals

  • Tool invocations without a valid active grant. Any call that arrives at the broker outside an approved window is a policy violation and an immediate investigation signal.
  • Grant request rate per tool per agent identity. A sustained spike indicates an agent is being induced to request tool access it does not normally need, consistent with prompt injection or a mis-scoped baseline.

Threats it covers

  • T2 Tool Misuse −1 severity step

    WHY IT HELPS Tool Misuse is the execution of tools with parameters or in combinations the operator did not intend to permit. JIT grants bound the available tool surface to the specific tool required for the current task, so any invocation outside the active grant window is rejected by the broker before the tool is reached.

  • T3 Privilege Compromise −1 severity step

    WHY IT HELPS Privilege Compromise relies on a compromised agent identity retaining access to tools beyond those its current task requires. JIT grants ensure that a compromised identity can only reach tools that have been explicitly granted for the running task; the rest of the catalog is structurally inaccessible until a new grant is issued.

  • T16 Insecure Inter-Agent Protocol Abuse −1 severity step

    WHY IT HELPS Insecure Inter-Agent Protocol Abuse allows a peer agent to invoke tools beyond its assigned scope by exploiting another agent's session or by misrepresenting task context. JIT grants enforce task-scoped boundaries at the broker layer, so a peer agent cannot expand its callable surface beyond what was granted for the current task regardless of how the request is framed.

Principle coverage

Defence-in-Depth stage: Prevent — and it advances:

  • Least Privilege JIT grants enforce least privilege at the temporal dimension: the tool surface is narrowed to exactly the tools a task requires and only for the duration of that task, so the agent never holds more callable authority than its current work warrants.
  • Attack Surface Minimization Reducing the tool surface to a single task-scoped grant at runtime removes every other tool in the catalog from the reachable attack surface for the duration of that task, shrinking the combinatorial space available to prompt injection and chaining exploits.
  • Least Agency / Minimal Autonomy JIT grants remove the agent's standing ability to invoke any tool in its catalog at will, replacing it with a time-bounded permission that must be explicitly issued for each task by an external policy broker rather than by the agent's own judgment.

Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.

Implementation options

Four implementation patterns, ranging from cloud IAM session credentials to framework-native dynamic tool lists. Mix as needed: AWS STS for cloud tools, MCP list_changed for local MCP servers, and an OAuth STS for cross-service delegation.

AWS STS AssumeRole Agent calls sts:AssumeRole immediately before a high-impact tool call, passing a task-scoped inline session policy and DurationSeconds (minimum 900 s). Resulting temporary credentials expire automatically; the session policy intersects the role policy so the agent cannot exceed what the role permits.

Why choose it: Self-enforcing expiry at the IAM layer. Works with any AWS-hosted tool endpoint. The inline session policy ensures the grant cannot exceed the base role permissions, providing a hard ceiling on what the agent can reach during the task.

More details:

MCP tools/list_changed MCP servers declare listChanged: true in their capability handshake. When a task starts the server adds the required tools and fires a notifications/tools/list_changed notification; on task completion the server removes them and fires again. The client-visible tool surface returns to baseline without a session restart.

Why choose it: Native to the MCP protocol; no external policy broker required. The server controls the canonical tool list, preventing client-side spoofing of which tools are available.

More details:

LangChain bind_tools per task LangChain BaseChatModel.bind_tools() returns a new Runnable with the supplied tool list embedded in the model call. The orchestrator calls it fresh per task, passing only the tools the task class requires. The previous Runnable with its broader tool list is discarded after the task completes.

Why choose it: Zero-infrastructure option for LangChain-based agents; tool surface scoping is enforced at the model-call boundary without a separate policy broker or credential service.

More details:

Custom tool broker with grant manifest A broker service sits between the agent and the tool registry. On each tool-invocation request the broker evaluates a grant manifest (agent_id x tool_id x task_id x TTL) against an OPA/Cedar policy, issues a short-lived signed token scoped to that tool, and rejects calls without a valid token or after expiry.

Why choose it: The most explicit and auditable pattern: every grant decision is policy-driven and logged. Appropriate for high-assurance environments where the mapping from task to permitted tools must be independently reviewable and the policy must be versioned separately from application code.

More details:

RFC 8693 OAuth Token Exchange The agent presents a broad subject_token to an OAuth STS implementing RFC 8693. The STS applies policy keyed on the requested audience (tool endpoint) and scope (permitted action), and returns a narrow access_token valid only for that tool, action, and a short expires_in window. Supports delegation chains via the act claim so the tool can audit which agent acted on whose behalf.

Why choose it: Standards-based; enables cross-service tool delegation with auditable actor chains. The act claim provides a verifiable record of principal delegation, which matters when the tool endpoint is operated by a different team or service.

More details:

Trade-offs

  • Grant overhead (approximately 10-50 ms per grant) is paid once per task when decisions are cached by task_id. Acceptable for task-duration actions; not suitable for per-call read-heavy workloads where grant overhead would exceed the time of the operation being gated.
  • JIT boundaries are only enforceable when task boundaries are well-defined. Free-form conversational agents with blurred task transitions lose the temporal anchor that makes grants meaningful.

When NOT to use

  • Agents issuing hundreds of read-only calls per minute: grant overhead relative to task duration makes JIT impractical for the read path; apply JIT only to high-risk write and external-action tools.
  • Perpetual background agents with no clear task boundary: without a defined task start and end, grant durations expand to session length and the control degenerates to session-scoped access.

Limitations

  • JIT grants assume the task boundary is well-defined. Free-form conversational agents whose tasks blur together lose the temporal boundary that makes grant expiry meaningful.
  • Tools required during agent initialisation must not be subject to JIT grant expiry. A grant that expires during startup causes a hard failure with no fallback.

Maturity tier reasoning

  • Tier 2 is appropriate because the underlying primitives (OPA, Cedar, MCP list_changed, AWS STS, RFC 8693) are individually production-mature. The agentic composition, specifically task-scoped tool grants with automatic revocation, is operational but not standardised: no industry-standard task-scoped tool-manifest schema exists.
  • A standardised task-to-tool grant protocol would elevate this to Tier 1. The adjacent controls (m-tool-scope and m-rbac-abac) address the same threat space with simpler deployment models and are better starting points for teams without an existing policy broker infrastructure.

Last verified against upstream docs: 2026-05-30.