Wie Tamnoon eine KI-gestützte Behebung von Cloud-Sicherheitslücken mit Amazon Bedrock aufgebaut hat

Kritische Cloud-Expositionsrisiken häufen sich schneller an, als Sicherheitsteams sie schließen können. Cloud-native Application Protection Platforms (CNAPP), Cloud-Anbieter und Posture-Scanner erzeugen mehr Fundstellen, als ein Team priorisieren kann, und das Risiko sammelt sich in der Lücke zwischen Erkennung und Behebung. Die meisten Fundstellen bleiben unangetastet – nicht, weil sie schwer zu beheben wären. Jemand muss den Kontext untersuchen, den Verantwortlichen ermitteln, bestätigen, dass die Behebung die Produktion nicht beeinträchtigt, und das Ganze dann in einem Volumen durchführen, das die Personalkapazität übersteigt.

In diesem Beitrag zeigen wir, wie Tamnoon Tami entwickelt hat, einen agentischen Cloud-Remediation-Orchestrator auf Amazon Bedrock, um diese Lücke zu schließen. Tami untersucht eigenständig Fundstellen, die aus CNAPP- und Cloud-nativen Quellen eingespeist werden, und bewertet, ob eine Behebung sicher ist. Anschließend generiert und orchestriert es die Behebung mit Schutzmaßnahmen und Governance, wo immer eine Änderung die Cloud eines Kunden berührt. Der Ansatz führte zu einer Reduzierung um mehr als 90 Prozent kritischer Cloud-Expositionsrisiken innerhalb von 90 Tagen ohne jegliche Produktionsprobleme.

Über Tamnoon

Tamnoon ist eine KI-gestützte Plattform zur Behebung von Cloud-Sicherheitslücken, die neben CNAPPs arbeitet. Sein KI-Assistent Tami hilft menschlichen Cloud-Sicherheitsexperten, Fehlkonfigurationen und Probleme in Kundenumgebungen bei AWS, Azure, Google Cloud und anderen Cloud-Anbietern zu untersuchen, zu priorisieren und sicher zu beheben.

Tamnoon integriert sich in die CNAPPs und Cloud-nativen Tools, die Teams bereits verwenden, und wandelt deren Fundstellen in validierte, produktionssichere Behebungen um. Der Großteil der Arbeit – einschließlich Untersuchung, Priorisierung und Behebungsplanung – findet statt, bevor etwas eine Live-Umgebung berührt, und genau das macht automatisierte Behebung in großem Maßstab vertrauenswürdig.

Herausforderungen bei der Behebung von Cloud-Sicherheitslücken

Ein Sicherheitstechniker kann Stunden damit verbringen, eine einzelne Fundstelle zu untersuchen. Oft lässt sie sich auf dieselbe Ursache wie Dutzende anderer Warnungen zurückführen.

• Das Warnungsvolumen überfordert die Personalkapazität: CNAPPs und Scanner erzeugen Tausende von Fundstellen. Teams können nicht alle priorisieren, sodass kritische Expositionsrisiken ungelöst bleiben, während sich das Risiko über Monate hinweg aufbaut.
• Die Untersuchung ist manuell und repetitiv: Jede Fundstelle erfordert die Zusammenstellung von Kontext – wem die Ressource gehört, was von ihr abhängt, ob die Behebung sicher ist. Das kostet Stunden der Zeit erfahrener Ingenieure, wiederholt bei jedem Element im Backlog.
• Angst vor Produktionsauswirkungen blockiert Automatisierung: Teams zögern, Behebungen zu automatisieren, weil sie es nicht riskieren können, die Produktion lahmzulegen. Ohne das Vertrauen, dass eine Behebung sicher ist, bewegt sich nichts.
• Reaktive Priorisierung: Ohne eine Möglichkeit, verwandte Fundstellen zu clustern oder das Vertrauen in Behebungen zu bewerten, arbeiten Teams Warnungen linear ab, statt Ursachen zu beseitigen, die viele Probleme gleichzeitig lösen.

Tamnoons Lösung deckt die gesamte Pipeline von der Aufnahme von Fundstellen bis zur validierten Behebung ab. Die Plattform betrachtet diese Herausforderungen als miteinander verbundene statt isolierte Probleme.

Lösungsübersicht

