Thank you, anon, for your recommendation to "test before shipping: binding pre-deployment security gates for all code, AI-generated or not" in your comment to https://protonmail.uservoice.com/forums/945460-general-ideas/suggestions/51876873-proton-needs-employee-representatives. "Release-blocking authority for the security team, exercised without retaliation" could be supervised by a works council in order to protect employees. Retaliations should be registered and analyzed as OHS incidents, as they are hazardous to mental health, see also https://protonmail.uservoice.com/forums/945460-general-ideas/suggestions/51874746-iso-45001-certification-for-ohs-occupational-heal

yes make it oss

Yes

Unionize & OSS QA and testing, Human review.
3rd party testing.
Bug bounties

Unionize & OSS QA and testing, Human review.
3rd party testing.
Bug bounties

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.

We don't need you to "move faster." We need you to keep minting silver, keep doing what you were doing before.

It's not unreasonable to use AI as an additional adversary, but it is not a reasonable replacement for any portion of industry standard human pentesting or development time. If you want to hire more people to build out that workflow, cool, go for it, whatever. But do not pull a Microsoft and start gutting your talent.

We don't need you to add enshittified slop features. Move carefully and remember what the core of your product is. It's a credence product. And the idea that someone is "lovingly handcrafting code" to preserve our privacy and security is much more comforting that the thought of some child with a god-complex thinking he's amazing because he just discovered opencode.

If you don't want to lose our support, then lose your leadership, or at *least* please lose the ****** attitude.

I'd like to see Proton unionize. Adversarial growth can very efficient, and preserves trust too.