Action Firewall - Block Destructive AI Agent Actions
Pricing
Pay per event
Action Firewall - Block Destructive AI Agent Actions
A safety gate in front of every agent action. Classifies a proposed shell, SQL, API, payment, or delete as allow / require-approval / block against a destructive-action taxonomy and your policy, before it runs. Catches rm-rf, fork bombs, DROP TABLE, and force-push.
Pricing
Pay per event
Rating
0.0
(0)
Developer
Creator Fusion
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
4 days ago
Last modified
Categories
Share
Agent Action Firewall
Creator Fusion Labs — Agent Protection Suite
A pre-execution safety gate for AI agents. Your agent submits a proposed action — a shell command, SQL statement, HTTP request, file operation, message/email, or payment — and the firewall classifies it before it runs, returning a verdict (allow, require-approval, block), a 0-100 risk score, the exact rules that matched, and a recommendation. Wire it in front of any tool-execution step so a destructive or unauthorized action is caught instead of executed.
This is a stateless classifier: it reads only the action you pass. No network calls, no data collection, no credentials.
What it catches
- Destructive / irreversible verbs —
rm -rf,DROP/TRUNCATE,DELETE/UPDATEwithout aWHERE,git push --force, disk format/dd/shred, fund transfers/payments, publish/deploy-to-prod. - Remote code execution —
curl … | shstyle download-and-run. - Data egress — outbound
POST/PUT/upload carrying credential- or PII-looking data. - Blast radius — root/
//wildcard scope, recursive flags, and production targets escalate the score. - Policy — optional
allow/denylists and amaxRiskceiling.
Input
| Field | Type | Notes |
|---|---|---|
action | string (required) | A command string (e.g. "rm -rf /tmp/cache", "DROP TABLE users;") or a JSON object (as a string, or a real object via API/MCP) with type, command, target, args. |
policy | object | { allow: [...], deny: [...], maxRisk: 0-100 }. deny forces block; allow permits non-critical actions; maxRisk caps silent allows. |
environment | string | prod | staging | dev. prod escalates flagged actions. |
Output (one row per run)
{"verdict": "block","riskScore": 100,"category": "filesystem","matchedRules": [{ "rule": "fs-recursive-force-delete", "severity": "critical", "detail": "Recursive force delete (rm -rf …) — irreversible bulk file removal." }],"reasons": ["[critical] Recursive force delete …", "Targets a root / whole-filesystem / global scope."],"recommendation": "Do NOT execute. Destructive/irreversible or explicitly denied; escalate to a human."}
verdict thresholds (before policy overrides): riskScore ≥ 60 → block, ≥ 25 → require-approval, else allow.
Use it from an agent
MCP — add the actor to your Apify MCP server and call it as a tool, passing { "action": "<command>" }.
curl
curl -X POST "https://api.apify.com/v2/acts/apricot_blackberry~agent-action-firewall/run-sync-get-dataset-items?token=$APIFY_TOKEN" \-H 'Content-Type: application/json' \-d '{ "action": "rm -rf /", "environment": "prod" }'
JavaScript
import { ApifyClient } from 'apify-client';const client = new ApifyClient({ token: process.env.APIFY_TOKEN });const { defaultDatasetId } = await client.actor('apricot_blackberry/agent-action-firewall').call({ action: 'DROP TABLE users;' });const { items } = await client.dataset(defaultDatasetId).listItems();if (items[0].verdict !== 'allow') throw new Error(`Blocked: ${items[0].recommendation}`);
Python
from apify_client import ApifyClientclient = ApifyClient(token)run = client.actor("apricot_blackberry/agent-action-firewall").call(run_input={"action": "ls -la ./logs"})row = next(iter(client.dataset(run["defaultDatasetId"]).iterate_items()))print(row["verdict"], row["riskScore"])
Pricing
Pay-per-event: an actor-start fee plus one evaluate event per successful classification. Failed/invalid-input runs emit an auditable error row and are not charged the evaluate event.
Limitations
Heuristic, not a sandbox — it scores the text of a proposed action against a curated rule set. Treat require-approval/block as strong signals, not a formal proof of safety, and keep a human in the loop for high-stakes actions. Obfuscated commands (base64, heavy indirection) may score lower than their true intent.


