ClaimGuard catches what
your agent confidently got wrong.
Injection attacks and out-of-scope requests are visible in structure. Hallucinations aren’t — they look exactly like correct answers. ClaimGuard captures every response, extracts factual assertions, and checks them against the tool results captured earlier in the same session, flagging contradictions in your audit trail.
The hallucination problem in production
CleverGuard and ScopeGuard stop inputs that are structurally wrong — injections, credential leaks, out-of-mandate requests. ClaimGuard addresses a different failure mode: a valid prompt, a structurally correct response, and a confident assertion that is simply false. The agent isn’t hijacked. It’s wrong, and it doesn’t know it.
The three guards are additive — CleverGuard runs on every call, ScopeGuard runs on top for governed agents, ClaimGuard verifies on the response side after delivery.
Six hallucination patterns ClaimGuard targets.
These are the patterns that pass every other guard and reach your users as confident, authoritative answers. Today ClaimGuard catches them when a contradicting tool result exists earlier in the session; the patterns marked “Medium risk” need the external knowledge-base connectors on the roadmap to fire reliably.
“"Refunds are processed within 90 days under policy WAC 308-100." (real window: 30 days)”
“"According to our Q4 2024 compliance report, section 4.2..." — no such report exists”
“"The Team plan includes unlimited governed agents." — the source of truth caps Team at 25 governed agents”
“"The Pro plan is $29/month." — price changed to $49 six weeks ago”
“"I checked your account and the last invoice was paid on March 4th." — no such lookup occurred”
“"You can request that via the Settings → Billing tab." — that tab was removed in v3”
Response captured. Claims verified. Contradictions flagged.
ClaimGuard runs on the response path — after the model generates output, verification happens asynchronously. The check is invisible to the agent and adds no round-trip latency from the user’s perspective.
Response captured for verification
Every AI response is captured by ClaimGuard as it is delivered. Verification runs asynchronously on the response side — the agent never knows its output is being checked, and the check adds no round-trip latency for your user.
Claims extracted from the response
ClaimGuard identifies the factual claims in the response: policy statements, dates, amounts, citations, product details, and any assertion that could be wrong. Hedged statements ('I think...', 'It might be...') are excluded — only confident assertions are flagged for verification.
Claims checked against session tool results
Today ClaimGuard verifies claims against the tool results captured earlier in the same session — if a tool returned refund_window=30 and the agent says "90 days", that's caught. External knowledge-base connectors (Notion, Confluence, internal wikis, uploaded PDFs) are on the roadmap; if your sources don't cover a claim, ClaimGuard marks it unsupported rather than inventing a verdict.
Flag, alert, or annotate
Claims that fail verification are handled according to your policy: flag the session for human review, raise an alert, or record an inline annotation on the audit record. Per-agent policy so your customer-facing agents can be stricter than your internal ones.
Unverified claims logged to the audit trail
Every unverified claim that reached a user is logged with full context in your audit trail and the agent's Governance tab: what was claimed, what the actual source says (if found), and whether the claim was corrected on retry. Use this to tune your knowledge sources and close coverage gaps.
Architecture — self-hosted extractor + session tool-result lookup
ClaimGuard uses a Clevername-operated, self-hosted model as a lightweight extractor pass to identify factual assertions in the response — with no live fallback to a managed provider; if the self-hosted service is unreachable, extraction is skipped (zero claims returned) rather than routed elsewhere — then looks up the tool results captured earlier in the same agent session to find corroborating or contradicting evidence. The extractor is scoped to factual claims only — it ignores opinions, instructions, and hedged statements to keep precision high. Results are cached per-claim so repeated assertions across calls don’t incur repeated lookup cost. MCP connectors for external sources (Notion, Confluence, internal wikis) are on the roadmap.
What ClaimGuard does not do
Does not verify claims outside your session
Today ClaimGuard checks claims against the tool results captured earlier in the same agent session — not the open internet or general world knowledge. External knowledge-base connectors (Notion, Confluence, wikis, PDFs) are on the roadmap. If a claim has no in-session tool result to verify against, ClaimGuard flags it as unsupported rather than inventing a verdict.
Does not catch reasoning errors
ClaimGuard verifies factual assertions — specific, checkable statements. It doesn't evaluate whether the agent's reasoning process was sound, whether its recommendations are correct, or whether its interpretation of a situation is good judgment.
Does not replace source quality
If your knowledge base contains outdated or incorrect information, ClaimGuard will match against that. Garbage-in, garbage-out. The unverified-claims log in your audit trail helps you identify which sources need to be updated when verified claims turn out to be wrong.
Does not add latency on the request path
ClaimGuard runs asynchronously on the response side, not in the hot path of the user's request. Verification happens after the response is delivered, so no ClaimGuard mode adds user-visible latency.
All four guards. One gateway. Your keys.
CleverGuard on every call. ScopeGuard on governed agents. ClaimGuard on responses. DriftGuard on behavioral baselines. Free tier covers all four. Currently in private beta — request access.