The verification layer for autonomous AI agents

Why does autonomous agent output need a verification layer?

Because autonomy scales confident error as readily as correct work. Governance patterns that enable a fleet to act — the file-based directive protocol and 23-principle constitution described in the cited research — decide what an agent is allowed to do. None of that inspects whether the claims the agent then makes are true. That is a separate primitive, and it has to run on the output, not the permissions.

The failure mode is specific: an agent asserts a fact, a statistic, or a citation that is fabricated, and it does so fluently. Downstream, a human or another agent reads it as settled. A verification layer breaks that chain by treating the agent as a witness that has to be checked rather than the only witness to its own accuracy.

What does Faultline actually check?

Faultline isolates each verifiable claim in a block of text and returns a verdict per claim: VERIFIED (supported by sources), REFUTED (contradicted), UNSUPPORTED (checked, no supporting evidence found), or MIXED (evidence cuts both ways). A fifth label, UNCHECKED, is explicitly not a verdict — it marks a claim verification could not run on, so a degraded check never masquerades as a pass.

Whether a verdict is backed by retrieved evidence depends on the path. On the hosted API and on a local Gemini key, verification retrieves live sources and verdicts arrive with evidence URLs attached. Other providers — OpenAI, Anthropic, Perplexity — judge claims from the model’s own knowledge without retrieving anything; those verdicts report grounded: false so a reader can tell a sourced result from an unsourced one. Faultline never blurs the two.

Where does it sit in an agent stack?

At the boundary between an agent and whoever reads it. The shipped surface today is two mounts. `faultline guard` sits in the pipe — a shell pipeline, a CI step, or a Claude Code Stop hook that checks the agent’s own transcript the moment it finishes; advisory by default, a gate with `--fail-on refuted`. `faultline-action` sits in CI, checking a pull request’s body or release notes and uploading findings to GitHub code scanning as SARIF.

A third mount — an MCP server that exposes verification as a tool inside the harness itself — is built but not yet published, so the install commands for it do not resolve. Until it ships, the Stop-hook recipe on the Agent Guard docs page does the same job from the pipe and is available now.

Full install and hook details: Agent Guard documentation.

What Faultline deliberately does not verify

v1 checks informational claims — statements about the world that sources can settle. It does not check operational claims like “the tests pass” or “it’s deployed.” Those are answered by deterministic probes against your own systems; asking a language model whether your tests passed just reproduces the problem you were trying to solve. Drawing that line is the point, not a limitation — a verifier that pretends to settle operational state would be another confident, unbacked assertion.

How does this map to agent-governance frameworks?

A per-claim verdict with an evidence trail is the raw material governance frameworks ask for. Faultline maps its findings onto the framework a buyer names next — the transparency and human-oversight expectations of the EU AI Act, or the measure-and-manage functions of the NIST AI Risk Management Framework. The verification runs once; the mapping is the reporting surface on top of it.

This is the complement to orchestration. Frameworks like Forge decide how a fleet of agents is coordinated and permitted to act; Faultline verifies what those agents assert once they do. Enablement and verification are the two halves of governing autonomous output — one lets the work happen, the other makes it accountable.

Frequently asked questions

Does Faultline verify AI claims against live sources?

On the hosted API and with a local Gemini key, yes — verification retrieves live sources and verdicts come back with evidence URLs. Other providers (OpenAI, Anthropic, Perplexity) judge from the model’s own knowledge and are flagged grounded: false, so unsourced verdicts are never presented as evidence.

Can Faultline check an AI agent’s output automatically?

Yes. `faultline guard` runs as a Claude Code Stop hook or in any pipeline or CI step, checking the agent’s output the moment it finishes. It is advisory by default and becomes a hard gate with `--fail-on refuted`, which also fails when verification was degraded rather than passing an unchecked claim.

Does Faultline verify operational claims like “the tests pass”?

No. v1 verifies informational claims that sources can settle, not operational claims about your own systems. Statements like “the tests pass” or “it’s deployed” need deterministic probes against those systems — asking a language model to confirm them would just repeat the original problem.

What verdicts does Faultline return for each claim?

Five labels: VERIFIED (supported by sources), REFUTED (contradicted), UNSUPPORTED (checked, no evidence found), and MIXED (evidence both ways). The fifth, UNCHECKED, is not a verdict — it marks a claim verification could not run on, so a degraded check is never counted as a pass.