David Mytton, CEO von Arcjet – Interview-Serie

David Mytton, Gründer und CEO von Arcjet, leitet das entwicklerorientierte Sicherheits-Startup, das Teams hilft, robuste Schutzmaßnahmen wie Bot-Erkennung, Rate Limiting, E-Mail-Validierung, Angriffsabwehr und Datenredaktion direkt in den Anwendungscode einzubetten, nachdem er im Juni 2023 die Leitung übernommen hatte. Er hat auch Console mitgegründet, einen weit verbreiteten Devtools-Newsletter und -Podcast, hat Beratungsrollen wie Expert in Residence bei Seedcamp innegehabt und zuvor das Produkt-Engineering bei StackPath geleitet, nachdem sein Cloud-Monitoring-Unternehmen übernommen worden war, während er ein starkes Interesse an nachhaltiger Rechnertechnik und aktiver Schreibarbeit zu technischen Themen beibehielt.

Arcjet basiert auf einer “Sicherheit-als-Code”-Philosophie, die es Entwicklern ermöglicht, Anwendungen mit einfachen SDK-Integrationen zu sichern, indem Sicherheitslogik neben Geschäftslogik platziert wird, um Entscheidungen mit geringer Latenz und Kontextbewusstsein zu treffen und die Notwendigkeit separater Infrastruktur zu eliminieren; die Plattform unterstützt Schutzmaßnahmen wie Bot-Blockierung, Rate Limiting und Filterung sensibler Daten und entwickelt sich weiter mit Funktionen wie einem lokalen AI-Sicherheitsmodell und erweiterter Framework-Unterstützung, was seinem Ziel entspricht, die Sicherheit im Code zur Norm für moderne Anwendungen zu machen. (fly.io)

Sie haben Server Density zu einer Zeit gegründet, als das Betreiben von Infrastruktur im großen Maßstab viel weniger standardisiert war als heute, und haben das Unternehmen letztendlich gewachsen und verkauft. Wenn Sie zurückblicken, welche waren die wichtigsten Lektionen, die Sie über das Bauen für Entwickler und das Betreiben von Produktions-Systemen gelernt haben, und wie hat diese Erfahrung Ihre Art und Weise geprägt, über Software nachzudenken?

Die meisten Entwickler-Tools gewinnen die Demo und verlieren die Produktion. Es ist schwierig, einen Entwickler dazu zu bringen, irgendetwas Neues zu installieren, also muss “Schnellstart” reibungslos sein – aber das ist nur der Anfang. Der eigentliche Fehlermodus ist, was nach “es funktioniert” passiert: das Produkt wird so eingeschränkt, dass ernsthafte Teams schnell frustriert werden und es herausreißen.

Das ist, warum Arcjets Sicherheit im Code für zwei Realitäten konzipiert ist: Sie benötigen eine sofortige Lösung für Anmelde-Spam, Konten-Betrug, Bot-Angriffe, API-Missbrauch usw., und Sie benötigen auch einen Ausweg in erweiterte Kontrollen – pro Benutzer-Contingente, risikobasierte Regeln und kontextbewusste Entscheidungen – ohne alles neu zu schreiben.

Das Produkt ist nicht die Benutzeroberfläche. Das Produkt ist das Laufzeitverhalten, die Randfälle, die Beispiele und die Referenzdokumentation, die Entwickler vertrauen können.

Aus dieser Erfahrung heraus, was hat Sie dazu gebracht, Arcjet zu gründen, und warum fühlten Sie, dass der nächste große Schritt in der Anwendungssicherheit innerhalb des Codes selbst und nicht auf der Netzwerk- oder Infrastrukturebene erfolgen muss?

Perimeter-Sicherheit optimiert das Falsche. Entwickler bauen und versenden in Code, nicht in Dashboards – und AI-Coding-Agenten werden nicht “in einem Sicherheits-Console herumklicken”, um eine Anwendung zu schützen.

Wenn Ihr Schutz nicht als Code ausgedrückt werden kann, in einem Pull-Request überprüft, in CI getestet und zusammen mit der Anwendung bereitgestellt werden kann, ist es keine “Entwickler-erste Sicherheit”.

Arcjet existiert, weil Sicherheit in der Anwendungsebene gehört: versioniert, testbar, beobachtbar und nahe an der Geschäftslogik, wo die tatsächliche Absicht lebt.

