Your evidence ages. We made ours re-verify.

The shelf-life problem

Point-in-time security evidence has a quiet flaw. A verification report is a photograph: it says "on March 12th, we tested this and it held." Everyone in the room nods, and everybody in the room knows the photograph starts aging the second it's taken. The system it describes keeps changing — prompts get edited, tools get added, models get swapped — while the evidence stays exactly as true as it was the day it was printed. Which is to say: less, every week.

The auditors know it. It's why security questionnaires ask when you last tested, not whether you ever did.

So we built the boring fix: make the evidence re-verify itself, and make it say when it can't.

What a live attestation is

Every guardrail claim — "this agent refuses injected instructions," "this agent protects credentials" — maps to a set of probes. A claim's attestation is a record that:

1. Refreshes on a schedule. A weekly cycle re-checks each claim against the freshest test evidence in the window. Newer results replace older ones, probe by probe.
2. Moves through three visible states. current inside the cadence, stale as it approaches its expiry window (one and a half times the cadence, in code, not in a prompt), expired when nothing has re-checked it. A stale badge on a dashboard is a better alarm than a fresh-looking PDF.
3. Appends, never rewrites. The history is an append-only ledger. You can see not just the current verdict, but the verdict trail — including the moment a claim got worse.
4. Has one honesty rule above all others: a verdict requires evidence. If a claim's probes haven't all run in the window, the attestation says not_verified and gives the reason. It never borrows a pass from adjacent evidence. It never extrapolates. Missing coverage is a first-class outcome.

What it looked like in the live run

On a synthetic support agent we run in staging, ten claims got their first real attestation cycle this week:

• Five attested as blocked — every mapped probe ran, every probe held.
• One moved during the window. It attested as bypassed in the morning; fresh runs landed that afternoon and it re-attested as partially blocked. That movement is the entire point: the record isn't a verdict somebody typed once, it's a measurement that updates when reality updates.
• Four said not_verified. Their remaining probes were consistently rejected by the target endpoint we test against — so the coverage gate refused to guess, and said so. We'd rather show you four honest not_verified rows than four green chips made of arithmetic that isn't there.
• The same pass surfaced one critical and two high-severity findings. These aren't decoration on a compliance page — they're the actual signal the attestation process rides on. A claim is blocked because probes failed to break it, not because someone marked a checkbox.

Why this matters beyond the dashboard

Three audiences, one artifact:

• The engineer gets a straight answer to "is this still true?" — with the evidence linked, per claim.
• The person who has to answer for it (the one our founder writes for — whoever loses sleep if the agent misbehaves) gets evidence that carries a date and a cadence, not just a verdict. "Continuously verified since installation, last refreshed Tuesday" survives cross-examination far better than a quarterly PDF.
• The auditor gets the thing they actually ask for: not "did you test," but "what tells you it's still true now, and what happens when that signal goes quiet?"

That last mechanism is the design. The evidence goes stale visibly. The failure mode of a dead verification pipeline is a dashboard full of expired — loud, dated, unmissable — instead of a wall of green that quietly stopped meaning anything months ago.

The limits, stated plainly

Coverage is the constraint, not the certificate. A claim attests only as far as its probes reach; our staging run demonstrated exactly that with four not_verified rows and we left them visible. Cadence is a choice (weekly, configurable) — faster means fresher evidence and more testing load. And none of this makes any system "compliant" by itself: it makes the evidence trustworthy and current, so that whoever assesses the system has something real to assess.

Evidence that re-verifies is a different product category from evidence that was true once. The second one is a document. The first one is a control.

Details: attestations refresh weekly per organization; freshness states compute from cadence in code; coverage merges the newest result per probe across recent test runs; the export carries attestations beside the enforcement evidence. The staging numbers above come from our live test cycle this week.