KI-generierter Code bei Proton: Was der Eklat über Sicherheit verrät

Hinweis: Dieser Beitrag wurde mit KI-Unterstützung erstellt und automatisiert veröffentlicht.

Wenn ein Anbieter, dessen ganzes Geschäftsmodell auf Vertrauen beruht, intern über Sicherheitstests streitet, wird daraus schnell mehr als eine Personalie. Genau das ist bei Proton passiert: Geleakte Slack-Nachrichten und Besprechungsmitschnitte zeigen, wie stark das Unternehmen auf KI-generierter Code setzt – und wie wenig Raum Einwände dazu offenbar hatten. Der Fall ist deshalb interessant, weil er eine Frage beantwortet, die aktuell in vielen IT-Abteilungen offen ist: Was passiert, wenn Geschwindigkeit das einzige Ziel ist?

Was im Proton-Eklat passiert ist

Grundlage ist eine Recherche von 404 Media, für die acht aktive und ein ehemaliger Mitarbeiter befragt sowie interne Slack-Kanäle, Audiomitschnitte und das KI-Manifest des Unternehmens ausgewertet wurden. heise online hat die Vorgänge am 3. November 2026 aufgegriffen und um die offizielle Reaktion ergänzt. Die belegten Kernpunkte:

• Ein Mitarbeiter schlug im Security-Kanal vor, neuen Code vor dem Live-Gang wenigstens einige Tage zu testen. Die Antwort von CEO Andy Yen fiel laut den Mitschnitten abweisend aus – er nannte die Haltung sinngemäß „Denkweise von Versagern“ und hielt dagegen, man könne sehr wohl schnell und sicher sein.
• Laut einer Audioaufnahme einer internen Besprechung, die 404 Media vorliegt, wurden rund 90 Prozent des im Oktober 2026 neu entstandenen Codes von KI geschrieben. Die Angabe stammt aus dem Unternehmen selbst, eine Methodik ist nicht veröffentlicht, und die Zahl ist nicht unabhängig bestätigt – sie betrifft also nicht den gesamten Codebestand.
• Im KI-Manifest des Unternehmens kommt Sicherheit nur an einer Stelle vor – mit dem Hinweis, dass das Thema dort nicht tiefer behandelt wird.
• Yen hat sich inzwischen öffentlich entschuldigt – in einem Community-Post auf Reddit sowie in einem Unternehmens-Statement vom 30. Oktober. Er räumt Fehler im Kommunikationsstil ein, hat die geplanten erneuten Bewerbungsgespräche zum KI-Einsatz abgesagt und zugesagt, dass KI-Einsatz nicht auf Kosten der Sicherheit gehen werde. Am Kurs selbst hält er fest.
• Berichte, Proton überwache per Software auf Firmenrechnern den Anteil KI-generierten Codes, widerspricht das Unternehmen. Dieser Punkt ist strittig.

Newsletter

Klartext zu KI, Security, Crypto

Einordnung statt Hype: was hinter den Tech-News steckt und was davon für dich zählt. Startbonus: die AD-Checkliste mit 12 Sofortmaßnahmen als PDF.

E-Mail-Adresse *

Mit der Anmeldung erhältst du die AD-Checkliste als PDF und danach den Tech-&-Tacheles-Newsletter mit Einordnungen zu Security, KI und Crypto sowie gelegentlichen Hinweisen auf meine Bücher und Produktempfehlungen (auch Affiliate-Links) – eingetragen bist du erst nach Klick auf den Bestätigungslink in der E-Mail (Double-Opt-in). Ich werte aus, ob du den Newsletter öffnest und Links anklickst, um ihn zu verbessern. Abmeldung jederzeit über den Link in jeder E-Mail, Details in der Datenschutzerklärung.

Was das für dich bedeutet

Nach 25 Jahren in der IT – und mit dem Blick, den man sich als Sicherheitsverantwortlicher antrainiert – ist das Bemerkenswerte an diesem Fall nicht die Prozentzahl. Es ist der Satz „jeder Entwickler soll seinen Code mit KI prüfen, statt manuell“. Das klingt effizient, verschiebt aber eine Kontrolle, die bewusst außerhalb der Produktion lag, in genau denselben Prozess hinein. Wer dasselbe Werkzeug schreiben und prüfen lässt, hat kein Vier-Augen-Prinzip mehr, sondern ein Zwei-Augen-Prinzip mit Brille.

Praktisch heißt das: KI im Entwicklungsprozess ist kein Sicherheitsproblem, solange die Prüfschicht unabhängig bleibt. Problematisch wird es erst, wenn Tempo zur Kennzahl wird und Tests als Bremse gelten. Diese Dynamik kennt man aus klassischen Projekten – neu ist nur, dass die Codemenge pro Woche jetzt vielfach höher liegt. Dass automatisierte Beiträge längst Normalität sind, zeigt GitHubs Octoverse-Bericht 2026: Im September 2026 starteten mehr als 40 Prozent aller Pull Requests mit dem ersten Entwurf eines Agenten – im März waren es noch 17 Prozent.

Fairerweise gehört dazu: Proton hat nach eigener Darstellung zusätzliche Sicherheitsprüfungen eingeführt, lässt den eigenen Code mit KI auf Schwachstellen scannen und will Code- und Security-Review-Prozesse sowie interne Werkzeuge offenlegen. Ob das die beschriebene Dynamik wirklich ausgleicht, lässt sich erst beurteilen, wenn diese Unterlagen vorliegen.

Für Anwender gilt dabei: Panik ist unangebracht. Es ist keine Schwachstelle in Proton-Produkten bekannt geworden, und die Verschlüsselung selbst steht nicht infrage. Was hier wackelt, ist ein Prozessversprechen – und das ist bei einem Privacy-Anbieter trotzdem relevant.

Drei Leitplanken für KI-generierten Code

• Prüfung von der Erzeugung trennen. Lass KI Code schreiben, aber prüfe mit einer anderen Kette: SAST, Dependency-Scan und mindestens ein menschliches Review bei allem, was Authentisierung, Kryptografie oder Rechteprüfung berührt.
• Merge-Gates technisch erzwingen. Branch-Protection, Pflicht-Reviewer und blockierende Pipelines sind wirksamer als jede Richtlinie, weil sie nicht unter Zeitdruck wegargumentiert werden können. Prüfe heute, ob in deinen Repos ein Push ohne Review überhaupt möglich ist.
• Herkunft dokumentieren. Markiere KI-generierte Änderungen im Commit oder Pull Request. Das kostet Sekunden und ist Gold wert, wenn du später eine Lücke eingrenzen musst – ähnlich wie beim automatisierten Lückenfinden in Open-Source-Code.

Wer das Thema systematisch aufbauen will, statt nur Einzelmaßnahmen zu sammeln, findet in meinen Buchempfehlungen zu KI und Security die Grundlagen dazu.

Quellen

• heise online: Nachrichten-Leak – Wachstum scheint bei Proton aktuell wichtiger als Sicherheit (3.11.2026)
• 404 Media: Manifestos, Fear, and Loser Thinking – Inside Proton’s AI Reckoning (Ursprungsrecherche)
• TechRadar: Proton apologizes to community after internal memo (2.11.2026)
• Proton: AI @ Proton – Engineering Manifesto (1.11.2026)
• GitHub Octoverse 2026 (28.10.2026)