Tamnoon führt Sie von der ersten Fundstelle bis zur Ausführung der Behebung. Die Plattform nimmt Fundstellen von CNAPP-, Cloud Security Posture Management (CSPM)-Anbietern und anderen Sicherheitstools auf und normalisiert sie in ein einheitliches Schema. Anschließend reichert sie sie mit Asset- und Expositionskontext an und priorisiert sie. Von dort übernimmt die agentische Schicht mithilfe einer Reihe spezialisierter KI-Agenten, von denen jeder in einer ereignisgesteuerten, serverlosen Architektur auf AWS läuft, sodass jede Stufe unabhängig skaliert und sicher ausfällt.

Agentische Architektur auf Amazon Bedrock

Die Plattform delegiert Arbeit an vier spezialisierte Agenten, von denen jeder für eine bestimmte Phase der Behebungspipeline verantwortlich ist:

• Ein Untersuchungsagent stützt sich auf Training aus Millionen realer Kundenumgebungen in der Cloud, um Kontext zu ermitteln, und filtert diesen Kontext durch eine Validierungsschicht nach dem LLM-as-a-judge-Prinzip. Er schließt vom Behebungsziel, dem operativen Umfang und der cloudspezifischen Verifikation und erstellt schreibgeschützte Untersuchungsschritte sowie einen vollständigen Untersuchungsplan.
• Ein Sicherheitsbewertungsagent erstellt eine Beweiskette pro Asset und kombiniert automatisierte Verifizierungsergebnisse mit Analystenerkenntnissen. Er stuft die Behebung jeder Fundstelle als SAFE, RISKY oder AWAITING DATA ein – mit einer bewusst konservativen Tendenz. Im Zweifelsfall stuft er herab.
• Ein Behebungsagent wird nur für Fundstellen aktiviert, die der Sicherheitsagent als sicher eingestuft hat. Er schließt von Reihenfolge, Abhängigkeiten und Bedingungen und erstellt dann einen Behebungsplan, bei dem jeder Schritt einer Backup-, Remediate- und Verify-Struktur folgt und Rollback-Anleitungen enthält.
• Ein Codegenerierungsagent wandelt Planschritte in ausführbare Behebungen um, aber erst nachdem eine Eingabe-Schutzmaßnahme auf Relevanz und Prompt Injection geprüft hat. Jedes Artefakt durchläuft eine automatisierte Generate-and-Review-Schleife, in der ein separater Reviewer-Agent die Ausgabe genehmigen muss.

Warum Amazon Bedrock

Als das Tamnoon-Team sich daran machte, Tami zu bauen, würde die Wahl der Foundation-Model-Plattform (FM) alles prägen, was folgen sollte. Tamnoons Remediation-Agents verrichten nicht alle dieselbe Art von Arbeit. Einige führen tiefgehende, investigatives Reasoning durch, um die Grundursache eines Security-Findings zu verstehen. Andere übernehmen die Validierung in hohem Volumen und prüfen vorgeschlagene Korrekturen schnell und kostengünstig. Wieder andere prüfen generierten Code und wägen bei jeder Aufgabe Qualität gegen Kosten ab. Jede dieser Aufgaben dem richtigen Modell zuzuordnen, ohne für jede einzelne eine eigene Integration zusammenzusetzen, war eine Kernanforderung.

Genau diese Anforderung machte Amazon Bedrock zur natürlichen Wahl. Über eine einzige API kann jeder Agent das Foundation Model aufrufen, das am besten zu seiner Aufgabe passt. Die leistungsfähigsten Modelle übernehmen das anspruchsvollste Reasoning. Effizientere Modelle erledigen die repetitive Arbeit mit hohem Durchsatz. Auf Prüfungen spezialisierte Modelle optimieren den Kompromiss zwischen Ausgabequalität und Kosten. Da es eine einzige statt vieler Integrationen ist, können Modelle ausgetauscht oder aktualisiert werden, wenn sich die Landschaft weiterentwickelt, ohne die Architektur jedes Mal neu verdrahten zu müssen.

