Ein JSON-Datensatz mit 150 Best Practices wird geladen, und ein Python-Skript rendert daraus eine formatierte Arbeitsmappe mit Statusspalten, Belegfeldern und einer Zusammenfassung auf Basis von COUNTIF-Formeln. Zwischen beiden Schritten liegt eine Bewertung, die ein Sprachmodell anhand von Belegen aus einem GitHub-Repository vornimmt. Anlass für diesen Aufbau war der Agentic AI Lens des AWS Well-Architected Framework: ein Prüfraster für agentische KI, das sich lesen, aber nicht ohne Weiteres ausführen lässt. Smarsh, ein Anbieter von Compliance-Archivierung und Kommunikations-Governance mit über 7.000 Kunden, hat daraus einen Claude Skill gebaut und damit die erste eigene agentische Workload bewertet. Der Fall zeigt, wo Automatisierung bei Architekturprüfungen trägt und wo sie auf menschliches Urteil angewiesen bleibt.
Ein Prüfkatalog, der sich lesen, aber nicht starten lässt
Denk an die Hauptuntersuchung eines Fahrzeugs: Es gibt einen verbindlichen Katalog von Prüfpunkten und ein Protokoll, in das der Prüfer jeden Punkt mit Befund einträgt. Fehlt das standardisierte Protokoll, prüft jeder Mechaniker anders, und am Ende liegen Zettel mit handschriftlichen Notizen herum, die niemand vergleichen kann. In dieser Lage befand sich das Architekturteam von Smarsh. Der Agentic AI Lens existiert als veröffentlichte Dokumentation mit 150 Best Practices, verteilt über 41 Prüffragen und sechs Säulen, jede mit einer Risikostufe und einem gewünschten Zielzustand. Im AWS Well-Architected Tool ist er derzeit nicht als auswählbare Linse verfügbar, anders als etwa der Serverless Applications Lens.
Die zu prüfende Workload war kein Experiment, sondern ein Agentensystem zur Prüfung von Compliance-Alerts, gebaut auf den Runtime-, Gateway-, Registry- und Identity-Funktionen von Amazon Bedrock AgentCore. In einer regulierten Branche mit sensiblen Kundenkommunikationsdaten muss jede agentische Lösung eine solche Prüfung bestehen, bevor sie einen Endkunden erreicht. Damit standen zwei Wege offen: mehrere Tage manuelle Arbeit, bei der jeder Prüfer anders strukturiert, oder warten auf Konsolenunterstützung. Smarsh wählte einen dritten Weg und machte die Linse selbst ausführbar.
Drei Bausteine: Datensatz, Bewertungsleitfaden, Report-Generator
Die Umsetzung ist ein Claude Skill, also ein versioniertes Bündel aus Anweisungen, Referenzdaten und ausführbaren Skripten, das der Assistent über eine Frontmatter-Beschreibung erkennt und bei Bedarf nachlädt. Dieses Nachladen auf Anfrage, in der Fachsprache progressive disclosure, hält die Token-Kosten nahe null, solange keine Prüfung angefordert wird. Der Skill besteht aus drei Teilen mit unterschiedlichen Aufgaben, bewusst getrennt.
Der erste Teil ist lens_data.json: alle 150 Best Practices als strukturierter Datensatz mit Kennung, Säule, Prüffrage, Titel, Risikostufe und Zielzustand. Die Verteilung lautet 90 High, 59 Medium und ein Low; diese Zahlen wurden gegen den Anhang der Linse gegengeprüft, um Extraktionsfehler zu finden. Der Datensatz gilt als einzige Quelle der Wahrheit, und der Skill ist angewiesen, keine Einträge zu erfinden oder umzunummerieren. Der zweite Teil, assessment-guide.md, definiert eine Bewertungsskala mit fünf Werten: konform, teilweise konform, nicht konform, nicht anwendbar und nicht geprüft. Dazu kommen eine Checkliste zur Belegsammlung, Signale pro Säule und ausdrückliche Ehrlichkeitsregeln.
Diese Regeln sind der Kern. Jeder Status muss einen Beleg aus dem Repository zitieren, Punkte ohne Signal werden als nicht geprüft markiert statt geraten, und derselbe zugrunde liegende Sachverhalt muss über alle Säulen hinweg zum gleichen Ergebnis führen. Der dritte Teil, build_report.py, ist ein deterministisches Python-Skript, das die Bewertung in eine formatierte Arbeitsmappe rendert. Es validiert seine Eingabe: Unbekannte Kennungen oder ungültige Statuswerte brechen den Build ab. So gelangen halluzinierte Einträge nicht stillschweigend in ein Dokument, das später eine Freigabe trägt. Die Schnittstelle zwischen Denken und Darstellen ist ein einzelnes JSON-Dokument, was den Austausch einzelner Komponenten erleichtert.
Vom Repository zur Arbeitsmappe in sieben Schritten
Eine Prüfung beginnt mit einer einzigen Anweisung: Claude auf ein Repository zeigen und eine Well-Architected-Prüfung verlangen. Danach läuft ein festes Verfahren ab. Der Skill lädt seinen Datensatz, sammelt ausschließlich lesend Belege aus dem Zielrepository, also README, Architekturdokumentation, Infrastructure as Code, CI/CD-Workflows und Testsuites. Anschließend bewertet das Modell alle 150 Punkte gegen die gefundenen Belege und wendet dabei die Skala und die Ehrlichkeitsregeln an.
Im nächsten Schritt ruft es den Report-Generator auf, der Zeilenzahlen prüft und leere Statusfelder meldet. Zurück kommt eine Zusammenfassung der wichtigsten Hochrisikolücken. Die letzte Instanz ist menschlich: Prüfer validieren die Befunde, leiten daraus einen Sanierungs-Backlog ab und sammeln offene Systemfragen für ein gezieltes Gespräch mit AWS. Der Automatisierungsgewinn liegt nicht im Urteil, sondern in der Vollständigkeit und Nachvollziehbarkeit. Kein Mensch übersieht gerne 150 Punkte. Unter Zeitdruck passiert das trotzdem zuverlässig.
Den Prüfer prüfen: zwei Fixture-Repositories als Testgelände
Bevor sich das Team auf die Ausgabe verließ, wurde der Skill selbst bewertet. Dafür baute Smarsh zwei synthetische Fixture-Repositories: eine mittelreife Workload im LangGraph-Stil und einen absichtlich rauen Proof of Concept mit hartcodierten Zugangsdaten und einem Vorfall mit außer Kontrolle geratenen Kosten in der Historie. Beide wurden mit und ohne Skill geprüft und gegen acht überprüfbare Erwartungen je Fixture benotet: alle 150 Punkte vorhanden, keine leeren Status, Belege für jeden definitiven Status, ehrliche Kalibrierung und fixturespezifische Befunde wie die erkannten hartcodierten Credentials.
Mit dem Skill bestanden die Durchläufe 16 von 16 Erwartungen. Ohne ihn waren es 8 von 16, und die Ergebnisse bestanden aus ad hoc zusammengestellten Listen mit 18 bis 39 Punkten ohne jede Rückbindung an die Linse. Der Evaluationssatz liegt im Skill selbst, sodass Regressionstests bei jeder Weiterentwicklung möglich bleiben. Das ist der unspektakulärste, aber wichtigste Teil des Projekts: Ein Werkzeug, das Prüfungen automatisiert, muss gegen bekannte Fälle getestet werden. Sonst automatisiert es lediglich die eigene Betriebsblindheit.
Was die erste echte Prüfung ergab
Gegen die reale Workload las der Skill Architektur- und Authentifizierungsdokumentation, AWS-CDK-Definitionen, GitHub-Actions-Workflows, Designaufzeichnungen zu Registry und Gateway sowie die Testsuites und bewertete alle 150 Punkte in Stunden statt Tagen. Die Arbeitsmappe zeigte eine plausible Mischung aus Stärken und Lücken. Zu den Stärken zählten IAM-Ausführungsrollen pro Agent, begrenzt auf benannte Runtime-ARNs, sowie SigV4-signierte MCP-Aufrufe über das AgentCore Gateway. Erfasst wurden außerdem schema-validierte Eingaben mit typisierten Fehlerverträgen, exportierte Entscheidungs-Audit-Trails und kontinuierliche Qualitätsüberwachung über AgentCore Online-Evaluations.
Bei den Hochrisikolücken wurde es konkreter: Der Ingress-Authorizer des Gateways lief mit deaktivierter Authentifizierung unter einer dokumentierten Risikoakzeptanz, es gab keine Prüfung auf Prompt-Injection in von außen beeinflussbaren Nachrichteninhalten, Rate Limiting war als TODO vermerkt, und automatisierte Kostenkontrollen fehlten. Jede Lücke war mit dem Lens-Punkt, dem Beleg und einer empfohlenen Sanierung verknüpft. Danach kam das Engineering-Team dazu, validierte Status, akzeptierte oder bestritt Ergebnisse direkt in der Arbeitsmappe und priorisierte den Backlog. Dabei verschmolzen mehrere Punkte zu einem Epic für Anomalieerkennung, und ein Befund wurde hochgestuft, nachdem das Team auf einen Beleg verwies, den das Repository übersehen hatte: Dependency Scanning lief bereits bei jedem Pull Request.
Die Fragen, die kein Repository beantworten kann
Die Triage förderte eine Kategorie von Lücken zutage, die kein Quellcode beantwortet: Semantikfragen zu den AWS-Diensten selbst. Statt einen allgemeinen Architekturtermin zu buchen, baute das Team eine fokussierte Agenda für seine AWS Solutions Architects, in der jede Frage dem Prüfpunkt zugeordnet war, den sie schließen würde. Behandelt wurden die Haltbarkeit und Konsistenz der AgentCore Runtime als Speicher für Session-Checkpoints, das Retry- und Idempotenzverhalten der InvokeAgentRuntime-API und Break-Glass-Muster zum Anhalten von Agentenaufrufen.
Dazu kamen Muster für Amazon Bedrock Guardrails zur Filterung nicht vertrauenswürdiger Inhalte, Regeln für Penetrationstests gegen Amazon Bedrock AgentCore sowie die Abdeckung durch Amazon GuardDuty und AWS CloudTrail für die Erkennung von Bedrohungen auf agentischen Laufzeitumgebungen. So wurde aus einer allgemeinen Rücksprache eine Arbeitssitzung mit definiertem Fertigstellungskriterium. Ein Nebeneffekt: Sind Befunde präzise dokumentiert, wird auch die externe Unterstützung präziser. Niemand muss mehr raten, welche Frage offen ist.
Was das konkret bedeutet
Smarsh erwartet drei Effekte. Erstens: ein vollständiger, mit Belegen versehener Entwurf über 150 Punkte in Stunden statt Tagen, wobei die menschliche Zeit in Validierung und Priorisierung fließt. Zweitens: vergleichbare Prüfungen, weil jede Workload dieselbe standardisierte Arbeitsmappe erzeugt, was schnellere Sicherheitsfreigaben tragen soll. Drittens: eine schärfere Nutzung von AWS-Expertise, weil aus breiten Diskussionen punktuelle Arbeitssitzungen werden. Der Skill steht inzwischen im internen Plugin-Marketplace für den AI-SDLC und wurde bereits gegen ein zweites, architektonisch anderes agentisches Repository gefahren.
Die Übertragbarkeitsgrenzen sind für Praktiker in regulierten Umgebungen genauso wichtig wie die Ergebnisse. Die Linse liegt bislang nur als präskriptive Anleitung vor und ist im Well-Architected Tool nicht auswählbar. Jede Automatisierung darauf ruht also auf einem Dokument, dessen Extraktion fehlerhaft sein kann und deshalb gegengeprüft werden muss. Der Skill ersetzt kein Architektururteil und keine Freigabe. Er erzwingt Vollständigkeit, Belegpflicht und Gleichbehandlung gleicher Sachverhalte – drei Eigenschaften, die Prüfungen in der Compliance-Archivierung sonst mühsam und uneinheitlich machen. Wer agentische KI Workloads prüfen will, sollte zuerst das Protokoll standardisieren und erst danach automatisieren. Sonst skaliert man nur die Unschärfe.
Quelle: aws.amazon.com
