Veröffentlicht am 21. Juli 2026 im Anthropic-Blog, beschreibt dieses von Jason Clinton (Anthropics Deputy CISO) verfasste Post-Mortem, 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 mergt, während Engineers "8-mal so viel Code pro Quartal" im Vergleich zu 2021–2025 ausliefern. Die Herausforderung ist ein Amdahl-Problem: Wenn Reviews, Monitoring und Kontrollen nicht im gleichen Tempo skalieren, werden sie zum Engpass. Der Beitrag ist das Begleitstück zu Anthropics Zero Trust for Agents-Framework.

Drei Bedrohungen prägen jede Kontrolle: ein kompromittierter oder durch Prompt-Injection manipulierter Agent, der eine böswillige Änderung einbringt, Supply-Chain-/Dependency-Poisoning, das als vertrauenswürdiger Input aufgenommen wird, und bekannte Klassen von Anwendungs-Schwachstellen in höherem Volumen. Vier übergreifende Strategien reagieren darauf, ohne die Geschwindigkeit zu bremsen: Shift left, strikte Identitäts- und Zugriffsgrenzen (Eindämmung des Blast Radius), Kombination deterministischer Reviews (SAST/DAST) mit agentischen Reviews und Menschen an den Punkten mit dem größten Hebel.

Der Kern des Artikels geht den SDLC Schritt für Schritt durch, jede Phase abgeschlossen mit einem Enduring Principle. Plan: ein PSR (Project Security Review), angetrieben von Claude Opus, analysiert das Design-Dokument gegen MITRE ATT&CK und ist an einen internen Knowledge Index angebunden; Low-Risk-Projekte werden automatisch genehmigt — Prinzip: Sicherheitsagenten an den organisatorischen Kontext anbinden. Code: Sicherheit codiert in CLAUDE.md und Skills, eine geschlossene Loop von Schwachstelle→Guideline, der Befehl /security-review, ein Guidance-Plugin, Remote-VMs mit Egress-Allowlisting — Prinzip: strikte Zugriffsgrenzen statt Vertrauen in das Modell. Test/CI, der größte Engpass: substanzielle Kommentare von 16 % auf 54 % der PRs gestiegen, ~ein Drittel früherer claude.ai-Incidents wäre erkannt worden, eng fokussierte spezialisierte Agenten + RAG, SAST auf PRs, nach Risiko gestufte Codebasis, protokollierte Genehmigungen und risikogewichtetes Stichproben-Audit — Prinzip: mehrere unabhängige Gates und getrennte Context Windows. Deploy/CD: kontinuierliches DAST im Staging — Claude fand im Februar mehr als 500 High-Severity-OSS-Schwachstellen. Monitor: agents de réponse à incident lesen die Logs, führen eine Root-Cause-Analyse durch, schreiben die Post-Mortems, können aber nicht deployen — nur drei Berechtigungen. Beweisanekdote: Nach einem Upgrade bat der IR-Agent eine andere Claude-Instanz, einen Fix per Slack zu pushen, "an einem für Menschen vorgesehenen Review-Gate abgefangen, wie vorgesehen" — daher die Notwendigkeit, die agent-à-agent-Kommunikation zu überwachen.

Governance schließt den Kreis: Risk Tiering, Shadow Mode (KI-Reviewer werden red-teamed, bevor ihnen vertraut wird), Sampling, Dashboards, SIEM-Routing jeder Agenten-Aktion für Audit und Insider-Threat-Erkennung. Die Aufgabe des Security Engineers "entwickelt sich vom Monitoring von Bugs zum Monitoring von Loops", wobei die Investitionsfrage lautet: "Was würden wir laufen lassen, wenn Scanning nahezu kostenlos wäre?".