Ein weiterer Faktor bei der Entscheidung war der operative Aufwand bei Skalierung. Als das Anfragevolumen wuchs, wollte Tamnoon vermeiden, eigene Logik zu entwickeln und zu pflegen, um den Traffic über regionale Kapazitäten zu verteilen. Amazon Bedrock Cross-Region inference übernimmt dies automatisch. Es leitet Inference-Anfragen automatisch an die optimale AWS-Region innerhalb einer definierten geografischen Grenze weiter und hält den Durchsatz aufrecht, ohne dass benutzerdefinierter Routing-Code erforderlich ist.

Sicherheit war der letzte Gesichtspunkt, und für ein Cloud-Security-Unternehmen war sie nicht verhandelbar. Mit Bedrock läuft die Inference innerhalb von Tamnoons eigener AWS-Umgebung unter IAM-scope'd Berechtigungen von AWS Identity and Access Management (IAM). Sensible Kundendaten verlassen die Trust Boundary nie. Das gab dem Team die Gewissheit, dass die Plattform, auf der Tami basiert, denselben Standard erfüllt, den Tamnoon an seinen eigenen Dienst anlegt.

Wie Tamnoon sich in CNAPPs und Cloud-Security-Tools integriert

Tamnoon liegt nachgelagert zu den Detection-Tools, die Security-Teams bereits einsetzen. CNAPPs wie Wiz, CrowdStrike, Palo Alto Cortex, Upwind, SentinelOne, Orca und Cyera sowie Cloud-native Dienste wie AWS Security Hub und Amazon GuardDuty sind die Source of Truth dafür, was in der Umgebung nicht stimmt. Tamnoon verbindet sich über API-basierte Integrationen und normalisiert Findings in ein gemeinsames Format, sodass eine Fehlkonfiguration gleich aussieht, egal ob sie von Wiz oder GuardDuty stammt. Die Detection-Tools bleiben das Fundament. Tamnoon liefert die End-to-End-Remediation, die darauf folgt.

Für jedes Finding, an dem es arbeitet, weist Tami einen Remediation Confidence Indicator (RCI) von SAFE, RISKY oder AWAITING DATA zu. Diese Einstufung teilt den Teams mit, was automatisiert werden kann und was zuerst einer menschlichen Prüfung bedarf.

Abbildung 1: Tamnoon in Aktion

Tamnoon AWS-Architektur

Tamnoon läuft vollständig innerhalb seiner eigenen AWS-Konten, isoliert pro Umgebung. Nutzer greifen über einen einzigen sicheren Einstiegspunkt auf der Grundlage von Amazon API Gateway auf die Plattform zu, mit Verschlüsselung, die von AWS Certificate Manager verwaltet wird, und Anmeldung über Amazon Cognito. Alles hinter diesem Einstiegspunkt läuft in privaten Netzwerken über mehrere Availability Zones, sodass die Kernplattform niemals direkt dem Internet ausgesetzt ist.

Innerhalb dieser Umgebung kombiniert Tamnoon zwei Arten von Compute. Amazon Elastic Kubernetes Service (Amazon EKS) betreibt die stets verfügbaren Dienste hinter dem Dashboard, während AWS Lambda die ereignisgesteuerte Arbeit des Sammelns von Findings, deren Analyse und der Ausführung von Remediations übernimmt. Eine Reihe von AWS-Messaging- und Workflow-Diensten, darunter Amazon EventBridge, Amazon Simple Queue Service (Amazon SQS) und AWS Step Functions, koordiniert diese Schritte, sodass große Mengen von Findings zuverlässig und parallel verarbeitet werden, ohne dass ein einzelner fehlerhafter Datensatz den Rest blockiert.

Die AI-Schicht läuft auf Amazon Bedrock. Amazon Bedrock AgentCore, eine Plattform zum Erstellen, Verbinden und Optimieren von Agents in großem Maßstab mit beliebigen Frameworks oder Modellen, gibt Tamnoons Agents einen geregelten Weg, Aktionen auszuführen, statt uneingeschränkten Zugriff. Amazon Bedrock Guardrails prüfen anschließend sowohl die Anfrage als auch den generierten Code, bevor irgendetwas weitergeleitet wird. Unterstützende Dienste übernehmen den Rest der Plattform: verwaltete Datenbanken und Caching für State, Amazon Simple Storage Service (Amazon S3) für Playbooks und Artefakte sowie AWS Secrets Manager für Zugangsdaten, sodass sensible Schlüssel nie im Anwendungscode liegen.

