Proton AI Coding Mandate: Is Zero-Access Encryption at Risk?

In late August 2026, an engineer in Proton’s internal security Slack channel suggested something routine: newly written code should get a few days of penetration testing before it ships to production. At most consumer software companies, an argument over release timing is a minor tug of war between product and QA. Proton is different. The Geneva company built its reputation on end-to-end encryption that keeps user data mathematically out of reach, even for its own administrators. For a company like that, adversarial review before deployment is basic hygiene.

CEO Andy Yen did not answer with a technical objection or a compromise on scheduling. “That’s bullshit and loser thinking,” he wrote. “Of course it’s possible to be fast and secure. Stop thinking always of how to be slower, and focus more on how to be faster.” A little later he added: “Only losers think like that.” When employees raised similar concerns about AI-generated output, his advice was to “prompt better” and to “stop lovingly handcrafting all our code and use AI more.”

Journalist Joseph Cox of 404 Media surfaced the exchange in late October 2026. His investigation drew on leaked internal chats, meeting audio, and interviews with eight current Proton staffers and one former one. It shows a deep split inside one of the best-known privacy companies in the world. Outwardly, Proton sells “Privacy by default,” sits under Swiss privacy law and the non-profit Proton Foundation, and regularly criticizes the surveillance-driven haste of Silicon Valley. Inside, leadership was reorganizing the company around large language models.

CTO Bart Butler circulated a document titled AI @ Proton, Engineering Manifesto. It told developers their “old job is gone” and described hand-written code as “a core skill whose time has passed, like memorizing phone numbers.” Leadership also set up an internal email address where staff could report anything blocking “AI velocity,” so executives could “ruthlessly smash” the bottleneck. By October 2026, Butler was telling an all-hands meeting that about 90 percent of the month’s new code had been written by AI, mostly Anthropic’s Claude, and that “most human code review will end.”

I want to look past the boardroom drama here, because the real risk sits in the software stack. Cryptographic engineering does not behave like ordinary web development. In a typical CRUD app, a subtle bug shows up as a broken button or a failed query, and an integration test catches it. In a zero-access, end-to-end encrypted system, code can pass every unit test and render perfectly in the browser while still carrying a fatal flaw: a timing side channel, a non-canonical packet parse, an unzeroed memory buffer, or a key-misbinding bug. Any of these can quietly remove the guarantees protecting a journalist’s inbox or a dissident’s password vault. Push for generative speed against that kind of code and the margin for error does not shrink gradually. It disappears.

What the leaked Proton Slack messages and manifesto reveal

The 404 Media reporting describes three things worth separating. First, there was a technical dispute: staff asked for pentesting time and AI-output caution, and the CEO rejected both in blunt terms. Second, there was a structural change: the engineering manifesto, the “AI velocity” bottleneck inbox, and Butler’s forecast that human code review would fade. Third, there was pressure on people. Engineers were told 2026 would be “the last year that we hire engineers,” and compulsory “re-interviews” were scheduled for November 4 through 11, 2026.

The reason behind the push is also in the leaked material. In internal presentations, leadership told staff the company was not on track for its annual recurring revenue target “due to insufficient velocity,” and concluded that “by all metrics that matter, we’re an underperforming company.” I come back to the economics below. First, it helps to see what is actually at stake in the code.

How Proton’s zero-access encryption works

Proton’s core security claim is architectural, not a matter of policy. Even if its production servers in Switzerland and Germany were compromised or subpoenaed, the operator could not read emails, calendar entries, files, or vault items, because the servers hold only ciphertext and never see plaintext credentials or private decryption keys. Delivering that across browsers, mobile apps, and desktop bridges means chaining several cryptographic primitives together, and each one depends on implementation details that are easy to get wrong.

SRP-6a authentication and the checks that cannot be skipped

Consider login. A standard web service sends your password over TLS to a backend, which hashes it and compares it with a database entry. If Proton worked that way, a malicious insider or a state actor who compromised the TLS termination layer could capture the plaintext password and use it to derive the key that unlocks your private OpenPGP keyring. To keep the password off the wire entirely, Proton uses a hardened variant of the Secure Remote Password protocol (SRP-6a, specified across RFC 2945 and RFC 5054).

In Proton’s flow, the client salts the password and hashes it with bcrypt (plus Argon2 for local offline unlocking in clients such as Proton Pass) to produce a secret exponent.

The server stores only a verifier:

Here, N is a large safe prime:

where q is also prime, and g is a generator of the multiplicative group:

At login, the client picks an ephemeral secret a and sends:

The server picks its own ephemeral secret b and replies with:

The multiplier k is calculated as:

Both sides compute the scrambling parameter u:

The client computes the shared session secret S:

The server computes the same shared session secret S:

Both expressions reduce to:

Therefore, both sides arrive at the same session key:

They then exchange mutual proofs, M1 and M2, to verify that both parties have derived the same session secret. Neither the password nor the secret exponent x ever leaves the client’s memory.

Now picture an automated coding agent refactoring the authentication or session glue around that implementation. Several boundary checks have to survive, and none of them is obvious:

1. The client must verify that the server’s value satisfies , and the server must verify that . If an attacker injects or a multiple of N, the shared secret S collapses to 0, regardless of the password exponent. An active man-in-the-middle or a compromised server could then bypass authentication.
2. The modular exponentiation and the final comparison of the proof M1 must run in constant time. If a byte-by-byte comparison stops at the first mismatch, high-resolution timing measurements can leak information about internal state.
3. The modulus N and generator g that the server returns during the /auth/info handshake must be pinned or checked against known safe primes. Otherwise, a compromised backend could supply a composite modulus with small prime factors and run a Pohlig-Hellman discrete logarithm attack to recover x from the client’s response.

OpenPGP key handling on the client

After SRP succeeds, the client fetches the user’s encrypted OpenPGP key material from endpoints such as GET /core/v4/users and GET /core/v4/addresses. Proton maintains two open-source libraries that power its own products and many third-party tools: OpenPGP.js for browsers and JavaScript, and GopenPGP (built on a customized fork of Go’s x/crypto/openpgp) for mobile apps, Proton Mail Bridge, and Proton Drive clients. On the device, a key derived from the user’s password unwraps the symmetrically encrypted OpenPGP secret key packets. Every email body, Drive file block, and Proton Pass vault entry is decrypted only in local volatile memory. Proton Pass encrypts each item under its own 32-byte random key using 256-bit AES-GCM, so even URLs and metadata stay opaque to the server.

Past regressions show how unforgiving the client side is

Proton’s own history shows how easily these boundaries slip. During an independent audit of Proton Pass in mid-2023, Cure53 researchers found that unencrypted usernames and passwords stayed in the browser extension’s process memory even after the user locked the vault. Proton patched it. A later feature release that summer accidentally undid the fix and brought the plaintext persistence back. It took an external researcher spotting the regression, plus a September 2023 cross-platform patch that Recurity Labs verified in early 2026, to close the exposure.

A second case came during the migration of GopenPGP from v2 to v3 in early 2026. Downstream integrations such as the rclone Proton Drive bridge hit parser regressions. Valid multi-address accounts with custom domains failed during keyring bootstrap with errors like openpgp: invalid data: tag byte does not have MSB set and user ID signature with wrong type.

Neither incident came from broken mathematics. Both came from state management, memory lifecycle, and parser edge cases, which are the kind of bugs that slip past automated test suites when feature speed outruns slow human review.

Post-quantum OpenPGP in Proton: where hybrid keys get fragile

Compressing security review gets more dangerous when it touches Proton’s most ambitious upgrade, post-quantum cryptography (PQC) in its OpenPGP infrastructure. The motivation is the “harvest now, decrypt later” threat model. State-level adversaries can archive encrypted traffic from backbone fiber today and decrypt it later, once a cryptographically relevant quantum computer can run Shor’s algorithm against RSA and elliptic-curve discrete logarithms. Proton worked with Germany’s Federal Office for Information Security (BSI) and the IETF OpenPGP working group on draft-ietf-openpgp-pqc.

Rolled out across Proton’s stack in 2026 alongside OpenPGP v6 keys (RFC 9580), the design swaps single-primitive public-key operations for hybrid PQ/T (post-quantum plus traditional) composite schemes. For key encapsulation, Proton pairs X25519 (ECDH over Curve25519) with ML-KEM-768, the NIST module-lattice scheme formerly known as CRYSTALS-Kyber (FIPS 203). For signatures, it pairs Ed25519 or ECDSA with ML-DSA, formerly CRYSTALS-Dilithium (FIPS 204).

The ML-KEM-768 and X25519 key combiner

A hybrid KEM stays confidential as long as at least one of its two underlying problems stays hard: elliptic-curve Diffie-Hellman on Curve25519, or Module Learning With Errors over the polynomial ring with .

Packing two KEMs into one OpenPGP v6 PKESK packet adds strict binding requirements. When encrypting a session key to a recipient’s composite public key, the implementation has to:

1. Parse the single composite algorithm identifier and extract the 32-byte ecdhPublicKey and the 1,184-byte mlkemPublicKey from the v6 key-material packet, with no trailing bytes and no ambiguous length encodings.
2. Run the ephemeral X25519 scalar multiplication to get the classical shared secret and ciphertext , and check that the result is not the all-zero output produced by low-order curve points.
3. Run ML-KEM.Encaps to get the lattice shared secret and the 1,088-byte ciphertext .
4. Feed both shared secrets, both ciphertexts, both public key components, and a fixed domain-separation label into one key combiner built on SHA3-256 or HKDF:

5. Wrap the symmetric message session key with AES-256 Key Wrap under .

The combiner hashes the ciphertexts and public keys along with the shared secrets for a reason. Without and in the KDF transcript, the hybrid construction is exposed to key-misbinding and downgrade attacks, unless both underlying KEMs independently meet strict IND-CCA2 security against rogue public-key registration.

Constant-time decapsulation and the KyberSlash lesson

Inside ML-KEM.Decaps, the Fujisaki-Okamoto re-encryption check has to run in strict constant time. The recipient decodes a noisy polynomial vector, re-encrypts the recovered message with a deterministically derived seed, and compares the result: with the received ciphertext: .

If they differ, the routine must implicitly reject by returning a pseudorandom key derived from a secret seed z and the ciphertext. It must never throw an early parsing error or branch on the comparison result.

In early 2024, researchers showed the KyberSlash class of bugs across several reference implementations of CRYSTALS-Kyber. Compilers turned the division operator used in polynomial coefficient compression into instructions whose cycle count depends on the dividend, and that timing variation leaked secret key coefficients.

An LLM trained on billions of lines of general-purpose Go, TypeScript, and C++ has no physical intuition for why a / b is a serious vulnerability inside a lattice polynomial reducer. It has no instinct for why returning err != nil on a malformed ML-KEM ciphertext breaks IND-CCA2 security and hands an attacker a chosen-ciphertext key-recovery oracle.

The rollout also came with an operational limit. Post-quantum protection applies only to newly sent messages and newly generated keys. Years of archived email stay under legacy classical keys unless the user re-encrypts them manually. When users on Reddit pointed this out, Yen did not treat it as a fair discussion of key-rotation trade-offs. According to Slack messages obtained by 404 Media, he went into an internal channel created to thank the engineers behind the PQC work and wrote: “Get it fixed. Now Reddit is pissed and we look worse than Tuta.”

Can “unaligned” AI models safely review security-critical code?

Facing criticism over dismissing human pentesting, Yen defended the new workflow on Reddit as u/andy1011000. The comment collected more than 1,200 downvotes. He argued that pausing deployments for “several extra days of human review is not the correct way to confront this challenge,” and said Proton performs more verification than ever because “for some time now, Proton has also been using unaligned models with custom skills to do a thorough review of our code.”

Security engineers who build automated vulnerability-discovery pipelines will recognize that phrase. My reading is that it describes a familiar pattern, though Proton has not published details of its setup. Commercial frontier models go through safety alignment (RLHF or Constitutional AI) meant to make them refuse requests for exploit payloads, reverse-engineering help, or zero-day synthesis. That prevents casual misuse, but it can also hurt legitimate defensive auditing. An over-aligned model may refuse to build a proof-of-concept exploit string, or may invent a harmless explanation for a dangerous memory operation. To get around that, offensive security teams use refusal ablation, either by fine-tuning on offensive corpora or by projecting the “refusal direction” out of the model’s residual stream activations. They then pair the uncensored model with “custom skills” through Model Context Protocol (MCP) servers or agent harnesses such as AGENTS.md files, repository context indexes, semgrep rules, syzkaller or libFuzzer hooks, and AST parsers.

Agentic static analysis has real value. An LLM with repository-wide context can trace taint flows across microservices, spot missing authentication middleware on a new REST route, and write fuzzing harnesses faster than a person typing boilerplate. The problem is using an unaligned model to review code that another model wrote 90 percent of. That creates a correlated failure mode, and empirical security research has warned about it repeatedly.

The research on LLM-generated cryptographic and low-level code, including hardware description languages such as Verilog and RTL, keeps finding a gap between functional correctness and side-channel resilience. Models often produce implementations that pass NIST Known Answer Tests while adding secret-dependent branches such as if ((secret_scalar >> i) & 1), secret-dependent array lookups that leak cache-line offsets under Prime+Probe attacks, or memset calls that the compiler removes through dead-store elimination, leaving key buffers unzeroed before the heap is freed.

