Skip to main content
BlogNewsletterRSS
Back to changelog

Block risky agent tool calls with AI Gateway Firewall

Avatar for Nijiko Yonskai

Nijiko Yonskai

Your coding agent can run shell commands, push to GitHub, and call every tool on your MCP servers. One bad tool call can force-push over main or send an AWS key somewhere it doesn’t belong. Firewall checks that traffic in AI Gateway and stops anything that breaks your rules before your agent runs it.

You attach a Firewall policy to access keys, not to an agent. Every agent that uses those keys gets the same checks without a code change. A request can add its own rules, but it can’t remove the policy’s.

Checks before and after the model

Firewall checks each request at two points:

  • Request rules run before the gateway sends the request to the model. They read the conversation, the output of tools your agent ran, and the tools your agent offers the model. A blocked request never reaches the model.
  • Response rules run on each tool call the model returns, including in a streamed response. Firewall removes a blocked call from the response, so your agent never receives it.

Rules and policies

Each rule matches in one of three ways:

  • Tool names match whole tool names, with * as a wildcard. mcp__payments__* matches every tool from a payments MCP server.
  • Regex matches an RE2 pattern, such as AKIA[0-9A-Z]{16} for AWS access keys in tool output.
  • Decision rules describe a risk in plain language, such as “Deletes files outside the project directory.” Jev, a decision model, judges the text against the rule. The rule matches when Jev’s confidence reaches the threshold you set.

Tool names and regex rules don’t call a model, so they add almost no latency. Each decision rule can add up to 1.5 seconds. Decision rules don’t use your credits.

Each rule also has a type. Hard block always blocks. Soft block blocks unless an Allow rule in the same policy also matches. Pair them for exceptions, like blocking every git push except pushes to feature branches.

A policy runs in one of two modes. Enforce blocks matches. Dry run checks everything and reports what matched, but lets it all through, so you can tune rules on real traffic first. On error decides what happens when Firewall can’t check something: Block it or Continue.

Apply a policy to all access keys as your account baseline, or only to the keys in the access key configurations you pick. A key’s baseline and its configuration’s policy both run, and each keeps its own mode.

A block isn’t an HTTP error. The gateway returns a normal 200 response, so your agent keeps working. Once you enforce the policy above, a call to any mcp__payments__ tool comes back as assistant text that names the tool and the “Payments MCP server” rule, and tells the model not to retry it with the same arguments. The model can change course, and the response’s safeguard_results field reports the verdict for each tool call.

Supported requests and limits

Firewall checks OpenAI Chat Completions (/v1/chat/completions), OpenAI Responses (/v1/responses), Anthropic Messages (/v1/messages), and Gemini generateContent and streamGenerateContent requests, streamed or not. That covers agents that call those endpoints through the gateway, such as Claude Code and Codex.

We’re still working on Firewall, and some behavior may change. These limits apply today:

  • Firewall doesn’t check other endpoints, such as the Gemini Interactions API. If an enforced policy on the key has On error set to Block, the gateway rejects those requests. Set On error to Continue, or send them with a key the policy doesn’t apply to. Your baseline applies to every key, so for a baseline, change On error.
  • Firewall checks tool calls, not the function calls a model returns for the legacy Chat Completions functions field. Send tools instead.
  • In a Responses request, Firewall can’t read the arguments of tools that OpenAI defines and your app runs, such as local_shell, computer use, and apply_patch. Tool names rules still match them by name. For other rules, On error decides.
  • After Firewall blocks a tool call in a Responses request, OpenAI still keeps the original call. If your next request uses previous_response_id, OpenAI expects output for a call your agent never received. Send the conversation in input instead.
  • Tools the provider runs, such as hosted web search, never reach your agent, so Firewall doesn’t check them.
  • Firewall results don’t appear in Logs yet. Read the safeguard_results field and the Ngrok-AIG-Firewall-Request header in the response instead.

Get started

  1. Create an ngrok account or sign in. You need an access key and an agent or app that calls a supported endpoint with tools.
  2. Open Firewall and click New firewall policy. Enter a Name, then select Dry run under Mode. New policies start in Enforce.
  3. Edit the example rule under Response rules, or click Add rule. Pick a Type and a Match for each rule. For a request rule, pick what it Reads.
  4. To try the rules on one request, copy the plugins field under Try it in one request into the request body.
  5. Under Apply to, select All access keys or Only these configurations, then click Create policy.
  6. Send requests with a key the policy applies to. Read safeguard_results in each response to see which rules matched.
  7. When the results look right, open the policy, select Enforce under Mode, and click Save changes.

The Firewall guide has more example rules and the API steps. The Firewall docs explain how policies combine and what a blocked agent receives.