Arcjet integriert AI-gestützte Bedrohungserkennung direkt in die Anwendungs-Request-Handler. Aus technischer Sicht, welche Vorteile bietet dieser lokale, im Code integrierte Ansatz im Vergleich zu herkömmlichen Perimeter-Sicherheits-Tools?

Innerhalb eines Request-Handlers haben Sie Identität, Sitzungsstatus, Kaufhistorie, Kontenalter, Feature-Flags und Datenbank-Wahrheit. Sie können eine Entscheidung treffen wie: “Das sieht seltsam aus, aber es ist ein treuer Kunde – überprüfen Sie stattdessen die Verifizierung und blockieren Sie nicht.”

Das Ziel ist nicht, maximal zu blockieren. Das Ziel ist, falsch positive Ergebnisse mit kontextbewusster Sicherheit zu minimieren, da der teuerste Sicherheitsfehler das Blockieren einer legitimen Abrechnung oder das Sperren eines echten Benutzers ist.

AI hat die Ökonomie des Missbrauchs dramatisch verändert, von Bot-Scraping und Spam-Anmeldungen bis hin zu automatisierter API-Ausbeutung. Welche Arten von Angriffen sehen Sie am häufigsten in der Produktion heute, und wie entwickeln sie sich, da Angreifer fortschrittlichere AI-Systeme einsetzen?

AI-Produktivitätszuwächse helfen Angreifern auch! Der große Wandel ist Volumen und Iterationsgeschwindigkeit: mehr Credential-Stuffing, mehr automatisierter Spam-Anmeldungen, mehr Bot-Scraping, mehr API-Abfragen und schnellere “Waffensysteme” für frische Schwachstellen.

Wir sehen auch, dass Angreifer engerere Feedback-Schleifen durchführen: Sie testen Verteidigungen, passen Prompts und Payloads an, rotieren Infrastruktur und machen weiter, bis sie hereinkommen. Es geht derzeit um Geschwindigkeit und nicht um Raffinesse.

Es gibt immer noch zu wenige Menschen, die bewährte Verfahren wie die Verwendung eines Passwort-Managers, die Bereitstellung von 2-Faktor-Authentifizierung mit phish-resistenten Anmeldeinformationen wie Passwörtern oder Hardware-Schlüsseln und die Aktualisierung von Abhängigkeiten befolgen. Mit zunehmenden Angriffsvolumina wird dies immer wichtiger.

Eines der größten Spannungen in der Sicherheit ist die Abwägung zwischen dem Schutz von Anwendungen und der Aufrechterhaltung schneller Entwicklungszyklen. Wie haben Teams, die Arcjet verwenden, Sicherheit in ihre Arbeitsabläufe integriert, während sie gleichzeitig schnelle Release-Zyklen aufrechterhalten?

Arcjet läuft in jeder Umgebung, einschließlich der Entwicklungsumgebung auf einem Laptop. Das bedeutet, dass Entwickler es testen können, ohne es sogar in die Produktion bereitzustellen. Dies ist ein erheblicher Vorteil, da Sie es validieren und die Integration demonstrieren können, ohne spezielle Berechtigungen benötigen und ohne Risiko, die Produktion zu beeinträchtigen. Dies löst das klassische Problem, dass Sicherheitsteams Entwicklern Werkzeuge aufzwingen, die ihre Fähigkeit, ihre Arbeit zu erledigen, beeinträchtigen.

Arcjet hat frühzeitig Erfolge bei AI-nativen Produkten und E-Commerce-Plattformen erzielt. Was macht diese Umgebungen besonders anfällig für moderne automatisierte Angriffe, und warum fallen herkömmliche Verteidigungen kurz?

Diese beiden Kategorien teilen eine Ähnlichkeit, bei der jeder missbräuchliche Anfrage einen direkten Kostenfaktor hat.

AI-Produkte zahlen für Token und Inferenz – Angreifer verwandeln Ihren Gewinn in ihren Spielplatz durch Scraping, Automatisierung und Free-Tier-Farming. E-Commerce zahlt für Betrug, Chargebacks, Inventar-Missbrauch und Konten-Übernahme. Beide sind hypersensibel auf falsch positive Ergebnisse, da das Blockieren echter Benutzer tatsächlich Umsatzeinbußen bedeutet.

