Proton, AI code and testing: trust also depends on internal decisions

Proton, AI code and testing: trust also depends on internal decisions

An engineer asks for a few days to check new code for security issues. Management wants to move faster with AI. That disagreement could lead to a practical decision: which risks need testing, what evidence is required and when can the change ship? According to a 404 Media investigation into Proton, it also prompted disparaging language in an internal Slack channel.

The faster a company moves with AI, the more carefully it must protect the right to say: “We have not verified this sufficiently yet.” This is about more than coding tools. It concerns how leaders receive objections, approve releases and make a promise of trust credible. It does not establish that Proton’s products have been compromised.

What does the Proton investigation actually report?

In his 29 October 2026 investigation, Joseph Cox says he spoke with eight current Proton employees and one former employee, and reviewed Slack messages, meeting recordings and an internal AI manifesto. Those are the journalist’s findings; we have not independently authenticated the internal material. Frandroid covered the story in French the same day.

404 Media reports that, in late August, an employee asked for at least a few days to conduct penetration testing on newly written code before putting it into production. The outlet attributes this reply to CEO Andy Yen: That’s bullshit and loser thinking. Of course it’s possible to be fast and secure. These were internal remarks made public through reporting, not a statement the CEO chose to deliver publicly.

The second sentence matters: Yen argues that speed and security can coexist. Treating this exchange as an admission that all testing had been abandoned would misrepresent it. The management question remains: can someone request a security check without having that request dismissed as a lack of ambition?

Why “90% AI-written” does not establish code quality

According to the investigation, CTO Bart Butler said in a meeting that 90% of the code written at Proton in October was written by AI. That does not mean 90% of Proton’s entire historical codebase. The calculation method and denominator are not explained: accepted suggestions, generated lines and deployed code need not measure the same thing.

Several employees quoted by 404 Media describe substantial use of Claude. That does not establish that Claude alone produced the whole 90%, or that customer emails, passwords or files were sent to Anthropic. The tools used to develop a product and the flows of its users’ data are separate questions.

The September manifesto reportedly sets a goal of having most code reviewed by AI rather than humans. The investigation also describes a proposed future in which humans write test specifications and AI writes and runs those tests. These are reported directions, not evidence of a practice already implemented everywhere. The article also includes instructions to check code and an employee’s statement that engineers still strive to build securely.

Before approving a release, a leader needs evidence about this change, not just a count of how much code AI wrote. A generated-code percentage does not, by itself, tell a buyer or a leader which risks were covered or how good the review was.

Trust also depends on which decisions employees can challenge

Proton provides privacy- and security-focused services. For a business whose customers rely on that protection, the treatment of a technical objection also matters to communication: the external promise depends on relevant concerns being able to reach decision-makers internally.

The risk is a mechanism, not a demonstrated incident. If asking for verification carries a social cost, an employee may hesitate to raise the next concern. Leaders could then hear fewer objections without the product becoming any more reliable. We cannot establish that this chain caused a vulnerability at Proton. It explains why the reported exchanges deserve attention beyond their wording.

Proton’s response appears in the investigation. Its spokesperson acknowledges that employees are unhappy or anxious and that, in trying to move quickly, leadership has sometimes been too blunt or too slow to explain itself. Cox writes that the spokesperson did not dispute his reporting or characterisation. This is a response reproduced by the journalist, not an independent technical confirmation of every reported fact.

Speed and verification need not be opposing positions. An objection can be vague, a requested delay excessive or a proposed test poorly targeted. Establishing that requires examining the risk and the evidence needed, rather than judging the person who raises them.

How can a team move faster without penalising verification?

Leaders do not need to impose the same waiting period on every release. They need criteria that make decisions open to examination and traceable afterwards. The following are proposed operating rules, not claims about the procedures actually in place at Proton.

• Define what makes a release acceptable. Before development, name the behaviours and permissions to check, acceptable limits and expected results. “AI reviewed the code” describes an activity, not its outcome.
• Make the trade-off explicit. If a deadline takes priority over another check, record what is deferred, who accepts the risk and which restriction accompanies the release. Reducing scope may be preferable to removing a critical control.
• Record objections without penalising the person raising them. A request should identify the feared scenario, proposed check and decision needed. A responsible owner can reject it with a recorded reason and an escalation route, without turning disagreement into a loyalty test.
• Retain review and test evidence. Identify the version, checks performed, results and remaining limitations. When AI writes both the code and its tests, examine whether the tests merely repeat the same mistaken assumptions.

Illustrative example, unrelated to any Proton incident: a small business wants to release an AI-generated customer portal. Login works, but an engineer has not yet checked that one customer cannot view another customer’s quote. The decision concerns a specific permission. The team can delay public access, restrict the release to a pilot or fix and test the issue. Counting generated lines does not resolve it.

This distinction between a demonstration and evidence starts earlier in product development. User testing an AI prototype checks whether someone understands the journey, not whether customer records are isolated. Both checks matter, but they answer different questions.

What should a leader ask before approving a release?

Three questions open the right conversation: what have we verified on this version? What remains uncertain? Who decides how users will be exposed, and how can we roll back? The answers can be brief. They need to be specific.

In our MVP development framework, the criteria established during scoping feed into tests and CI/CD: automated delivery checks. A controlled rollout and measurement then support corrections based on actual observations. AI can speed up several steps; someone still has to define the evidence required to move to the next one.

The lesson from this investigation is not to ban AI-written code or declare Proton compromised. It is to take the cost of a difficult objection seriously. A team that can produce more quickly must also be able to identify what it has not sufficiently verified, without discrediting the person who says so.

Building with AI while release criteria remain unclear? Say Digital can help scope the requirements, tests and rollout for your next version. Discuss your delivery process with Say Digital.

Sources and limitations

• Joseph Cox, 404 Media, 29 October 2026: original investigation and the spokesperson’s response reproduced in the article, linked above.
• Frandroid, Cassim Montilla, 29 October 2026 at 17:07: French coverage, linked above.

Sources reread on 30 October 2026. A targeted additional check of Proton’s official blog and Andy Yen’s author page did not identify a separate response on those surfaces; that does not establish that none exists elsewhere. This is management and software-delivery analysis, not a technical audit of Proton. The sources reviewed do not demonstrate a customer-data leak, compromised products or the removal of all testing.