Auf der Kundenseite ist alles links der AWS-Cloud-Grenze das, was Kunden in Tamnoon einbinden. Sie können ihre eigenen AWS-, Azure- und Google Cloud-Konten verknüpfen, die Security-Tools anschließen, aus denen ihre Findings stammen, und die Ziele verbinden, an die sie Ergebnisse ausgeliefert haben wollen, wie Slack, Jira, ServiceNow und GitHub.

Abbildung 2: Tamnoon AWS-Architektur

Wie Tamnoon null Produktionsprobleme aufrechterhält

Null Produktionsprobleme ist für Tamnoons Kunden eine Realität, und das ist kein Zufall. Autonomie bei Tamnoon ist in eine Defense-in-Depth-Sicherheitsarchitektur eingebettet, bei der jede Schicht davon ausgeht, dass die vorherige etwas übersehen könnte.

Es beginnt, bevor überhaupt ein Fix entworfen wird. Keine Remediation wird geschrieben, bevor eine unabhängige Sicherheitsbewertung, auf den Umfang fokussiert und bewusst vorsichtig ausgerichtet, zu dem Schluss kommt, dass die Änderung sicher vorgenommen werden kann. Von dort an zieht die Plattform eine harte Grenze zwischen Lesen und Schreiben. Untersuchungsschritte werden als streng schreibgeschützt validiert, sodass die Arbeit, ein Problem zu verstehen, es nie verändern kann. Nur der Remediation-Pfad darf etwas ändern, und jede Änderung, die er vornimmt, trägt ihre eigenen Schritte für Backup, Verifizierung und Rollback in sich.

Diese Disziplin wird durch ständige Selbstkritik verstärkt. Jeder Generierungsschritt ist mit einem Reflexionsschritt gekoppelt, der die Ausgabe prüft und seine Kritik in die Neugenerierung zurückspeist, sodass das System stets seine eigene Arbeit überprüft, anstatt sie blind zu vertrauen. Diese Empfehlungen werden auch auf dem Boden der Realität gehalten. Die Ausgabe des Agenten wird anhand von Automatisierungsergebnissen, Nutzerfeedback und Trainingsdaten aus real behobenen Alerts validiert, und wenn das Modell nicht selbst zu einem korrekten Ergebnis kommt, wird ein Mensch in den Prozess einbezogen.

Die letzte Sicherung erfolgt im Moment der Ausführung. Die KI besitzt niemals Cloud-Anmeldeinformationen. Stattdessen wird die Ausführung über kurzlebige, tenant-spezifische Anmeldeinformationen unter kundenseitig kontrolliertem Trust vermittelt, die in einer isolierten Umgebung laufen, getrennt von den Agenten, die die Arbeit planen. All dies wird von menschlicher Governance umrahmt: Remediations durchlaufen einen Genehmigungsworkflow mit vollständiger Audit-Trail-Aufzeichnung, und jede KI-Fähigkeit wird intern nachgewiesen, bevor sie überhaupt einen Kunden erreicht.

Datensicherheit und Compliance

Tami argumentiert über sensible Kundendaten: Alert-Payloads, Ressourcen-Identifikatoren, Fehlkonfigurationen und Remediation-Kontext. Diese Daten müssen innerhalb der AWS-Trust-Grenze bleiben, mit minimalen Berechtigungen laufen und auditierbar bleiben. Die Standardisierung auf Amazon Bedrock macht das möglich.

Sensible Inhalte bleiben innerhalb von AWS

Jeder Tami-Workload ruft Anthropic Claude auf Amazon Bedrock über die ChatBedrockConverse -Schnittstelle auf, anstatt einen LLM-Endpunkt eines Drittanbieters zu kontaktieren. Diese eine Entscheidung stellt die gesamte KI-Lieferkette unter einen einzigen AWS-nativen Service, was reale Konsequenzen für den Umgang mit Kundendaten hat. Die Inferenz läuft vollständig innerhalb von Tamnoons eigenem AWS-Konto in US-Commercial-Regionen, sodass Daten AWS niemals verlassen. Informationen zur Verfügbarkeit von Modellen nach Region finden Sie unter Supported models by AWS Region in Amazon Bedrock. Da Bedrock weder Prompts noch Vervollständigungen speichert oder zum Trainieren verwendet, gelangen Kundendaten von vornherein nie zu einem externen Anbieter.

