Note

The certificate stops at the platform

ElevenLabs and Harvey are certified under AIUC-1, the standard for AI agent security audited by Schellman. ElevenLabs is the first voice AI company on the roster. Harvey is the first legal AI, and that certificate is legal-agent assurance, not a scan of coding-agent output. Both are real milestones for the category. It is also worth being precise about what a certificate covers, because the thing it covers and the thing that leaks are not the same object.

What AIUC-1 actually is

AIUC-1 is a security, safety, and reliability standard written for AI agents, developed with a consortium that includes Orrick, Stanford, MIT, Carnegie Mellon, Cisco, MongoDB, and Google Cloud, with contributors who came out of Anthropic. It grades an agent across six risk pillars, data and privacy, security, safety, reliability, accountability, and societal impact, and it operationalizes established frameworks including ISO 42001, the NIST AI Risk Management Framework, MITRE ATLAS, and the OWASP Top 10 for LLMs. Certification runs through an accredited auditor, tests the agent against more than a thousand adversarial scenarios, re-tested quarterly. It is rigorous, and it is not a marketing badge.

The detail that tells you what the certificate is scoped to is who stands behind it. AIUC-1 comes from an underwriter, and the certificate feeds an insurance model: audit the controls, then price a policy on how the system holds up. That is a judgment about the vendor and its platform, the thing an enterprise is deciding whether to trust and insure. UiPath earned it across its agent products after testing against more than two thousand enterprise risk scenarios. Same scope. The platform.

Phil Venables, former CISO of Google Cloud and a contributor to the standard, framed the goal as a SOC 2 for AI agents. Take that literally, because it is the right analogy. A SOC 2 says a vendor's controls held up when the auditor looked. It has never told you the software you run on top is free of bugs. AIUC-1 is that, aimed at agents.

And the standard is candid about its own reach. AIUC describes a certificate as a point-in-time assessment of controls, not a warranty of outcomes, and not a substitute for independent risk assessment of what you deploy. The rest of this note is really just taking that sentence seriously.

The output is a different object

Here is the distinction that matters to anyone shipping an app. A certified platform and a vulnerable generated app are not a contradiction. They are two different things.

The certificate covers the factory's controls. It does not read the specific thing that rolled off the line for you. When you describe an app and the platform writes it, the security of that app, whether the export route inherited the auth built forty prompts earlier, whether the admin panel answers on a guessable path, whether the list endpoint is scoped to the user asking, is a property of the generated code. It is written one prompt at a time, and different in every app. No platform-level certification reads your particular repo at the moment you share the link.

This is not us reaching past the standard. Its own work points the same way. The whitepaper AIUC published with Lovable catalogs seventy-five risks specific to coding agents, across thirteen categories, and names the stake in one line: a hallucinated authentication pattern in generated code is a security vulnerability that ships to production. The standard is telling you the same thing we are. The output is where the risk lands.

To its credit, the standard does not stop at naming the problem. Its extension for coding agents asks for generation that is secure by default and a scanner that reads the generated output for common vulnerability classes before it reaches you. That raises the floor, and it is real. Two things stay true anyway. A certified pipeline is tested in aggregate, against adversarial scenarios, every quarter. It is not an audit of the one repo the platform wrote for you at the moment you share it. And the failure that actually leaks is rarely a bad pattern a scanner matches. The scanner flags a hardcoded key or a query built from raw input. It does not flag an admin route that answers without a session, because nothing about that line looks wrong. The leak is a missing invariant across surfaces, the authorization that guards the page and never reaches the action behind it, code that looks correct line by line and only fails as a whole.

That failure has a name: a protection that exists but does not propagate, the guard on the page that never reaches the action behind it. A rigorous audit of the producer does not remove it from the produced.

Compliant is not secure, and that is not a new lesson

We ran a version of this experiment more than a decade ago, at a different layer. In September 2013, Target was certified PCI DSS compliant. Weeks later it was breached, and forty million cards went with it. Compliant is not secure: a certification is a snapshot of controls at a point in time, not a standing guarantee about the system in the wild.

Be fair about the analogy. Target's breach came through a vendor's stolen credentials, an operations failure, not a line of generated code. The surface is different. The principle is what carries: a certificate of the controls is not the security of the specific system, and everyone who read "PCI compliant" as "safe" learned the difference the expensive way.

The version that matches our exact layer is already on the record. In March 2026 an Italian streamer launched a social network built with AI for about forty euros. Within hours someone typed the admin path and reached an administration panel with no authentication at all, and behind it the personal data of thousands of users. A researcher later catalogued nine critical issues. The tooling was capable of shipping a working app, and it did. What it shipped was an open door. That is the output layer, and no certificate of the platform reads it for you.

Why the gap is easy to miss

The risk here is not the certificate. It is what a builder reads into it. "The platform is certified" is true and reassuring, and it is one short step to "so the app I built with it is secure", which does not follow. A certificate of the tool says nothing about whether this particular session left a route unguarded, in code that looks finished and demos clean.

What we do not claim

We are not saying AIUC-1 is weak, or that certification is theater, or that Lovable's output is insecure. Naming Target is not a knock on PCI, and naming a forty-euro app is not a knock on any standard. Every one of these standards raises the floor, and platform-level assurance is genuinely valuable. More products should pursue it. We hold no claim about any specific app, and we would not publish one. The narrower point is the load-bearing one: a floor is not a ceiling, certification of the tool and security of the output are different layers, and only one of them is read at your ship moment.

A platform certificate answers whether the vendor is trustworthy. It does not answer whether the app you are about to share is guarded. That second question is a different one, asked of the specific code in front of you, and it does not stop being yours the day the platform gets certified.

Connor · Seatbelt · July 24