Claude Opus 5.5 ging mit Motion Graphics viral. Doch Cybersicherheit könnte die größere Geschichte sein.

Die Clips der Launch-Woche waren kaum zu übersehen: kinetische Typografie, Produktfilme, animierte Logos und 3D-Szenen, erstellt mit Claude Opus 5.5.

Interessant ist, wie viele davon entstanden sind. Anthropics Modelldokumentation beschreibt Eingaben aus Text und Bildern sowie Textausgaben, aber keine native Videoausgabe. Ein öffentliches Verzeichnis eines Drittanbieters berichtet, dass viele Kreative Claude zum Schreiben von HTML-, Canvas- oder SVG-Animationen nutzten und diese anschließend als Video aufzeichneten oder rendern ließen. Zum Zeitpunkt unserer Prüfung umfasste das Verzeichnis 1.048 Clips mit 73,6 Millionen Aufrufen auf X. Es weist jedoch auch darauf hin, dass sich die Entstehungsweise nicht für jeden Clip unabhängig verifizieren lässt. Diese Summen sind daher als Momentaufnahme der Aufmerksamkeit in sozialen Medien zu verstehen, nicht als offizielle Modellkennzahl. (Claude Opus 5.5 Video Examples & Prompts; weitere Beispiele in einer Sammlung aus der Launch-Woche)

Dieser Unterschied weist auf die größere Geschichte hin. Die Animation ist das sichtbare Ergebnis; dahinter arbeitet ein Modell in einer Schleife aus Planen, Code schreiben, Ausführen, Beobachten und Überarbeiten.

Motion Graphics machen den agentischen Ablauf sichtbar

Aus einem kreativen Briefing kann eine Abfolge von Schritten werden:

Ziel → Planen → Code schreiben → Ausführen → Ergebnis prüfen → Überarbeiten

Die Anwendungssicherheit kann einen ähnlichen Ablauf nutzen:

Anwendung verstehen
  → Code und erreichbares Verhalten untersuchen
  → Eine Angriffshypothese aufstellen
  → Im autorisierten Umfang testen
  → Anhand beobachtbarer Belege validieren
  → Auswirkungen erklären und nach der Behebung erneut testen

In den beiden Bereichen gelten unterschiedliche Risiken, doch das Muster der Fähigkeiten ist verwandt. Ein Agent liefert nicht nur einen ersten Entwurf: Er kann Werkzeuge einsetzen, Ergebnisse beobachten und so lange weiterarbeiten, bis ein überprüfbares Resultat vorliegt.

Das ist für die Softwareentwicklung nützlich. Zugleich stellt sich für Sicherheitsteams eine praktische Frage: Wie kann die Verifikation Schritt halten, wenn sich Code schneller ändert?

Opus 5.5 ist auf lang laufende Aufgaben ausgelegt

Anthropic veröffentlichte Claude Opus 5.5 am 22. September 2026 und positionierte das Modell für lang laufendes agentisches Coding und Wissensarbeit. Anthropic zufolge nutzten frühe Tester es, um eine Migration mit 680.000 Codezeilen in weniger als einem Tag abzuschließen und eine Codebasis mit 200.000 Zeilen in weniger als drei Stunden zu prüfen und zu korrigieren. Das sind vom Anbieter berichtete Beispiele, keine kontrollierten Schätzungen dessen, was jedes Team erwarten sollte. (Anthropics Ankündigung zu Opus 5.5; Modelldokumentation)

Auch Anthropics veröffentlichte Ergebnisse zeigen, dass Opus 5.5 und Sonnet 5.5 bei einigen Evaluierungen nahe beieinanderliegen. Die gemeldeten Werte betragen 66,4 % gegenüber 70,6 % bei Terminal-Bench 4.0, 57,8 % gegenüber 55,5 % bei CursorBench 4.0 sowie 1.846 gegenüber 1.844 bei GDPval-AA v2.1. Benchmark-Ergebnisse hängen vom Testaufbau, der gewählten Aufwandsstufe und dem Aufgabenmix ab. Bei einigen Tests wurden zudem unterschiedliche Aufwandsstufen verwendet; die Ergebnisse sind daher nicht als direkter Vergleich unter gleichen Bedingungen zu verstehen. Anthropic weist selbst darauf hin, dass kleine Punktunterschiede die Leistung in der Praxis nicht zuverlässig vorhersagen. (Anthropics Opus-Ankündigung; Sonnet-Ankündigung)

Sonnet 5.5 senkt die Kosten dafür, den Ablauf zu wiederholen

Anthropic veröffentlichte Sonnet 5.5 am 28. September als schnellere und günstigere Ergänzung zu Opus. Die veröffentlichten API-Preise liegen bei 2 US-Dollar pro einer Million Eingabe-Token und 10 US-Dollar pro einer Million Ausgabe-Token, gegenüber 4 beziehungsweise 20 US-Dollar bei Opus 5.5. Anthropic gibt außerdem an, dass Sonnet 5.5 mehr als 30 % schneller Text generiert als Sonnet 5 und pro Aufgabe bis zu 30 % weniger kosten kann als sein Vorgänger. (Sonnet-Ankündigung; Sonnet-Modelldokumentation)

Das verändert die Wirtschaftlichkeit agentischer Arbeit. Die Frage lautet nicht mehr nur, ob ein Modell eine lange Folge von Softwareaufgaben bewältigen kann. Es geht auch darum, wie oft sich Teams solche Abläufe über Repositories, Pull Requests und Entwicklungsworkflows hinweg leisten können.