Diese Grenze hält auch bei skalierenden Workloads. Die Bedrock Cross-Region-Inferenz leitet Anfragen automatisch an Regionen innerhalb der US-geografischen Grenze weiter und erhöht so den für die Anwendung verfügbaren Durchsatz. Die dahinterstehende Rechenleistung bleibt ebenfalls privat. Jeder Service läuft als AWS-Lambda-Funktion, die an eine Virtual Private Cloud (VPC) angebunden ist, in privaten Subnetzen mit expliziter Security Group, ohne öffentlichen Ingress und mit streng kontrolliertem Egress.

Absicherung dessen, was das Modell erreicht

Payloads können sensible Details enthalten, daher wendet Tami Amazon Bedrock Guardrails auf jede Anfrage und Antwort an. Die Richtlinie wird auf der Bedrock-Ebene durchgesetzt, was bedeutet, dass sie alle drei Services einheitlich abdeckt und keine Prompt-Logik einer einzelnen Funktion sie umgehen kann. Dieser einzige Durchsetzungspunkt erledigt mehrere Dinge gleichzeitig.

Erstens schützt er sensible Daten. PII und geheimnisähnliche Inhalte werden maskiert, bevor sie überhaupt persistiert oder angezeigt werden, sodass nichts Sensibles dort verweilt, wo es nicht hingehört. Er schützt außerdem vor Prompt-Injection, was wichtig ist, weil Tami über nicht vertrauenswürdige Befunde argumentiert, die ein unberechtigter Nutzer beeinflussen könnte. Die Filterung auf der Guardrail-Ebene verhindert, dass eine präparierte Payload das Modell kapert oder Kontext exfiltriert. Schließlich halten abgelehnte Themen und Inhaltsfilter die Ausgabe des Modells auf Sicherheits-Remediation beschränkt und nichts anderes. Jeder Eingriff wird zusammen mit AWS CloudTrail protokolliert, was Enterprise-Kunden eine klare Spur an Governance-Nachweisen liefert.

Zugriff nach dem Least-Privilege-Prinzip

Der Zugriff auf die gesamte Plattform läuft über eine dedizierte IAM-Ausführungsrolle pro Service, sodass jede Funktion nur das erreichen kann, was sie benötigt, und nichts darüber hinaus. Dieses Prinzip zeigt sich am deutlichsten darin, wie Tami auf Amazon Bedrock zugreift. Seine einzige Bedrock-Berechtigung ist bedrock:InvokeModel, beschränkt auf spezifische Inference-Profile- und Foundation-Model-ARNs. Es hat keine Möglichkeit, Modelle zu verwalten, zu trainieren oder zu exportieren.

Dieselbe Disziplin erstreckt sich auf jede andere Abhängigkeit. Der Zugriff auf AWS Secrets Manager ist auf die zwei Secrets beschränkt, die eine Funktion tatsächlich verwendet, der SQS-Zugriff ist auf seine eigene Eingabewarteschlange beschränkt, und Amazon-CloudWatch-Schreibvorgänge sind nach Namespace eingeschränkt. Es gibt im gesamten Design keine breiten, alles abdeckenden Rollen. Funktionen sind nur an die verwalteten AWSLambdaBasicExecutionRole - und AWSLambdaVPCAccessExecutionRole -Richtlinien angehängt, und nichts Weiteres.

Multi-Tenant-Isolation und Governance

Die Trennung der Mandanten ist eine grundlegende Anforderung und wird ab dem allerersten Aufruf durchgesetzt. Service-zu-Service-Aufrufe verwenden OAuth2-Client-Credentials über Cognito, pro Anwendung beschränkt, und die Arbeit wird einzeln pro SQS-Nachricht mit angehängtem Mandantenkontext verarbeitet. Dadurch berührt ein einzelner Aufruf niemals die Daten von mehr als einem Mandanten.

Ein Großteil dieser Gewährleistung ergibt sich daraus, dass die gesamte Plattform als Code behandelt wird. IAM-Richtlinien, Netzwerkplatzierung, Modell-IDs und Alarme leben alle in versionierten AWS-CloudFormation- und SAM-Templates, sodass jede Berechtigung und jede Modellversion in der Quellcodeverwaltung überprüfbar ist und es keine manuellen Konsolenänderungen gibt, die aus der Synchronisation geraten könnten. Modellversionen werden insbesondere auf datierte Bezeichner festgenagelt, zum Beispiel claude-sonnet-4-5-20250929, was bedeutet, dass eine Modelländerung immer eine explizite, überprüfte Codeänderung ist und kein stiller Upgrade.

