What was found
The largest instance was generated code: a command-line tool and three API routes that returned verification outcomes without computing them.
- One route returned ORGANIZATION_VERIFIED for any domain submitted to it.
- A DNS token was hard-coded, identical for every user and every domain.
- Server-side key storage silently wrote operator keys as plain hex whenever its encryption secret was unset.
- A public onboarding page had every operator sign a fixed operator name, contact, purpose, and both disclosure attestations (
discloses_to_user,human_escalation) preset to true, under their own key. - DECLARED, which sits below L1, rendered in Verified Emerald with confetti.
What replaced it
The stubs were replaced with real Ed25519 paths that report DECLARED and nothing above it. The command-line tool now generates real keys, builds manifests from explicit operator attestations, signs a ManifestProof over RFC 8785 canonical bytes, writes the private key with 0600 permissions and never prints it.
Server-side operator key generation was deleted outright rather than hardened, so the registry never holds an operator private key. The onboarding page now collects the operator's own identity and attestations instead of signing fixed ones. DECLARED renders amber, and the panel states plainly that no third party has checked the claims.
Smaller claims that were also untrue
Dead and out-of-namespace hosts were removed from public copy. Endpoints that were not deployed, the second key-discovery path and the assertion write path at the time, were labelled as not deployed in the docs, the homepage diagram and every Verification Card's instructions. A privacy escrow feature described on the site did not exist and was removed. The root package guard that prevents publishing the whole monorepo by accident was restored.
Making the standard a test
packages/web/test/public-surface.test.ts turns each of these into a build-breaking assertion. A later sweep found two more defaulted attestations, registration implemented twice, and the presentation layer deciding trust state, which led to the fail-closed presentation change. The rule it all comes down to is simple: a level, a badge or a sentence may claim only what was computed from evidence.
The same rule sets the ceiling every AgenID page states. The reference deployment at agenid.com issues nothing above L1_REGISTERED today: L2 and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet. L5 is reserved and is not issuable at all.
What it means for operators and verifiers
For operators, the lesson is to sign only what you mean: at /issue the behavioral attestations start false and must be set deliberately. For verifiers, the lesson is the protocol's own design: do not take a displayed level on faith. Resolve the envelope and re-verify it, as described in how to verify an AI agent. Which agent is acting is not the same question as what it is allowed to do. AgenID answers the first. Protocol v1.1.1 defines no signed authorization object, so permission stays with the operator and with the party on the other side.