Tool Firewall
Deny or log tool calls with rules based on context (e.g. user attributes, token claims, and tool arguments)
The Tool Firewall inspects each tool call before Gatana forwards it to the upstream MCP server. Each server has its own list of firewall rules. A rule has two parts:
- Condition: A CEL expression. The gateway evaluates it against the tool call and the caller's identity.
- Action: What to do when the condition matches.
| Action | Effect |
|---|---|
| Deny | Block the tool call. The client receives an error, and Gatana writes a firewall_deny audit event. |
| Log | Allow the tool call, and write a firewall_log audit event. |
The gateway evaluates the rules from first to last:
- If a Deny rule matches, evaluation stops immediately and the call is blocked.
- If a Log rule matches, the event is recorded and evaluation continues with the next rule.
- If no rule matches, the call is allowed.
A server with no rules allows all tool calls.
Configuring Rules
- In Gatana, navigate to Servers and open a server
- Select the Firewall tab (visible if you can update the server)
- Click Add Rule
- Select an Action (Log or Deny)
- Build the Condition with the query builder
- Click Save
The query builder produces a CEL expression. You can combine conditions with and/or, negate groups, and nest groups for more complex logic.
Rules are cached per server for 30 seconds. A saved change becomes effective on all gateway instances within that window.
Condition Fields
The condition can reference these fields:
| Field | Type | Description |
|---|---|---|
tool | string | Name of the tool being called |
args.* | varies | The arguments of the tool call. The query builder derives the available arguments from the tool schemas of the server. |
user.id, user.email, user.name, user.role | string | The calling user |
user.isServiceAccount, user.isDisabled | boolean | Flags on the calling user |
teams | list | Team IDs of the calling user |
profiles | list | Profile IDs active for the request |
claims.* | varies | Claims from the caller's token (for example from a federated JWT) |
authMethod | string | How the request was authenticated |
Example Conditions
Deny a destructive tool for everyone:
tool == "delete_repository"Deny writes outside a directory:
tool == "write_file" && !args.path.startsWith("/workspace/")Deny service accounts, but permit one team:
user.isServiceAccount == true && !teams.contains("team_a1b2c3")Log every call that carries a specific token claim:
claims.env == "production"Auditing
Both actions write to the audit log with the matched condition and the tool name. Deny writes firewall_deny, and Log writes firewall_log. You can inspect these events in the server's Audit Logs tab, or forward them with SIEM Streaming.
Related
- Profiles — control which servers and tools are available at all
- Limiting Servers — restrict servers with a query-string parameter