Work on refusal-ablated and fine-tuned models for vulnerability localization (CWE classification and line-level bug attribution) shows calibration limits too. Removing refusal guardrails makes a model more willing to propose offensive hypotheses, but it does not widen its reasoning over global state invariants. Outside local syntactic anti-patterns like SQL injection, basic buffer overflows, and hardcoded API keys, LLM auditors tend to produce many false positives, which tire out human maintainers, and they systematically miss flaws that span several architectural boundaries.

Take a pull request in GopenPGP or go-proton-api. The model reviewing it analyzes token sequences conditioned on nearby repository files. Its weights hold no formal model of the adversary. Suppose a change alters how a client caches an address key after GET /core/v4/addresses. Nothing in that diff announces that a compromised Proton API server could now mount a key-substitution attack if the client fails to verify the self-signature binding the subkey to the user’s primary fingerprint before encrypting a draft. Catching that requires a human engineer to step back and ask: if an intelligence agency controlled our backend tomorrow morning, what malicious JSON payload could trick this client into encrypting plaintext to a key the attacker owns? Swapping days of that adversarial threat modeling for an automated LLM pass confuses fast pattern matching with cryptographic assurance.

The productivity paradox behind Proton’s “velocity” push

Why would a company whose brand rests on cryptographic trust gamble on unverified speed? The leaked material points to financial pressure. Proton has grown from a standalone encrypted webmail provider into a wide suite: Proton Mail, VPN, Pass, Drive, Calendar, Wallet, the Docs collaboration tool, and its own AI assistant, Lumo. That puts it in direct feature competition with Google Workspace and Microsoft 365, from a base of hundreds of staff in Geneva.

Unable or unwilling to match the headcount of trillion-dollar advertising giants, Yen and Butler bet the roadmap on generative leverage. Yen told staff that 2026 would be the last year Proton hires engineers. From 2027, it would hire only “what we used to call product managers, to build things with AI.” Butler’s manifesto put it this way: “Every engineer is now a team leader, a manager, and your direct reports are the models and agents you use.” When an agent fails, he argued, the engineer should not just write the code by hand. They should work out why the agent failed and update repository-level context files such as AGENTS.md and shared prompt libraries so it succeeds next time.

Part of that philosophy is sensible. Treating an agent failure as a sign that a repository lacks clear interfaces, fast deterministic tests, or written conventions is good software stewardship. The trouble starts when leadership confuses the volume of generated code with actual delivery.

What the METR study found about AI coding speed

Early vendor-sponsored benchmarks claimed 55 percent task speedups and 60 percent more merged pull requests, mostly on junior or greenfield work. Independent studies of experienced engineers on mature codebases tell a different story. METR (Model Evaluation and Threat Research) ran a randomized controlled trial with experienced open-source developers working on repositories they already knew well. Before the trial, they predicted AI tools would make them 24 percent faster. Afterward, they still believed they had worked about 20 percent faster. The stopwatch showed they were 19 percent slower with AI, a 39-percentage-point gap between perception and result.

The slowdown comes from the cost of verification. Autocomplete streams tokens instantly, and that feels like fast progress. In practice the engineer swaps active writing time for passive debugging: reading plausible diffs, re-prompting when an agent invents an internal API parameter, tracking down regressions they did not author, and switching between architectural intent and machine babysitting.

DORA metrics and the cost of flooding code review

The organizational numbers are worse. Industry telemetry from enterprise teams in 2026 reportedly showed median pull-request review wait times rising by up to 441 percent as AI-generated code flooded repositories. Bug rates per developer rose 54 percent, and production incidents per pull request rose more than 240 percent. (I have not independently verified these figures, so check the original sources before citing them.)

Against that background, consider a CTO who reports that AI wrote 90 percent of the code in a single month and then proposes ending human review because review has become the bottleneck. That does not fix a quality problem. It switches off the smoke detectors because the kitchen is filling with smoke.

Why psychological safety is a cryptographic dependency

The most damaging part of the campaign, to my mind, was not the use of Claude or the AGENTS.md files. It was the erosion of psychological safety among the engineers who protect the platform. In high-assurance engineering, whether flight control, medical device firmware, or zero-access cryptography, human dissent is the main circuit breaker. No static analyzer or formal verification suite covers a whole production system. Security ultimately depends on an experienced engineer noticing an odd edge case on a Thursday afternoon and feeling free to pull the Andon cord without fear of retaliation.

