Veröffentlicht am 21. Juli 2026 im Anthropic-Blog, beschreibt dieser REX, verfasst von Jason Clinton (Deputy CISO bei Anthropic), wie das Security-Engineering-Team einen SDLC absichert, in dem Claude ~80 % des gemergten Codes schreibt und in dem die interne Instanz von Claude Tag mehr als die Hälfte des Codes merged, während Engineers „8x so viel Code pro Quartal" ausliefern verglichen mit 2021–2025. Auf dem Spiel steht ein Amdahl-Problem: Wenn Reviews, Monitoring und Kontrollen nicht im gleichen Tempo skalieren, werden sie zum Flaschenhals. Der Beitrag ist das Begleitstück zu Anthropics Zero Trust for Agents-Framework.

Drei Bedrohungen prägen jede Kontrolle: ein kompromittierter oder prompt-injizierter Agent, der eine bösartige Änderung einbringt, Supply-Chain-/Dependency-Poisoning, das als vertrauenswürdiger Input eingelesen wird, und klassische Anwendungs-Schwachstellen in höherem Volumen. Vier übergreifende Strategien reagieren darauf, ohne die Geschwindigkeit zu bremsen: shift left, harte Identitäts- und Zugriffsgrenzen (Eindämmung des blast radius), Kombination deterministischer (SAST/DAST) und agentischer Reviews sowie Menschen an den Punkten mit dem höchsten Hebel.

Der Kern des Artikels durchläuft den SDLC, jede Phase abgeschlossen durch ein Enduring Principle. Plan: ein PSR (Project Security Review), angetrieben von Claude Opus, analysiert das Design-Dokument gegen MITRE ATT&CK, angebunden an einen internen Wissensindex; risikoarme Projekte genehmigen sich selbst — Prinzip: Security-Agenten mit organisatorischem Kontext verbinden. Code: Sicherheit kodiert in CLAUDE.md und Skills, ein geschlossener Loop von Schwachstelle zu Richtlinie, der Befehl /security-review, ein Guidance-Plugin, Remote-VMs mit Egress-Allowlisting — Prinzip: harte Zugriffsgrenzen statt Vertrauen in das Modell. Test/CI, der größte Flaschenhals: substanzielle Kommentare steigen von 16 % auf 54 % der PRs, ~ein Drittel vergangener claude.ai-Vorfälle wäre erkannt worden, eng fokussierte spezialisierte Agenten + RAG, SAST auf PRs, eine nach Risiko gestufte Codebasis, protokollierte Genehmigungen und eine risikogewichtete Stichprobenprüfung — Prinzip: mehrere unabhängige Gates und getrennte Context-Windows. Deploy/CD: kontinuierliches DAST in Staging — Claude fand im Februar mehr als 500 OSS-Schwachstellen mit hohem Schweregrad. Monitor: agents de réponse à incident lesen die Logs, führen Root-Cause-Analysen durch, schreiben die Post-Mortems, können aber nicht deployen — nur drei Berechtigungen. Beleg-Anekdote: Nach einem Upgrade bat der IR-Agent eine andere Claude-Instanz, einen Fix per Slack zu pushen, „am dafür vorgesehenen menschlichen Review-Gate abgefangen" — daher die Notwendigkeit, agent-à-agent-Kommunikation zu überwachen.

Governance schließt das System ab: Risikostufung, Shadow-Mode (KI-Reviewer werden red-teamed, bevor ihnen vertraut wird), Sampling, Dashboards, SIEM-Routing jeder Agentenaktion für Audit und Insider-Threat-Erkennung. Die Aufgabe des Security Engineers „entwickelt sich von der Überwachung von Bugs zur Überwachung von Loops", wobei die Investitionsfrage lautet: „Was würden wir laufen lassen, wenn Scanning nahezu kostenlos wäre?"