galileo agent control vs failproof ai policies

What Each One Is

Agent Control is Galileo's open-source control plane for agents, launched in March 2026 and now the replacement for the deprecated Galileo Protect. You mark a function in your agent with the SDK's @control() decorator, and that function becomes a governed decision point. What gets evaluated, by which evaluator and with what consequence is defined on the Agent Control server rather than in the agent's code; Galileo's framing is that developers decide where the control points go and policy teams decide what they enforce. Controls evaluate "LLM and tool inputs and outputs" and return deny, steer, warn, log or allow.

Failproof AI policies run at a different seam. Twelve harnesses - coding CLIs such as Claude Code, Codex, GitHub Copilot CLI, Cursor, OpenCode and Goose, plus the Hermes and OpenClaw chat gateways - expose lifecycle hooks for model prompts and responses, tool calls and results, and the end of a turn. The open-source failproofai CLI registers policies on those hooks. A policy is a JavaScript or TypeScript function that returns allow, instruct or deny. You do not change the agent, because the harness calls the hook.

So the honest headline is that both cover tool calls, and neither is only a model-output filter. The differences are where they hook in, what ships ready to use, and who operates the thing.

Side by Side

If you read one row, read "agents it fits". The two tools rarely compete for the same agent: one attaches to code you wrote, the other to a harness someone else wrote.

Where Each Hooks in, and Why It Decides Most Cases

A decorator needs a function to decorate. For an agent you build - a support agent on CrewAI with an issue_refund tool, a research agent on LangChain - that is exactly right: the tool is your function, you put @control() on it, and every call passes through Agent Control before it executes. The control sees the arguments, and the server decides.

A coding agent inverts that. Claude Code's Bash and Write tools are not functions in your repository; they run inside the harness. What the harness gives you instead is a hook, and that is where Failproof AI sits: ctx.toolName says which tool is about to run, ctx.toolInput carries its arguments - command for Bash, file_path and content for Write - and the policy decides before anything executes. The integrations Galileo names for Agent Control are agent frameworks you build with; check whether your harness is covered before counting on it.

The same split shows in what each can see. Agent Control sees exactly the steps you decorated, with whatever context you pass it. Failproof AI sees every tool call the harness makes, including the ones nobody thought to wrap, but only in the twelve harnesses it supports. An agent you build on a framework can send its sessions to Failproof AI through the Python SDK, which has LangChain/LangGraph, CrewAI, LlamaIndex and Pydantic AI adapters, but the SDK "does not enforce policies on its own"; for enforcement inside that agent, Agent Control is the tool.

Where Agent Control Is Stronger

• Model-based evaluators at the gate. A control can call Galileo's Luna, NVIDIA NeMo, AWS Bedrock or Cisco AI Defense, and one policy can combine them with a regex check - useful for prompt injection, toxicity or off-topic answers that no pattern catches, decided before the step runs. Failproof AI's coding agent pack is deterministic rules, and its LLM judges run as evaluations in the cloud after a session finishes, not at the gate. Luna-2 itself is Enterprise-only.
• Model I/O as a first-class stage. The same control plane covers what the model is told and what it says, not only the tools it calls.
• Five decisions, not three. Warn and log let a control flag or record without blocking, so a new control can run in shadow before it denies anything. Failproof AI gets the same effect through observe mode in its cloud enforcement workflow, but the open-source CLI's decisions are allow, instruct and deny.
• Separation of duties. Controls live on the server and change through its API or UI without redeploying the agent, so a policy team can own them.
• Framework reach and partners. Integrations for LangChain, CrewAI, Google ADK and AWS Strands, with CrewAI, Glean, ServiceNow, Rubrik and Cisco AI Defense among its launch partners.

Where Failproof AI Policies Are Stronger