Inside Proton in autumn 2026, that incentive structure was reversed. When a senior staffer asked whether the sudden push to replace engineering headcount with AI agents was driven by financial trouble, Yen replied that if the employee did not trust his word, Proton “might not be the place for you.” Employees also said monitoring software on company machines tracked how much AI-generated code each developer produced. Proton later called that a “misunderstanding about how MDM [Mobile Device Management] software works,” though staff stayed unconvinced.

The pressure peaked with the mandatory “re-interviews” for engineers, scheduled between November 4 and November 11, 2026. Interviewers from outside each employee’s reporting line would spend 30 minutes probing personal adoption of AI tooling and alignment with the velocity doctrine. The announcement warned that outcomes would be “consequential” and could lead to “changes in roles, responsibilities and continued employment.”

Picture a developer on November 1 reviewing a diff in GopenPGP or the Proton Mail web client. An AI agent has produced a 1,500-line refactor of the IndexedDB key-caching layer or the WebCrypto wrapper. Tests pass and the build is green. But the engineer spots a subtle race condition in how decrypted session keys are cleared when a user switches accounts. Confirming or ruling it out will take two days of manual tracing and adversarial testing.

In a healthy security culture, the engineer blocks the merge and spends the two days. In a company where the CEO has called pentesting requests “bullshit and loser thinking,” where a tip line exists to “ruthlessly smash” anything that slows AI velocity, and where an out-of-department panel will soon decide who keeps their job based on AI throughput, the rational move is to click Approve and look away.

Once a culture punishes the instinct to verify, the sophistication of its primitives stops protecting users. You can have 4,096-bit RSA, Curve25519, and ML-KEM-768, wrapped in zero-knowledge SRP-6a authentication and hosted in a bunker under the Swiss Alps. One unreviewed, AI-hallucinated line of JavaScript that logs decrypted DOM state to an analytics endpoint, or mishandles a CORS origin header, makes all of that mathematics irrelevant.

Proton’s walkback and the contradiction that remains

Within 48 hours of 404 Media publishing the leaked Slack logs and manifesto, backlash from paying subscribers and the wider infosec community forced a retreat. At an emergency all-hands, Butler apologized bluntly: “We fucked up, we know we fucked up.” He told staff that “using AI effectively and pragmatically does not mean that we’ve given up on security, or good architecture, or sound software engineering principles.” Proton’s public statement admitted that “in our determination to move fast, we have sometimes been too blunt or too slow in explaining ourselves to our people.” It also promised to open-source its internal AI review tools and publish detailed documentation of its code-review and security-auditing methods.

Yen cancelled the November re-interviews and said nobody would lose a job over AI metrics. The way he did it explains why many employees told reporters the walkback felt like damage control. He said the interviews had, “in a, let’s say, unintentional way, already served their purpose” because the whole company was now talking about AI. Then leadership repeated that “I’m still going to push,” and said the AI adoption criteria meant for the November interviews would move into regular performance reviews. Staff also noted that because Yen controls Proton’s governance structure, no external board could check his impulses.

For the millions of individuals, journalists, and enterprise teams who rely on Proton, the episode raises a hard question. Using language models in a security company’s engineering process is possible, and probably necessary. With discipline, coding agents can speed up boilerplate, widen fuzzing coverage, help translate legacy modules into memory-safe languages like Rust, and help human auditors triage large repositories. Proton also keeps real strengths. OpenPGP.js and GopenPGP are open source, third parties such as Cure53 and Recurity Labs audit its releases periodically, and its client-side design means server-side changes cannot quietly decrypt local user vaults without a compromised client update.

That last point is where trust is won or lost. Each time a user logs into the Proton web app or lets a mobile app auto-update, they trust Proton’s internal release governance: that no regression, side-channel leak, or parser bug was rushed through to hit a quarterly velocity target. Cryptographic trust takes a decade of slow, conservative engineering to build, and it depends on admitting that people and language models both make mistakes. A leader who calls a request for adversarial scrutiny “loser thinking” is spending down the trust that makes a privacy company worth paying for.

• Did Proton really say 90 percent of its code was written by AI? According to 404 Media’s reporting, CTO Bart Butler told an all-hands meeting in October 2026 that roughly 90 percent of that month’s new code was AI-written, mostly by Claude.
• Is Proton Mail still end-to-end encrypted? Proton’s zero-access design stores only ciphertext on its servers, and its client libraries are open source. The concern in this article is about the review process behind client code, not a confirmed break in the encryption.
• What did Proton say after the backlash? Proton admitted it had been “too blunt,” cancelled the November re-interviews, and promised to open-source its internal AI review tools and publish its review methodology.