Die frühe Review-Evaluierung von CodeRabbit liefert ein begrenztes Beispiel. In 13 schwierigen Fällen mit bekannten Fehlern fand Sonnet 5.5 durch umsetzbare Kommentare 6 Probleme, Sonnet 5 hingegen 4. Bei einer separaten Stichprobe von 44 Open-Source-Pull-Requests ermittelte CodeRabbit eine durchschnittliche Review-Zeit von 6 Minuten und 33 Sekunden für Sonnet 5.5 und 13 Minuten und 31 Sekunden für Sonnet 5. Die Autoren bezeichnen die erste Stichprobe als klein und merken an, dass der größere Durchlauf Arbeitsaufwand und Geschwindigkeit, nicht aber die Review-Qualität, gemessen hat. (CodeRabbits Evaluierung)

Diese Ergebnisse gelten für die Pipeline von CodeRabbit. Sie sind kein allgemeingültiges Ranking, zeigen aber, warum schnellere und günstigere Reviews zu einem festen Bestandteil der Softwarebereitstellung werden können.

Besseres Coding bedeutet nicht automatisch Sicherheit

Ein Modell kann funktionsfähige Software erzeugen, ohne alle Sicherheitsanforderungen zu erfüllen. Sonars Evaluierung von Java-Code, der mit Opus 5.5 erzeugt wurde, ergab eine um 9 % geringere Schwachstellendichte als bei Opus 5 und zugleich 27,5 % weniger generierten Code. In Sonars Kategorietabelle entwickelten sich die Rohzahlen jedoch unterschiedlich: Die Zahl der Injection-Befunde stieg von 7 auf 17, die der Path-Traversal-Befunde von null auf fünf. Sonars Test ist ein einzelner Benchmark mit einer bestimmten Codebasis-Mischung und kein allgemeingültiges Sicherheitsmaß. Er zeigt jedoch, warum eine Verbesserung des Gesamtwerts eine Verschlechterung in einer bestimmten Schwachstellenklasse verbergen kann. (Sonars Evaluierung)

Die Agent Security League von Endor Labs fand in ihrem eigenen Benchmark eine ähnliche Lücke. Nach Anwendung des Anti-Memorization-Filters erreichte Opus 5.5 bei 68,7 % der Aufgaben die funktionalen Kriterien; bei 33,5 % erfüllte es sowohl die funktionalen als auch die Sicherheitskriterien. Diese Quoten beziehen sich auf eine bestimmte Evaluierung mit 179 Aufgaben und einem spezifischen Agenten-Testaufbau; sie schätzen nicht den Anteil aller generierten Codeabschnitte, die sicher sind. Die engere Schlussfolgerung lautet: Funktionaler Erfolg allein belegt kein sicheres Verhalten (Auswertung von Endor Labs).

Die hilfreiche Frage für die AppSec lautet daher nicht einfach: „Ist dieses Modell besser?“ Sondern: „Welche Sicherheitsannahmen sind von dieser Änderung betroffen, und können wir belegen, ob der resultierende Pfad erreichbar und ausnutzbar ist?“

Auch Anthropics eigene Entscheidungen zur Veröffentlichung unterstreichen diesen Unterschied. Das Unternehmen erklärt, Opus 5.5 verfüge über starke Cybersicherheitsfähigkeiten und unterliege den Schutzmaßnahmen, die es für seine leistungsfähigsten Modelle einsetzt. Außerdem sei Sonnet 5.5 das erste Sonnet-Modell, das mit vergleichbaren Cyber-Schutzmaßnahmen und einem Fallback-Verhalten veröffentlicht werde. Anthropic beschreibt diese Kontrollen als auf eine eng begrenzte Gruppe von Anfragen mit hohem Risiko ausgerichtet; gewöhnliche Softwareentwicklung sei davon in der Regel nicht betroffen. (Opus-Ankündigung; Sonnet-Ankündigung)

Cybersicherheitsfähigkeiten halten Einzug in weitere Modellklassen jenseits der teuersten Stufe. Das eröffnet Verteidigern Chancen und erhöht zugleich den Druck auf AppSec-Programme, die sich noch auf langsame manuelle Triage stützen.

Die Verifikationsgeschwindigkeit muss mit der Codegeschwindigkeit Schritt halten

KI-Coding-Agenten können Repositories prüfen, mehrere Dateien bearbeiten, Tests ausführen und Änderungen überarbeiten. Wenn Umfang und Tempo dieser Änderungen zunehmen, lässt sich die manuelle Prüfung jeder Zeile durch eine Sicherheitsfachkraft immer schwerer aufrechterhalten. Mehr Scanner können eine weitere Warteschlange mit Funden erzeugen, ohne zu zeigen, welche davon tatsächlich relevant oder erreichbar sind.

Die AppSec muss ihre Verifikationsgeschwindigkeit erhöhen, nicht nur die Zahl erkannter Probleme. Sicherheitsworkflows sollten:

• Anwendungspfade innerhalb eines klar festgelegten und autorisierten Umfangs testen;
• einen Fund mit dem Code und dem Datenfluss verknüpfen, die seine Auswirkungen erklären;
• Belege und Unsicherheiten für die Prüfung durch Verantwortliche festhalten; und
• das relevante Verhalten nach der Behebung erneut testen.

Das ist die Logik hinter Proof-Driven AppSec: verifizieren, was tatsächlich vorliegt, den betroffenen Pfad verstehen und Belege durch Behebung und Verifikation hindurch mitführen. Mehr Codegenerierung erfordert mehr Validierung. Mehr Autonomie erfordert stärkere Belege und klare menschliche Kontrolle über folgenreiche Entscheidungen.

Vielleicht wird Opus 5.5 wegen seiner Motion Graphics in Erinnerung bleiben. Für Sicherheitsteams ist der agentische Ablauf dahinter entscheidend – und die Frage, ob die Verifikation im selben Tempo vorankommen kann.