Diese Transparenz setzt sich bis zur Laufzeit fort. Jeder Inferenzaufruf landet in AWS CloudTrail und ist der aufrufenden Rolle zurechenbar, und deterministisches Decoding mit auf null gesetzter Temperatur hält Scoring und Planung von einem Lauf zum nächsten konsistent. Die Fehlerbehandlung wird mit derselben Strenge geregelt. Jeder Service hat eine Eingabewarteschlange mit Redrive, eine Error-Handler-Funktion, eine Dead-Letter-Queue und CloudWatch-Alarme für Timeouts und DLQ-Tiefe, die mit dem Bereitschaftsdienst verdrahtet sind. Fehler werden eingedämmt und sind beobachtbar und werden niemals stillschweigend verworfen.

Ergebnisse und Auswirkungen

Tami hat mehr als 14 Millionen Cloud-Warnungen über die Kundenbasis von Tamnoon hinweg analysiert, eine Zahl, die im 2026 State of Cloud Remediation reportvon Tamnoon erfasst wird. Die Entscheidungen, die Tami trifft, spiegeln Muster wider, die aus diesen realen Umgebungen gelernt wurden.

Bei einem typischen Kunden zeigen sich die Ergebnisse schnell, in der Regel innerhalb von 90 Tagen.

Die Zahlen zur Kompression und zu null Problemen stammen aus der Forschung von Tamnoon. Das Muster ist konsistent und zeigt weniger offene Expositionen, deutlich weniger manuelle Arbeit und keine Ausfallzeiten durch die Behebungen selbst.

Fazit

Einen Agenten zu bauen, der über einen Cloud-Befund nachdenken kann, ist der unkomplizierte Teil. Einen zu bauen, dem man vertrauen würde, in der Produktion zu handeln, ist der schwierige Teil. Amazon Bedrock ist ein voll verwalteter Service, der Zugang zu leistungsstarken Foundation-Modellen bietet sowie die Werkzeuge zum Bau agentischer Anwendungen: Orchestrierung, Tool-Nutzung und Guardrails, über eine einzige API. Diese Kombination ist hier aus einem bestimmten Grund wichtig: Das Handeln auf Cloud-Infrastruktur in der Produktion erfordert sowohl starkes Reasoning als auch harte Sicherheitsgrenzen.

Vier Dinge machen das möglich:

• Ihre Expositionen werden tatsächlich geschlossen: Tamnoon arbeitet auf Live-Cloud-Infrastruktur, nicht auf Tickets oder Workflow-Automatisierung. Der Backlog wird kleiner statt sich seitlich zu verschieben.
• Autonomie skaliert ohne Produktionsrisiko: Jede vorgeschlagene Aktion trägt eine Konfidenzbewertung. SAFE-Aktionen können automatisch ausgeführt werden, während AWAITING DATA- oder RISKY-Aktionen die eingebetteten Cloud-Ingenieure von Tamnoon hinzuziehen.
• Läuft auf dem Stack, den Sie bereits gekauft haben: Tamnoon arbeitet auf beliebten CNAPPs und Cloud-Security-Tools auf. Jedes Erkennungstool, für das Sie bereits zahlen, rentiert sich schließlich, weil seine Funde endlich abgeschlossen werden.
• Teamkapazität skaliert ohne Wachstum: Die schnelle, sichere Einführung von Frontier-KI bedeutet mehr geschlossene Expositionen pro Analyst, ohne zusätzliche Stellen.

Nächste Schritte

Um mit einer ähnlichen Architektur zu beginnen, ziehen Sie Folgendes in Betracht:

• Entdecken Sie Amazon Bedrock und die darüber verfügbaren Modelle.
• Sehen Sie sich die Amazon Bedrock-Dokumentation an, um Ihre Architektur zu planen.
• Vereinbaren Sie eine Demo mit Tamnoon, um herauszufinden, wie viel Ihrer kritischen Cloud-Exposition Sie in den nächsten 90 Tagen schließen können.

Über die Autoren