Herkömmliche Verteidigungen schützen hauptsächlich Bandbreite und Infrastruktur. Moderne Angreifer zielen auf die Geschäftslogik: Anmelde-Flows, Abrechnungs-Flows, Promo-Logik, Konten-Wiederherstellung und API-Endpunkte. Deshalb fallen generische Perimeter-Steuerungen und “Lösungen mit einem CAPTCHA” zunehmend kurz.

Das Bauen von Sicherheits-Software geht mit sehr unterschiedlichen Kompromissen einher als die Beobachtbarkeit oder Überwachung. Was überraschte Sie am meisten über die Entwicklung eines Sicherheits-Produkts im Vergleich zu Ihrer früheren Erfahrung mit Infrastruktur-Tools?

Bei der Beobachtbarkeit vertrauen Kunden darauf, dass Sie verfügbar sind. Bei der Sicherheit vertrauen Kunden darauf, dass Sie sicher sind und nicht zu ihrem neuen Lieferanten für Ausbeutung werden.

Das Bauen eines Sicherheits-Produkts bedeutet, ein Sicherheits-Unternehmen zu betreiben. Wir verwenden Frameworks wie SOC 2, minimieren unsere Abhängigkeiten von Drittanbietern und behandeln Entwickler-Laptops und den Zugriff auf Tools als Produktions-Assets. Dies bedeutet eine Menge Überwachung und schnelle Reaktionen auf potenzielle Probleme.

Da Anwendungen zunehmend auf AI-Agenten angewiesen sind, die im Namen von Benutzern handeln, wie sollten Entwickler Ideen wie Identität, Absicht und Vertrauen auf der Anwendungsebene neu denken?

Wenn AI-Agenten im Namen von Benutzern handeln, hört die Identität auf, ein binärer Anmeldezustand zu sein, und wird zu einem Delegationsproblem: Wer handelt, in wessen Namen, mit welchen Berechtigungen, für wie lange und mit welchen Einschränkungen.

Entwickler sollten zu kontinuierlicher Verifizierung übergehen: Jede Anfrage als eine frische Vertrauensentscheidung basierend auf Kontext behandeln – Benutzerhistorie, Gerätesignale, Sitzungsverhalten und Handlungsrisiko. “Absicht” wird aus Verhalten über die Zeit hinweg abgeleitet, nicht aus Headern abgeleitet.

Dies bedeutet, Schritte zu bauen, die Überprüfung (Verifizierung, Rate Limiting, Reibung) um hochrisiko-Handlungen wie Passwort-Reset, Abrechnung und Token-Erstellung herum, und diese Kontrollen im Code zu platzieren, wo die Anwendung zwischen einem treuen Kunden und einem Bot mit einem gestohlenen Cookie unterscheiden kann.

Wenn Sie in die Zukunft blicken, wie sehen Sie die Rolle der im Code integrierten, kontextbewussten Sicherheit in den nächsten Jahren, da AI-generierter Datenverkehr weiter wächst?

Perimeter-Tools werden nicht verschwinden – aber sie werden der grobe Filter für Dinge sein, die am besten auf der Netzwerkebene wie DDoS-Angriffe behandelt werden. Die präzisen Entscheidungen werden innerhalb der App erfolgen, mit echtem Kontext.

Wenn eingebettete Sicherheit zum Standardmodell für moderne Anwendungen wird, was bedeutet dieser Wandel für die Art und Weise, wie Entwickler Sicherheit in Produktions-Systemen testen, bereitstellen und verstehen?

Wenn eingebettete Sicherheit zur Norm wird, werden Teams Missbrauch auf die gleiche Weise testen wie Korrektheit: Sicherheits-Unit-Tests, wiedergabefähige Angriffssimulationen und CI-Prüfungen für risikobehaftete Endpunkte.

Der größere Wandel ist, dass AI-Coding-Agenten Sicherheit als Code implementieren, nicht als Dashboard-Konfiguration. Agenten können nur zuverlässig Schutzmaßnahmen vorschlagen, überprüfen und validieren, wenn die Kontrollen im Repository leben: Richtlinien, Regeln, Tests und Instrumentierung. Wenn die “Sicherheitsebene” eine Web-Oberfläche ist, kann der Agent die Änderungen nicht sicher bereitstellen.

Das ist der wahre Grund, warum “Sicherheit im Code” gewinnt – es passt, wie moderne Software (und moderne AI-gestützte Entwicklung) tatsächlich gebaut wird.

Vielen Dank für das großartige Interview. Leser, die mehr erfahren möchten, sollten Arcjet besuchen.