Action Firewalls: Enforce Authority at Every Tool Call for Model-Driven Agents

# Why the Boundary Must Be the Action

Model-driven agents plan and then call external tools. When those tools can send email, update tickets, execute code, query databases, or approve payments, a mistaken decision becomes a real-world side effect. Security that inspects only the text entering or exiting the model misses the fundamental authorization point. The enforcement boundary needs to sit at the action, not the text.

# Scanning

Teams commonly scan inputs, retrieved documents, and model output for suspicious instructions. That helps catch obvious cases, but attackers can rephrase, split, encode, or hide instructions inside attachments, logs, or memory. Benchmarks and adaptive attackers have shown detection defenses are often bypassable. Detection reduces noise but cannot be the sole authorization mechanism.

# An Action Firewall Explained

An action firewall evaluates every proposed side effect before any tool, credential, or protected resource is reached. The model remains an untrusted planner that can propose actions such as http.post, renewal.approve, or email.send. The firewall decides whether to allow, deny, rewrite, or escalate each proposed action based on a precise policy and the provenance of the request.

# A Concrete Scenario: Poisoned Renewal Email

Task: read a renewal email thread, summarize open issues, and draft a reply to current participants. Authorized actions: read that thread, read renewal materials, draft a reply to those recipients. Not authorized: send the email, approve the renewal, add new recipients, upload contracts, or notify finance.

# Reference Monitor Principles

Design the firewall to follow the reference monitor model: it must always be invoked before protected resources are reached, resist tampering, and remain small enough to analyze and test. Those properties make the enforcement point auditable and reliable.

# What the Firewall Needs to Work

• Precise policies that map tasks to allowed actions and scopes.
• Provenance tracking so the firewall can reason about where a proposed action originated and what the original authorization granted.
• Complete mediation so there is no alternate path to a credential, API, or resource that bypasses the firewall.
• Minimal trusted code to reduce the audit surface and improve testability.

# Governance

# Practical Next Steps for Teams

• Map every tool call that can cause side effects and ensure it routes through a centralized enforcement component.
• Define clear, task-scoped policies that enumerate allowed actions and recipients.
• Implement provenance and logging so the firewall can make decisions with context and produce auditable records.

# Bottom Line

Scanning text is useful but insufficient. The control that actually prevents undesired side effects should evaluate the action itself, with clear policy, provenance, and a trusted, auditable enforcement path.