FailproofAI: A Local Enforcement Layer for AI Agent Harnesses

What FailproofAI Solves and Who It Serves

FailproofAI addresses a specific pain point: AI coding agents and chat assistants execute tool calls with little oversight. A model might run a destructive shell command, modify files outside the project, or exfiltrate data before a human notices. FailproofAI positions itself as a hook layer that sits between the agent harness and the outside world, capturing every run and blocking dangerous tool calls before they execute. The intended users are engineers and teams running agents like Claude Code, Codex, or Copilot CLI in development or production environments, who want a safety net that does not require sending their session data to a third-party cloud. The README emphasizes that it runs locally, requires no account for the dashboard, and offers a generous free cloud plan for those who want remote features. This makes it attractive for privacy-conscious teams or those with strict data residency requirements.

How It Works: Hooks, Events, and Policies

The mechanism is built on hooking into supported harnesses. FailproofAI claims to hook twelve agent harnesses, split into ten coding CLIs and two chat or assistant gateways (Hermes and OpenClaw). The architecture appears to intercept events from each harness, normalize them into a common event format, and apply a set of built-in policies. The README states there are 39 built-in policies, though the description elsewhere mentions 40; the discrepancy suggests the count may have changed between versions. Policies likely evaluate tool calls against rules, and when a dangerous call is detected, the hook blocks it before execution. The same event stream, policies, and session history apply across all supported harnesses, meaning you get a unified view regardless of which agent you run. For agents not in the supported list, a Python SDK provides tracing, sessions, and audits, but enforcement requires a hook in your own runtime, which the README says requires contacting the vendor for mapping.

Installation and Getting Started

The README shows a minimal installation command: 'npm'. The full command is truncated, but it clearly points to an npm package named 'failproofai', as indicated by the npm badge. After installing the package, you would likely configure it to hook into your harness. The README does not provide explicit configuration steps, but the repository includes documentation at docs.befailproof.ai, which would contain the details. Given the supported harnesses, setup probably involves adding a hook or plugin to each CLI, such as a Claude Code hook or a Codex plugin. The local dashboard suggests a command to start a web UI, though that command is not shown. The lack of explicit setup instructions in the README is a gap; you must consult the external docs to get running. The presence of a Python SDK for custom agents indicates a different install path, likely 'pip install' or similar, but that is not documented in the available material.

The Policy Engine and Its Limits

FailproofAI ships with 39 built-in policies, which is the core of its enforcement value. These policies likely cover common failure modes like dangerous shell commands, file system modifications outside allowed paths, network calls to unexpected hosts, or secrets in prompts. The README claims 'zero latency', which is a strong assertion; in practice, any hook adds some overhead, and the claim is unverified in the provided material. A genuine limitation is that policies are fixed to a built-in set unless you can write custom policies. The README does not mention custom policy authoring, which could be a problem for teams with specific security requirements. Another limitation: enforcement only works for the twelve supported harnesses. If you run a different agent or a custom harness, you lose the blocking capability and only get tracing via the SDK, which requires additional integration work. The policy engine's effectiveness depends on the quality and coverage of those 39 rules, and without a policy language, you cannot adapt it to your unique threat model.

Supported Harnesses and the Custom Agent Gap

The supported harness list includes major coding CLIs: Claude Code, OpenAI Codex, GitHub Copilot CLI, Cursor Agent, OpenCode, Pi, Factory Droid, Devin CLI, Antigravity CLI, and Goose. Two chat gateways, Hermes and OpenClaw, round out the twelve. This coverage is broad for coding agents, but it is not exhaustive. The README explicitly notes that agents running in none of these harnesses can report through the Python SDK, which gives tracing, sessions, and audits. However, enforcement there needs a hook in your own runtime, and the README says to contact the vendor for mapping. This is a real gap: if you have a custom agent or an internal tool, you cannot get policy enforcement out of the box. You must build the hook yourself or rely on the vendor's consultation. For teams that use only the supported harnesses, this is not an issue, but it limits the tool's applicability to a specific ecosystem.

Alternatives and the Difference in Approach

A direct alternative is building your own hook scripts using each harness's native hook system. For example, Claude Code supports hooks that can run scripts before or after tool calls. That approach gives you full control over logic but requires you to implement logging, policy checks, and session management yourself. FailproofAI abstracts that by providing a unified layer across multiple harnesses, so you write policies once instead of per-harness. Another alternative is a cloud-based observability platform that offers guardrails, but those typically send data to a third party, which conflicts with FailproofAI's local-first design. The difference in approach is that FailproofAI centralizes policy enforcement and session history into one local system, whereas native hooks are fragmented and require per-tool maintenance. The trade-off is that native hooks are more flexible and do not introduce a dependency on a specific vendor's policy engine.

Licensing and Maintenance Considerations

The repository license is marked as NOASSERTION in the metadata, but the README badge indicates a license of 'MIT + Commons Clause'. The Commons Clause is a restriction that limits the commercial use of the software, meaning you can use it freely for internal purposes but cannot resell it or offer it as a hosted service without a separate agreement. This is a critical consideration for any company that might want to embed FailproofAI in a commercial product. The README also mentions a 'generous free cloud plan', which suggests there is a commercial cloud offering that may have its own terms. Maintenance-wise, the project is actively developed, with recent releases in September 2026, including version v1.0.4-beta.4. The beta status indicates that the API and policies may change, so upgrading could require adjustments. The supply chain badge claims 'secure', which implies they run OSV scanner, but the exact details are not in the material. You should verify the license terms with your legal team and plan for potential breaking changes while the project is in beta.

Editorial conclusion

Adopt FailproofAI if you run coding CLIs or chat gateways among the twelve supported harnesses and need local, policy-driven control over agent tool calls without a cloud dependency. Skip it if you use a custom agent runtime that cannot be hooked, since enforcement there requires manual integration and vendor engagement. Before adopting, verify that the 39 built-in policies match your specific risk scenarios, confirm the license terms with your legal counsel given the Commons Clause, and test the zero-latency claim in your own environment, since the README provides no independent benchmark data.

Official sources

1. FailproofAI/failproofai on GitHub
2. Issues
3. Project website
4. README
5. Releases