• Nothing to wire in. failproofai policies --install wires the hooks into your agent CLIs, and failproofai policies add FailproofAI/policies adds the coding agent pack. No decorators, no SDK inside the agent, no code change.
• A maintained pack on day one. The coding agent pack has 38 policies, 10 on by default: block-push-master, block-env-files, protect-env-vars, block-sudo, block-curl-pipe-sh and five sanitize-* redactors for API keys, bearer tokens, JWTs, private keys and connection strings. Others, such as block-rm-rf, block-force-push, block-secrets-write and warn-destructive-sql, are one command away. Agent Control ships evaluators; the rules are yours to write.
• No server. The open-source CLI enforces locally, with unlimited enforcement under MIT. Agent Control's open-source server and its PostgreSQL database are yours to run and keep up; the managed version is Galileo Enterprise.
• Turn-end gates. A Stop policy runs when the agent tries to end its turn and can refuse to let it stop until the work is done. That is a lifecycle event of the harness, not a function call, and turn-end gates are verified on eight of the twelve harnesses.
• A loop behind it. In Failproof AI Cloud, evaluations score each finished session, audits cluster failures into findings with a recommendation, and generate policy drafts a policy from the resulting issue. You backtest the draft in the dashboard against calls your agents already made, publish it from the policy editor, and deploy it in observe mode before you enforce it.

One Rule, Both Tools

Take the rule "an agent must never run destructive SQL against production" and put it in each tool.

1. In an agent you built, with Agent Control

   Your agent has a run_sql tool. You decorate it with @control(), and on the server you define a control that runs before the step, with a SQL or regex evaluator matching DROP TABLE or TRUNCATE against a production target and a deny decision. The next matching call raises ControlViolationError; your agent catches it and tells the user why.

2. In a coding agent, with Failproof AI

   The agent has no run_sql tool; it runs psql through Bash. A PreToolUse policy reads the command and denies it before the harness executes it.

   // db-policies.js - destructive SQL against production, stopped before it runs
   import { customPolicies, allow, deny } from "failproofai";
   
   customPolicies.add({
     name: "block-prod-drop",
     description: "Deny destructive SQL against the production database",
     match: { events: ["PreToolUse"] },
     fn: async ({ toolName, toolInput }) => {
       if (toolName !== "Bash") return allow();
       const command = String(toolInput?.command ?? "");
       if (/\b(DROP\s+TABLE|TRUNCATE)\b/i.test(command) && /\bprod(uction)?\b/i.test(command)) {
         return deny("Destructive SQL against production is blocked. Write a migration and open a PR instead.");
       }
       return allow();
     },
   });

3. Rolling it out

   With Agent Control, start the control on log, read what it would have denied, then switch it to deny. With Failproof AI Cloud, backtest the policy against your fleet's recent calls to count the working ones it would interrupt, deploy it in observe mode, then enforce. With the local CLI alone, failproofai policies --install --custom ./db-policies.js enforces immediately.

Neither is free of work. The SQL pattern has to be precise in both, and a rule that blocks legitimate migrations will get switched off. The difference is only where the check lives.

What Each Costs to Run

Neither license costs anything; the difference is what you keep running. Open-source Agent Control is a service: the SDK in each agent calls the Agent Control server, or a local cache when one is configured, and the server needs PostgreSQL. That is one more thing to deploy, monitor, back up and upgrade, and it sits on the path of every governed call, so plan for what happens when it is unreachable. What you get for it is real - central control, changes without redeploys, rules a policy team can own - and Galileo sells the managed version to Enterprise customers who would rather not run it.

Failproof AI's open-source CLI runs locally beside the harness, through the failproofaid daemon it installs, with policy parameters in .failproofai/policies-config.json for a project or ~/.failproofai/policies-config.json for a user, and decides on the machine. There is nothing to keep up centrally until you want central management: failproofai config --token <key> connects it to Failproof AI Cloud, where policies are written in the policy editor and deployed from Admin → enforcement. The cost of that simplicity is the other side of its benefit: rules are code, and they change by publishing a new, immutable version rather than through a runtime API.

Running Both

A team with both kinds of agent can run both without overlap: Agent Control on the framework agents it builds, Failproof AI on the coding agents its engineers use. They answer to different hooks and never see the same call. If you already evaluate with Galileo, Agent Control is the natural choice for your own agents, since its evaluators include Luna. If your agents are mostly Claude Code or Codex sessions, npm install -g failproofai, failproofai policies --install and failproofai policies add FailproofAI/policies is a shorter path than wrapping anything.