PulseFlow Tecnologia
← Insights
·7 min read·technical-guide·guardrails·tool-use·authorization
PulseFlow Tecnologia

How to create guardrails for tool use in agents

Recent academic research found something uncomfortable in three of the market's most-used agent frameworks - LangChain, LlamaIndex, and Stripe Agent Toolkit: all of them "conflate tool exposure with authorization." In other words, exposing a tool to the model doesn't mean, by default, that each individual call gets authorized with specific values before executing. In practice, the researchers demonstrated an unauthorized payout call executing under LangChain's default dispatch - the classic "confused deputy" problem, now showing up in AI agents.

A list of allowed tools isn't the same as per-call authorization

The common mistake is confusing "the tool is on the list of available tools" with "this specific call is authorized." All three audited frameworks offer capability gating by default - deciding which tools exist - but none offers, by default, a deterministic, fail-closed authorization gate by value and by call.

Risk per tool: not every tool needs the same guardrail

A read-only tool has a completely different risk profile from one that moves money, deletes a record, or sends external communication. Guardrails proportional to each tool's risk - not a generic guardrail applied equally to everything - is what avoids both excess friction on low-risk tools and excess exposure on critical ones.

ScopeGate: the five-step mechanism that zeroed out bypasses

The response the researchers themselves propose, ScopeGate, structures the guardrail in five steps: scope (what the tool can do), authorization (who/what approved this specific call), monetary limit (max value per call), idempotency (the same call doesn't execute twice by mistake), and default denial (fail-closed when something isn't explicitly allowed). Tested against 48 static bypass attempts and 29 adaptive attempts across 40 iterations, the result was zero successes in both cases - with 10-out-of-10 containment on a payments agent, and zero false positives on legitimate cases.

Argument validation as part of the gate, not a separate step

Authorizing the right tool with the wrong argument is still a failure. The per-call authorization gate needs to validate not just whether the tool can be called, but whether that call's specific values (amount, recipient, data scope) are within what's allowed.

Isolated environments, logs, alerts, and revocation

Every tool call should run in an environment isolated enough to contain the damage if something slips past the gate. Logs of every tool call - not just errors, every call - enable auditing after the fact. Alerts for unexpected patterns (abnormal volume, out-of-range values) complement the deterministic gate with anomaly detection. And access revocation - the ability to shut off a tool or credential immediately once an incident is identified - closes the loop.

Guardrails checklist

  1. List of allowed tools - capability gating, the starting point, not the end
  2. Risk per tool - proportional guardrail, not generic
  3. Argument validation - part of the authorization gate, not a separate step
  4. Approval policy - who/what authorizes each call
  5. Default deny - fail-closed when not explicitly allowed
  6. Financial limits - max value per call, not just per day
  7. Isolated environments - contain the damage if the gate fails
  8. Tool call logs - every call, not just errors
  9. Alerts - volume or value anomalies
  10. Access revocation - shut off quickly when needed

Sources