future agi protect vs failproof ai policies

Where Each Sits in the Request Path

An agent step has two halves. First the application sends a prompt to a model and gets back a response, which may propose a tool call. Then something executes that tool call - your code, an agent framework, or a harness like Claude Code - and the result goes back to the model. Protect and Failproof AI policies stand on different halves.

user or task
  -> application / harness
       -> [Protect: pre-processing checks]      Agent Command Center gateway
            -> model provider
       <- [Protect: post-processing checks]
  -> harness decides to run a tool
       -> [Failproof AI policy: PreToolUse]     inside the harness
            -> tool executes (Bash, Read, Write, ...)
       <- [Failproof AI policy: PostToolUse]
  -> result goes back to the model

Future AGI's docs describe gateway guardrails as checks that "run on every request and response flowing through Agent Command Center", catching content "before it reaches the LLM (pre-processing) or before it reaches your users (post-processing)." Failproof AI policies fire at the harness's own hook points: PreToolUse before a tool executes, PostToolUse after it returns, and Stop at the end of a turn.

Side by Side

The "Local shell and file actions" row is marked partial for Protect because Future AGI's docs do not describe that coverage, not because they rule it out. If you need an answer for a specific harness, ask Future AGI.

What Protect Sees, and Where It Is Stronger

Protect runs named guardrail checks and returns one of four actions: block, warn, mask or log. It works in two independent surfaces. In the gateway, a check configured once in the Agent Command Center covers every request in your organisation's routed traffic. Through the SDK, protect() screens one input inline in your own code and returns the verdict in the response body.

• Content checks Failproof AI does not have. The first-party list covers PII, prompt injection, secrets, content moderation, keyword blocklists, topic restriction, language detection, system-prompt protection, hallucination detection and data-leakage prevention.
• Modalities. Text, image and audio. A voice agent or a vision pipeline is covered in the same product.
• Outside scanners behind one interface. Provider-backed checks include Lakera Guard, Presidio, Llama Guard, Azure Content Safety and Bedrock Guardrails, among others.
• Remediation, not only refusal. PII can be masked, redacted or hashed on its way through, so a response is repaired rather than dropped.
• Language-agnostic coverage. Anything that speaks the OpenAI-compatible API through the gateway is covered, whatever it is written in.
• Tool and MCP checks at the same hop. Tool Permissions and MCP Security run in the pre-processing stage for traffic through the gateway.

For a customer-facing application, that list is most of what a guardrail layer is for, and Failproof AI does not compete with it. Failproof AI has no gateway, no response scanner and no image or audio checks.

What a Hook Policy Sees

A Failproof AI policy is a function the harness calls at a hook. At PreToolUse it receives toolName, such as Bash, Read or Write, and toolInput, which carries the command for Bash, the file_path for Read, and the file_path and content for Write. It returns allow, deny or instruct. A deny stops the action; an instruct lets it continue with guidance for the agent, and is never a safety boundary.

Because the harness is the thing about to run the command, the decision does not depend on how model traffic is routed. Here is a policy for a failure that happens entirely on the engineer's machine: an agent, told by text it read, tries to send the .env file to an outside host.

// egress-policies.js - stop env files leaving through a shell command
import { customPolicies, allow, deny } from "failproofai";

customPolicies.add({
  name: "block-env-upload",
  description: "Deny shell commands that send .env contents over the network",
  match: { events: ["PreToolUse"] },
  fn: async ({ toolName, toolInput }) => {
    if (toolName !== "Bash") return allow();
    const command = String(toolInput?.command ?? "");
    if (/\.env\b/.test(command) && /\b(curl|wget|nc|scp)\b/.test(command)) {
      return deny("Sending .env contents over the network is blocked. Ask a human if this is intended.");
    }
    return allow();
  },
});

