Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Einen Attack Surface Management Agent mit AWS Bedrock bauen

By Matthias BaetensNov 14, 20256 min read

Diese Seite ist auch in English, Español, Français, Italiano, 日本語 und Português verfügbar.

Das Internet ist riesig – und es wächst unaufhörlich. Mitte 2025 umfasst es mehr als 1,25 Milliarden Websites und produziert jährlich rund 149 Zettabyte an Daten. Mehr als die Hälfte des gesamten Traffics geht inzwischen auf das Konto von Bots – viele davon mit bösartigen Absichten. Vor diesem Hintergrund war es noch nie so wichtig, Unternehmen beim Schutz ihres digitalen Footprints zur Seite zu stehen.

Bei DoiT haben wir gemeinsam mit einem auf Attack Surface Management (ASM) spezialisierten Kunden ausgelotet, wie sich Teile dieses Prozesses mit moderner KI automatisieren und skalieren lassen. Das Ziel: ein Agent, der das Web durchforstet, die exponierten Assets eines Kunden analysiert und potenzielle Schwachstellen identifiziert – komplett auf AWS.

Aufbau der Lösung

Wir haben ein System auf Basis von Amazon Bedrock und Strands Agents entworfen, das Reasoning-Modelle, Browser-Automatisierung, Retrieval-Augmented Generation und vollständige Observability für den Produktivbetrieb vereint.

Zu den zentralen AWS-Komponenten zählten:

Und so greifen sie ineinander:

Sehen wir uns die einzelnen Komponenten in den nächsten Abschnitten genauer an.

Reasoning-Modelle und Agent-Framework

Beginnen wir beim Fundament: wie der Agent "denkt". AWS Bedrock bietet unkomplizierten Zugang zu leistungsstarken Reasoning-Modellen – darunter Amazons Nova-Familie, die Claude-Modelle von Anthropic sowie zahlreiche Open-Source-Modelle wie Mistral, DeepSeek oder Llama. Diese Modelle beherrschen bereits Chain-of-Thought-Reasoning und können Zwischenschritte des "Denkens" durchlaufen, bevor sie Schlussfolgerungen ziehen und Aktionen auslösen. Diese Fähigkeit zum Reasoning ist entscheidend, denn jede Browsing-Aktion und jede Beobachtung baut auf der vorherigen auf.

Für die Orchestrierung liefert Strands Agents eine elegante Abstraktion über den Agent-Loop: im Kern ein Zyklus aus Reasoning, Tool-Nutzung und Antwortgenerierung. Das Framework integriert sich nahtlos mit Bedrock-Modellen und bringt produktionsreife Bausteine für Session-State, Multi-Agent-Koordination und Kontextmanagement mit.

Ein kleines Codebeispiel aus dem Agenten – damit Sie ein Gefühl dafür bekommen, wie einfach Strands die Entwicklung macht:

Dieser Loop erlaubt es dem Agenten, autonom zu browsen, die Erkenntnisse zu verarbeiten und den Zustand zwischen den Schritten zu persistieren.

Handeln über Tools und MCP

Reasoning allein reicht jedoch nicht – der Agent muss mit der Außenwelt interagieren.

Das Tooling haben wir über das Model Context Protocol (MCP) umgesetzt – einen offenen Standard, der LLMs mit externen Systemen verbindet. Jeder MCP-Server stellt einen Katalog von "Tools" mit klaren Definitionen und Schemata bereit, die der Agent zur Laufzeit dynamisch aufrufen kann.

Für unseren Use Case haben wir drei Tool-Quellen kombiniert:

  1. retrieve: für semantische Abfragen der Schwachstellendatenbank.
  2. Playwright MCP: für Web-Browsing und Interaktionen mit Websites.
  3. Filesystem MCP: für einfache persistente Speicherung und Logging.

Während der Entwicklung – im August 2025 – stellte AWS AgentCore vor, das ein eigenes Browser Tool mitbringt und uns den Betrieb einer eigenen Playwright-Infrastruktur erspart. Es bietet eine vollständig verwaltete, isolierte Browser-Umgebung mit IAM-Integration und CloudTrail-Observability – und ließ sich problemlos in den bestehenden Code einklinken:

Dank der Modularität von Strands war der Wechsel vom selbst gehosteten Browser-Tooling zu einem sichereren und besser skalierbaren Managed Service eine Sache von wenigen Handgriffen.

Grounding mit Bedrock Knowledge Bases

Damit der Agent mit realen Daten arbeiten kann, haben wir ihn an die CVE™ Program-Datenbank angebunden – ein Repository bekannter Schwachstellen.

Mit Amazon Bedrock Knowledge Bases haben wir den CVE-Datensatz hochgeladen; AWS hat ihn automatisch in Chunks zerlegt, eingebettet und in OpenSearch Serverless indiziert – fertig für Abfragen.

Über das Tool retrieve kann der Agent diesen Vector Store zur Laufzeit abfragen und so jederzeit aktuelles Wissen zu Schwachstellen für jedes angetroffene Kunden-Asset abrufen. Die verwaltete Ingestion- und Retrieval-Pipeline der Bedrock Knowledge Bases hat uns gegenüber einem komplett selbst gebauten RAG-Flow erheblichen Engineering-Aufwand erspart.


