Insurance
A claim decision an agent influenced has to be reconstructable years later, by somebody who was not there.
This is already on your desk.
- 01
The tail is measured in years, not in log-retention windows
A claim reopened in 2031 has to be explained by a record made in 2026. That is an argument for deciding retention deliberately: the default keeps everything, which over-satisfies an evidence obligation and satisfies nothing in storage limitation. - 02
The oversight has to be real, and it has to look real
An approval queue nobody reads is worse than no gate at all, and a record of thousands of instant confirmations invites the obvious conclusion. Risk-tiered gates exist so approvals stay rare enough to be read. - 03
Claims prompts carry special-category data by default
Health information, criminal-conviction history and financial hardship arrive as free text inside a description of what happened, and free text is what regex and checksum detection cannot find.
- 01
Our agents only propose and a human always decides. Why add a control?
Because the proposal is part of the decision, and it is the part nobody currently records. What a human saw at the moment they approved (the tool, the policy that stopped it, the trace it belonged to) is the evidence that separates oversight from rubber-stamping when the file is reopened years later. Approvals are bound to one exact payload, single-use and expiring, with the approver's identity, time and rationale recorded.
- 02
Can we keep the evidence for the life of the claim?
Yes, and the decision is yours rather than the product's. Cloud activity retention is configured to 30 days. Customer-hosted trace retention is unset by default and unset means keep forever, which suits a long tail and fails storage limitation, so a regulated deployment sets a window that reconciles both. The hash-chained governance log is never touched by retention, so the record of a deletion outlives the deleted data. There is no vendor-side copy, so back the database up like evidence.
- 03
Will it tell us whether the model's decision was fair?
No. The mapping marks misinformation as partial (traces make outputs reviewable and there is a hook for evaluation scores) and improper output handling as partial, because response redaction cannot control what your downstream system does with the text. Evaluator governance is a later roadmap proposal. Buy this for authority and effect evidence, and keep your fairness testing where it is.
Cloud custody and optional customer-hosted controls are described separately. The 24 limits we publish, and the 9 risks a named person has to accept in writing, are on one page.
What we do not claimWhat a claims interaction leaves behind is bounded on purpose.
A governed request produces a trace holding metadata only (agent, session, delegated principal, team, status, token counts, cost, the personal-data kinds detected and tool names) and trace events holding the routing and policy decisions. Message text is not among them unless conversation capture has been switched from its metadata default to redacted, in which case prompt, reply and tool traffic are kept mask-redacted and bounded.
Model response text follows the same rule: at the metadata default the response event records the stop reason, token counts and content-block types rather than the generated text. Hidden model reasoning is recorded nowhere, because no provider exposes it. What is captured is read off the payload after redaction, which is also the limitation, because what redaction missed is what the record retains.
- What an approver sees
- The tool name and the policy's own reason for requiring a human, mask-redacted and capped at 240 characters, with the approver's identity, time and typed rationale. None of the model's proposed arguments.
- Approvals sit outside the trace window
- Not purged by trace retention and not erasable by subject, so they need their own place in your retention schedule.
- Shadow mode before enforcement
- Every policy runs in shadow first, so the first week produces findings rather than blocked claims, and a backtest replays a candidate rule against retained traces.
Every check lives in one function, so you can read your rules and know what they do.
POST /v1/chat/completions
The key resolves to one registered agent with a named owner, and the trace is opened before anything can refuse the request.
Kill switches, then lifecycle, then deny-by-default permissions across every delegation hop, then rate limits, then your policies by priority.
returns: allow · block · require_approval — plus a redaction plan
A spend ceiling is the deliberate exception: it is deferred until routing has fixed which provider and model will serve the call, so it is tested against the price you will pay.
Routed to the provider you configured, on your key. Metering runs last and the trace closes with a terminal status.
The plan is applied to the outbound payload and a redaction event records kinds and counts, never values. A redaction that cannot be applied faithfully becomes a refusal instead.
An approval bound to a hash of this exact payload, single-use and expiring. The caller receives the approval id and the header to resume with.
429 ACP_BUDGET_EXCEEDED or ACP_RATE_LIMITED where a ceiling decided it. The trace closes as blocked and is kept as thoroughly as one that went through.
Verdict names and status codes are the product’s own. Every rule can run in shadow mode first, where the decision is recorded and the request is not changed. That is how you learn your false-positive rate before you refuse real work.
The control is real at the identifier layer and absent at the narrative layer.
Detection before egress is regex plus checksum, and the confidence per kind is published rather than averaged into a reassuring number. NHS numbers are validated mod-11 and cards by Luhn, scoring 0.9 to 0.98; national insurance numbers score 0.85. A health condition described in a sentence scores nothing at all, because free-text personal data is not detected. It is a compensating control, not your data-loss prevention.
Two routing controls are worth setting on a claims agent on day one: require no training on payloads, and require a serving region. Both are enforced on the fallback chain as well as the primary route, and a request with no qualifying route is refused rather than downgraded quietly. Those flags are your assertions about your contracts, unverified by the product.
This is what does the work.
Human approvals
One human decision, bound to one exact payload, spendable once.
Flight recorder
Every governed request in a timeline a compliance officer can read, and a search box that never writes SQL.
Policy engine
One deterministic verdict on every governed request: allow, block, redact, or park it for a human.
Questions
Which agent use cases in insurance does this help with?
Any where an agent's output influences a decision somebody may later challenge, and particularly where the agent acts rather than drafts: setting a reserve, issuing a payment, transitioning a claim status. For those, the effect contract verifies a postcondition rather than trusting a success response. For drafting workflows the value is narrower: a bounded, hash-chained record of what was asked and who approved it.
How do we evidence human oversight to a complaints reviewer?
With the approval record and the trace it belongs to, read together. The approval carries the approver's identity, decision time and typed rationale; the trace carries the policy decisions that led to the pause and, where conversation capture was switched on before the request ran, the bounded, mask-redacted prompt and reply beside them. Both sit inside a compliance export carrying the audit-chain verdict. The model's hidden reasoning is in neither.
Is there a signed artefact we can rely on?
Two, and it matters which you are holding. Ed25519 audit anchors sign a statement of the chain head and are published off-box; effect receipts sign a terminal outcome and verify offline against a public key you obtain independently. The compliance and trace exports are not signed: they are SHA-256 digest-sealed, which catches edits and does not prove origin.
Bring the objection that is not on this page.
Create a cloud account and workspace. No card or server installation. Model calls and Google BigQuery scans can incur separate provider charges.