Composio, the company that supplies tool access for AI agents across 1,500+ apps, has added a Firewall to its runtime. According to its documentation, Firewall "lets you block actions you don't want your agent to take, or tool results you don't want it to receive," and ships with a built-in check that blocks prompt injection in tool results before the agent sees them. It is marked experimental and sold on paid plans.
This matters because the hardest agent attacks do not come through the chat box. They arrive inside an email, a web page or a pull request that the agent reads while doing its job. This post separates what Composio's own pages confirm from what remains a claim, explains how the hooks work, and gives you a test plan.
TL;DR: Composio Firewall at a glance
| Question | Answer |
|---|---|
| What is it? | A hook layer that checks tool calls (before) and tool results (after) |
| Status | Marked Experimental in the docs |
| Price | Paid plans only: Composio's pricing page lists $0.50 per 1M tokens evaluated as a Pro add-on, included on Enterprise, not on Hobby |
| Built-in check | prompt_injection_check, after_execute only |
| Custom checks | condition_check with a natural-language condition |
| How are conditions judged? | A classifier sees the tool, its arguments, the result (for after hooks) and earlier session activity |
| Published block rates? | Not on the pages we read |
| Zero data retention caveat | With ZDR, the classifier cannot see session history |
What problem does Composio Firewall target?
Indirect prompt injection is when text an agent reads carries instructions the agent then follows. Composio's Firewall page shows two illustrative cases: an invoice email with a hidden line telling the assistant to export HubSpot contacts to an outside address, and a pull request whose README holds a comment telling AI reviewers to approve and merge without waiting for CI. In both, the sender never talks to the agent directly. The agent's own tool results are the attack surface.
A crooked hook catching a blank instruction card, illustrating prompt injection hidden in an agent's tool results
This is the same class of problem behind several incidents and tests we have covered, such as APEX-Harm's shared-workspace script injection results and Anthropic's red-teaming of auto mode and Codex Guardian monitors, where monitors missed more than half of attacks. A firewall at the tool boundary is one defensive pattern among several.
How do the hooks work?
Composio attaches checks to a session as hooks. Each hook has a unique id, a type, a scope and a handler.
- before_execute runs before the tool call and can block an action, such as emailing internal pricing to an outside address.
- after_execute runs on the result and can keep content from reaching the agent, such as an email containing an API key.
- applies_to lists toolkits such as Gmail, or the string
all. - handler is either
condition_check(your rule) orprompt_injection_check(the built-in screen).
A custom rule from the docs, shown here in Python, blocks pricing leaks:
session = composio.create(
user_id="user_123",
hooks=[{
"id": "no_pricing_to_customers",
"type": "before_execute",
"applies_to": {"toolkits": ["gmail"]},
"handler": {
"type": "condition_check",
"condition": "Sharing internal pricing with anyone outside acme.com",
"action": "block",
},
}],
)
When the rule fires, the call returns a blocked result with the error "Blocked by session policy" and a block_reason naming the hook. Frameworks surface that message to the agent. If several hooks apply and any one blocks, the call is blocked.
Why must a condition be written as a description?
The docs make a point that trips people up: write the condition as a description of what to block, not as an instruction to the agent. "Sharing internal pricing with anyone outside acme.com" works. "Don't share internal pricing with anyone outside acme.com" does not, because it describes nothing for a classifier to match. The same applies to "An email that contains a password, API key or access token" versus "Hide emails that contain...".
The classifier compares each call to the condition. It sees the tool, the arguments, and for after hooks the returned data. It also considers earlier activity in the session, which catches chained behavior: an email with a few numbers looks harmless unless the agent just copied them from an internal pricing sheet. The documented catch is zero data retention. With ZDR on, the classifier loses session history and judges each call in isolation, which weakens checks that depend on context.
What does the built-in injection check do?
The prompt_injection_check handler screens each tool result and blocks it if it contains an injection. It works only in after_execute hooks, since results are where outside content enters. The docs example applies it with applies_to: "all", so every toolkit's output is screened.
Two limits are stated or implied in the docs:
- It cannot undo the call. If the agent fetched a page that exploited something on load, the fetch already happened. The check only protects the model's context.
- Meta tools are not covered. Hooks do not currently run on Composio's own meta tools, so a condition like "Running a Workbench script" blocks nothing. Calls made from a Workbench script, proxy calls and multi-execute calls are covered.
Claimed versus verified
| Claim | Source | Status |
|---|---|---|
| Blocks prompt injection in tool results before the agent reads them | Composio docs and site | Documented behavior; effectiveness unmeasured publicly |
| Natural-language rules for tool calls and results | Composio docs | Documented with code samples |
| Reads "every tool result" so agents can work with sensitive data unsupervised | Composio Firewall page | Marketing framing; no audit published |
| Tracks attack rate, false alarms, work completed, added latency | Composio Firewall page | Metrics are named; the figures were not shown on the page we read |
| Available now | Composio site shows a NEW banner | Docs label it Experimental, paid plans only |
We found no independent test of Firewall and no changelog entry that pins down the release date, so the exact launch day is unconfirmed. Everything above comes from Composio's own docs and pages. That is a fair primary source for what the product does, and a weak one for how well it works.
Where does Firewall sit in the Composio stack?
Composio's developer page presents Firewall as one stage in a runtime pipeline that also covers per-user authentication, tool search, a sandbox for running code, a browser, skills, per-action permissions, a pay-per-use wallet for paid tools, and a trace of every call. Its homepage adds that passwords and tokens stay with Composio so the model never sees them, that actions can be limited or put behind approval, and that the company reports SOC 2 Type II compliance.
That context explains the design. Permissions answer "may this agent use Gmail at all", while Firewall answers a narrower question: "is this particular call, or this particular result, acceptable given what happened earlier in the session". The first is a static allow list. The second needs judgment, which is why Composio uses a classifier and why its quality, not its existence, is the thing to measure. For teams already on Composio, the cost of trying it is small, and the usage-based pricing means you can pilot it on one risky toolkit such as Gmail before turning it on everywhere.
How does this compare with other approaches?
Several layers are emerging, and they are complementary:
- Credential isolation. 1Password for Agents keeps passwords away from the model, so a hijacked agent cannot leak what it never saw.
- Gateways and spend limits. Walmart's agent gateway uses profiles and limits around MCP traffic.
- Tool-call classifiers. OpenRouter Armor scores calls with a small model, with claims we flagged as unverified.
- Government guidance. NIST, NSA and CISA's ten practices stress control and incident evidence for rogue agents.
Composio's twist is sitting where tool results enter, inside the integration layer it already operates, so adoption needs a few lines of session config rather than a new proxy. The trade-off is that you trust one vendor to both supply the tools and judge them.
What should you do before relying on it?
A thread following beads under a magnifying lens, illustrating a trace of blocked and allowed agent tool calls in a Composio Firewall test
Run your own evaluation. A reasonable plan:
- Build an injection set. Plant hidden instructions in emails, web pages and files your agent really reads, including white-on-white text and instructions inside quoted replies.
- Measure attack rate. Count how often the agent still acts on a payload with the hook on versus off.
- Measure false alarms. Feed ordinary but unusual content, like a vendor correcting an invoice, and count wrongful blocks.
- Measure task completion. Check that real jobs still finish.
- Time it. Record added latency per tool call, typical and worst case.
- Test the ZDR path if your project uses it, since context-dependent rules degrade.
- Pair it with before_execute rules for actions that must never happen, such as sending data outside your domain, because after hooks cannot undo.
- Review the logs. Every blocked call returns hook results you can export for audit.
For a layer that sits outside any one vendor's tool stack, AgentBeam, the agent security platform from the explainx.ai team, stops AI agents before they take dangerous actions and can be evaluated alongside hook-based checks like this one.
What to watch next
Watch for Composio publishing its four headline numbers, for real-world cost per tool call at the listed $0.50 per 1M tokens evaluated, and for third-party red-team results. If the false-alarm rate is low and the attack rate genuinely falls, tool-boundary filtering becomes a default for production agents. If not, it is another classifier that attackers will learn to phrase around. Until independent data lands, treat Composio Firewall as a promising, documented control with unproven strength. Details reflect Composio's documentation and website as read on October 22, 2026 and may change as the feature leaves experimental status.
Related reading
- APEX-Harm: shared-workspace script injection benchmark
- Anthropic red-teaming of auto mode and Codex Guardian monitors
- 1Password for Agents: sign in without seeing passwords
- Walmart agent gateway with MCP and spending limits
- OpenRouter Armor tool-call safety classifier
- NIST, NSA and CISA ten practices for agents
- What is MCP? The Model Context Protocol guide