Den Agenten auf AWS deployen

Nach der lokalen Validierung des Prototyps haben wir die Lösung mit zwei Managed Runtimes in den Produktivbetrieb überführt:

1. AWS Fargate

Ein containerisiertes Deployment, paketiert mit Docker und orchestriert über AWS CDK. Dieses Setup gibt volle Kontrolle über Skalierung und Networking und eignet sich ideal, wenn Sie mehr Kontrolle brauchen oder spezielle Abhängigkeiten haben (etwa die MCP-Server).

2. Amazon Bedrock AgentCore

AgentCore bietet eine noch höhere Abstraktionsebene: Sie definieren den Agenten und seine Konfiguration – AWS übernimmt den Betrieb für Sie.

Mit wenigen Code-Anpassungen – im Wesentlichen der Umstellung vom Filesystem-Storage auf das Strands-State-System – lief derselbe Agent vollständig verwaltet, ganz ohne CDK- oder VPC-Konfiguration: einfach per agentcore configure und agentcore launch aus dem AgentCore Starter Kit. Für schnelle Iterationen und minimalen operativen Aufwand war dieser Ansatz unschlagbar.

Observability und Evaluation

Das Verhalten eines Agenten zu beobachten ist genauso wichtig wie sein Design.

Für Teams, die externe Analytics bevorzugen, ließ sich LangFuse mühelos über OpenTelemetry einbinden – mit einer fein granulierten Timeline aus Loops, Modellaufrufen und Tool-Aufrufen. Damit erhalten Sie einen detaillierten Schritt-für-Schritt-Einblick, was der Agent gerade "denkt" und welche Tools er einsetzt – entscheidend für Debugging und kontinuierliche Verbesserung.

Mit dem Launch von AgentCore wurde auch AgentCore Observability verfügbar; es integriert sich nahtlos mit CloudWatch, das inzwischen ein GenAI Observability Dashboard bietet und Traces, Metriken und Logs über jeden Aufruf hinweg erfasst. Entwickler können den Token-Verbrauch und Fehlerraten visualisieren und Sessions im Detail prüfen – aus der Black Box des LLM-Reasonings werden so messbare Daten.

Die Kosten Ihres Agenten mit DoiT Cloud Intelligence im Blick behalten

Eng verwandt mit Observability ist das Thema Kostenwirkung – auch sie sollte vor dem Produktiv-Deployment ganz oben auf der Agenda stehen.

Bei DoiT haben wir die GenAI Lens als Teil unserer DoiT Cloud Intelligence™-Plattform veröffentlicht – damit analysieren Sie die Ausgabenmuster Ihrer Generative-AI-workloads.

Die GenAI Lens bindet Amazon Bedrock ebenso direkt an wie Anthropic und OpenAI und zeigt Ihnen transparent, welche Modelle und workloads Ihre Kosten in die Höhe treiben.

Für tiefergehende Analysen können Sie mit DataHub die Daten-Ingestion direkt in Ihre Anwendung einbetten. Mit Labeling und individuellen Dashboards lassen sich Kosten pro Domain oder Kunde nachverfolgen – Sie können sogar die Kosten pro gefundener Schwachstelle berechnen und damit Security-Insights in messbaren ROI verwandeln.

Ein Blick nach vorn

Von Daten-Ingestion über Reasoning bis hin zu Observability – das AWS-Ökosystem lieferte alle Bausteine, um diesen autonomen ASM-Agenten zum Leben zu erwecken: sicher, skalierbar und mit minimalem Infrastrukturaufwand. Erst recht, seit AgentCore jetzt allgemein verfügbar ist.

Unsere Tests auf testphp.vulnweb.com haben gezeigt, dass das System Szenarien wie SQL Injection, Reflected und Stored XSS, Authentication Bypass und sogar eine aktive Site-Kompromittierung zuverlässig erkennt. Die Ergebnisse bestätigten: Der Agent kann Web-Flows autonom durchlaufen, Payloads einschleusen, Ausführungsbelege interpretieren und die Resultate gegen die CVE-Datenbank korrelieren – und das mit minimaler menschlicher Aufsicht. Über die rein technische Genauigkeit hinaus zeigte sich der Mehrwert der Kombination aus autonomem Reasoning, Echtzeit-Retrieval und Observability: Aus reinen Vulnerability-Scans werden strukturierte, nachvollziehbare Erkenntnisse.

Es bleibt noch viel Spielraum: das Reporting weiter ausbauen, die Performance an etablierten Benchmarks messen und zusätzliche Schwachstellendatenbanken anbinden. Doch schon in der heutigen Form zeigt das Projekt, wie AWS Bedrock + Strands Agents das Versprechen generativer KI in echten operativen Mehrwert für die Cybersicherheit überführen.

Den vollständigen Quellcode samt Implementierungsdetails finden Sie auf GitHub; eine Langfassung gibt es hier.

Machen wir Ihren FinOps-Weg gemeinsam einfacher: Sprechen Sie mit uns über doit.com/services!