Test before shipping: binding pre-deployment security gates for all code, AI-generated or not

Recent reporting (404 Media, October 29, 2026) documents CEO Andy Yen's directive to "stop lovingly handcrafting all our code and use AI more," his "******** and loser thinking" reply to engineers who asked for a few days of pentesting before shipping, and the drive to "ruthlessly smash everything that stands in the way of AI velocity." As a paying customer who runs security-critical work on Proton — and who bears responsibility for colleagues and clients I brought onto the platform — I ask for one specific change: binding, published pre-deployment security gates in Proton's security-critical products.

Security is the product. End-to-end encryption, independent audits, open-source clients, transparency reports — all of this only means something if the code path behind it is tested. A vulnerability in Pass, Authenticator, or the Mail web client is not an inconvenience; it is exposure of passwords, 2FA seeds, and correspondence — the most sensitive data a person or organization has. Shipping untested code inverts the product's core promise.

The engineering evidence on AI-generated code is settled. Germany's BSI warns that AI coding assistants used without careful oversight by experienced developers introduce major security vulnerabilities or incorrect solutions about half the time, that over-reliance erodes the skill to review code at all, and that such assistants open novel attack vectors and data-exfiltration channels toward model providers. Deloitte's position matches industry practice: AI output requires automated testing, static analysis, and human review before use. The dangerous failure mode in cryptographic and authentication code is precisely the flaw that looks plausible — edge cases in key handling, session validation, or decryption logic that pass casual review. The reported CTO-authored "AI manifesto" may set direction, but manifestos don't enforce merge rules — CI does.

What a binding gate means, concretely:
1) A published security policy: no code, AI-generated or human-written, reaches production in security-critical components (crypto, key management, authentication, decryption logic) without security review.
2) SAST/DAST, dependency and secret scanning enforced in CI — as release blockers, not dashboards.
3) Human security review by security engineers for security-critical changes; AI may assist red-teaming but must not replace human testing.
4) Scheduled *********** tests before major releases in Mail, Drive, Pass, Authenticator, VPN, and Wallet, with public summaries in the style of Proton's existing audit reports.
5) Release-blocking authority for the security team, exercised without retaliation; no performance metric may reward shipping around the gates.

Velocity and security are not opposites. "Fast and secure" is achieved by putting gates into the pipeline, not by skipping them — that is exactly what CI is for. As a customer, I will judge Proton by the policy it publishes and the metrics it shows, not by reassurances.