Install it with failproofai policies --install --custom ./egress-policies.js. For the common cases there is no code to write: the coding agent policy pack (failproofai policies add FailproofAI/policies) has 38 policies, 10 on by default, including block-env-files, protect-env-vars, block-push-master, block-sudo, block-curl-pipe-sh and five sanitize-* redactors for secrets, with block-rm-rf, block-force-push, block-secrets-write and warn-destructive-sql among the rest. The limit is the flip side of Protect's strength: policies exist only in the twelve supported harnesses - Claude Code, Codex, GitHub Copilot CLI, Cursor, OpenCode, Pi, Factory Droid, Devin CLI, Antigravity CLI, Goose, Hermes and OpenClaw.

One Company, Two Request Paths

Take a company with a support assistant on its website and a dozen engineers using Claude Code on the same codebase.

1. The support assistant

   It is an application calling a model through the OpenAI SDK. Point it at the Agent Command Center, turn on the PII and injection checks in Monitor mode, read a week of verdicts, then switch the ones you trust to Enforce. A response carrying a card number is masked before the customer sees it. Failproof AI has nothing to add on this path.

2. The engineers' coding agents

   Their risk is actions: a rm -rf in the wrong directory, a force-push to main, a secret written into a config file. Install failproofai, run failproofai policies --install to wire the hooks and failproofai policies add FailproofAI/policies for the coding agent pack, add the custom rules your team needs, and the harness asks the policy before each command runs. Whether Protect also sees these sessions depends on whether their model traffic can be routed through the gateway - something to confirm with Future AGI.

Neither layer replaces the other here, and neither was built to. Each covers the path it stands on.

Cost and Who Runs It

Future AGI's pricing page lists built-in guardrails on every plan, including Free; the gateway meter is 100K requests a month free, then $5 per 100K. Self-hosting the gateway means running the Future AGI stack, which is Docker Compose with PostgreSQL, ClickHouse, Redis, Temporal and more. Failproof AI's policy engine is the MIT-licensed CLI, free and local, with unlimited local enforcement and custom policies. Failproof AI Cloud adds a policy editor, backtest against calls your agents already made, and observe-then-enforce rollout to machines; its tiers are Free, Team at $99, Scale at $599 and Enterprise on contract, with what each includes on /pricing.

Latency is the other cost. A gateway adds a hop to every model call, and every enabled check runs on it; Future AGI's README quotes a P99 at or under 21 ms with guardrails on (their figure). A hook policy runs in a local process just before each tool call, so it adds nothing to the model call and a little to each action.

Rolling Out Either One Without Breaking the Agent

Both layers can break a working agent if they go in at full strength on day one, and both are built to be introduced gradually.

1. Protect: Monitor, then Enforce

   Gateway guardrails have three enforcement modes. Monitor lets the request through with a 200 and logs a warning; Log records the violation silently; Enforce blocks with a 403. Run a new check in Monitor, read what it would have stopped, tune it, then move the checks you trust to Enforce. A 403 your application does not handle becomes an error the user sees, so decide what the app does with one before you switch.

2. Failproof AI: observe, then enforce

   In Failproof AI Cloud a policy is authored in Admin → policy editor, backtested against calls your fleet already made (by default every agent, last 30 days) to count the working calls it would interrupt, published as an immutable version, and deployed under Admin → enforcement in observe mode before enforce. Locally, failproofai policies lists what is enabled, and failproofai opens the local dashboard at http://localhost:8020. Write each deny reason as an instruction, as in the example above, because the agent receives it.

3. Both: count the false positives

   A regex over shell commands and a PII detector over responses both misfire. Keep a list of the legitimate actions each layer blocked in its first week, and fix the rule rather than teaching people to work around it.

What Neither One Does

Neither layer tells you whether the agent did its job well. A response can pass every Protect check and still be wrong; a session can clear every policy and still fail the task. That is evaluation, and both vendors treat it as a separate stage. Future AGI scores traces with built-in metrics and its Turing judge models. Failproof AI runs evaluations in the cloud when each session finishes - code checks, LLM judges, and existing eval sets in DeepEval or Ragas brought in as they are - audits populations of sessions for failure patterns, and from an issue can draft a policy with generate policy, which you backtest against calls your agents already made before deploying it. The usual order is evaluation first, to learn what goes wrong, then a guardrail or a policy for the failures you can name precisely enough to block. Evals vs guardrails covers that split.