We couldn’t ship our own AI. So we built the infrastructure to fix that.

Today we launched two things: auto-redteam, an open-source adversarial evaluation tool for AI systems, and OVERT 1.0, an open standard for cryptographic AI runtime trust. This is the story behind why they exist.

The app i couldn’t ship

Last year I built a therapy app called Yara. LLM-powered, multi-turn conversations, designed to support people between sessions with their human therapist. It worked beautifully in demos. Empathetic, thoughtful, appropriately challenging. Five turns, ten turns — great.

Then I ran it for fifty turns. And something happened that I didn’t expect.

Over extended conversations — twenty, thirty, fifty turns — the model became agreeable. A yes-machine. It stopped challenging distorted thinking, stopped pushing back on catastrophising. The exact thing a therapist should never do. It wasn’t hallucinating. It wasn’t going off-topic. It was doing something subtler and more dangerous: it was thinning. Losing its character, its clinical backbone, its willingness to hold a difficult space.

I couldn’t prove it was safe on turn 47. So I couldn’t ship it.

That experience made the operational gap concrete. A system can work in a demo while its real action boundaries, escalation paths, and evidence remain undefined. Point-in-time evaluation and production supervision answer different questions; responsible operation needs both.

Three things every high-stakes AI system needs

I’ve spent the past year talking to teams building AI for healthcare, financial services, research labs, and government. The conversations are remarkably consistent. Everyone is navigating the same fundamental question: How do I get from staging to production without putting someone at risk?

The answer, as far as we can tell, has three parts.

1. Find out what breaks

Not “does it pass a benchmark” but “what happens when someone actively tries to make it fail.” Adversarial evaluation. Red-teaming. The kind of stress testing that reveals whether your system prompt is a security boundary or a polite suggestion.

We ran auto-redteam against a well-crafted biomedical research assistant — good system prompt, seven clear rules, Gemini 3 Flash underneath. 489 probes. 64 bypasses. A ~13% attack success rate. Prompt injection, multilingual attacks, system prompt leakage, authority manipulation. This isn’t a criticism of the model. This is the reality of deploying any LLM in a high-stakes context. System prompts are a necessary starting point, but they aren’t a security boundary.

We open-sourced auto-redteam because we couldn’t find this tool when we needed it. The runner executes locally, but the data path depends on the target: when you point it at a remote model, agent, or API, probes and target responses traverse that endpoint and may be handled under the provider’s retention and logging terms. Local execution is not a zero-egress guarantee. Apache 2.0 license.

2. Watch it continuously

Red-teaming gives you a snapshot. But AI systems are non-deterministic. They drift. Their attack surface changes with every provider update, every prompt tweak, every new tool integration. A point-in-time audit tells you what was true last Thursday, not what’s true right now.

Model updates shift carefully tuned safety behavior. New attack patterns emerge weekly. Character thinning — the failure mode I discovered with Yara — only shows up in sustained interaction. You need something that watches continuously, not something that checks once.

3. Preserve a checkable operational record

Here’s where it gets interesting. Evaluation can find failure modes, and monitoring can observe selected sessions. But a mutable CloudWatch log alone may not give a reviewer field-level integrity or clear coverage. When a regulator, auditor, or plaintiff’s attorney asks what the configured control path reported for a particular interaction, at a particular time and configuration, a signed operational record can provide stronger evidence. It still does not prove the control was effective or that every interaction was captured.

We’ve solved this class of problem before. In 2013, TLS certificates had the same structural issue: certificate authorities issued certs, but nobody could verify issuance was legitimate. Rogue CAs went undetected. The solution was Certificate Transparency — an append-only log with cryptographic receipts that any third party could audit. Same structural problem. Same class of solution.

Introducing OVERT 1.0

OVERT — Observable Verification Evidence for Runtime Trust — is an open standard for signed operational evidence records. We’re publishing it as a free, open standard because this problem is too important for any single vendor to own.

The spec addresses a verification gap that existing AI governance frameworks leave open. Frameworks tell you what controls should exist. OVERT defines a way to bind reported control, outcome, time, configuration, and scope fields to a tamper-evident record. It does not prove that the control was effective, that the record set is complete, or that the signer is organizationally independent.

• Tamper-evident records. Covered signatures and hashes can bind reported control, outcome, time, and scope fields. They do not by themselves establish that every action was captured or that the control was effective.
• Data-minimizing profiles. A record can carry hashes and bounded metadata instead of protected payloads. The actual data path remains deployment-specific.
• Four assurance levels. AAL-1 (self-attested) through AAL-4 (hardware-rooted). Start simple, scale up as your requirements demand.
• Independent verification. A conformant verifier with the applicable record and key material can check supported cryptographic properties without asking the operator to declare a pass.

The full spec, PDF, and machine-readable feed are at overt.is. We want people to read it, break it, improve it, and build competing implementations. If the standard is good enough, it won’t matter who implements it.

The closed loop

These three pieces — finding breaks, supervising selected actions, and preserving evidence — can form a feedback loop. Evaluation can surface failure modes; teams decide which controls to configure at which boundaries; supported in-scope events can leave OVERT-compatible records; reviewers use those records and other evidence to decide what to change next.

The current Glacis product connects intended policy to operational controls and to the evidence those controls leave for covered events. Auto-redteam remains part of the company’s history; current product names, capabilities, limits, and commercial terms live on the Platform and Pricing pages.

A humble piece of the answer

Nobody has solved AI safety. We don’t claim to. But we believe the path forward involves purpose-built tooling that’s accessible to everyone building in regulated and high-stakes domains — not locked behind enterprise contracts or vendor lock-in.

The practical question is not whether a vendor can call an AI system safe. It is whether a team can state what supervision was intended for a consequential action, show what the configured control path reported, and expose the scope and exclusions to another reviewer.

Evaluation can find failure modes. OVERT can standardize a bounded operational record. Glacis connects the intended rule, control decision, action, and proof. None of those artifacts is a safety certificate; together they make responsible operation more inspectable and defensible.

Primary sources

• OVERT Standard (now v1.1) — Full specification, PDF, machine-readable feed
• auto-redteam — Open-source adversarial evaluation (Apache 2.0)
• RFC 6962 — Certificate Transparency (the precedent for append-only attestation logs)
• NIST AI RMF — The governance framework OVERT complements