Was sind LLM-Leitplanken?
LLM-Leitplanken sind technische Kontrollen, die das Verhalten von KI-gestützten Anwendungen in der Produktion einschränken. Anstatt das Modell selbst zu modifizieren, umwickeln Leitplanken das Modell mit Richtlinien, die regeln, was es sehen, sagen darf und was es bei jeder Anfrage tun darf.
Leitplanken funktionieren zur Inferenzzeit und werden von der Anwendung und der umliegenden Infrastruktur durchgesetzt. Sie validieren Eingaben, bevor Eingaben das Modell erreichen, inspizieren Ausgaben, bevor Antworten Nutzer erreichen, und kontrollieren den Zugriff auf Tools, APIs, Datenquellen und Cloud-Ressourcen streng.
Es ist wichtig, Leitplanken von anderen, verwandten Sicherheitsmechanismen zu unterscheiden:
Modellausrichtung (Trainingszeit): Ausrichtungstechniken wie Reinforcement Learning from Human Feedback (RLHF) prägen das Basisverhalten eines Modells während des Trainings. Das verbessert die allgemeine Sicherheit und Nützlichkeit, ist aber statisch und kennt nicht den Kontext oder die Richtlinien deiner Anwendung.
Anbieter-Inhaltsfilter (Service-Level): Cloud-Anbieter bieten integrierte Filter (zum Beispiel Azure OpenAI Content Filtering oder Amazon Bedrock Guardrails), die breite Inhaltskategorien wie Hassrede oder Gewalt blockieren. Diese arbeiten auf der API-Ebene und sind absichtlich generisch.
LLM-Leitplanken (Anwendungsebene): Leitplanken sind Kontrollen, die du entwirfst und konfigurierst, um sie durchzusetzen Deine Sicherheits- und Geschäftsregeln. Sie können je nach Nutzer, Rolle, Umgebung oder Anwendungsfall variieren und entwickeln sich weiter, wenn sich Ihre Anwendung verändert.
25 KI-Agenten. 257 echte Angriffe. Wer gewinnt?
Von der Zero-Day-Discovery bis zur Eskalation von Cloud-Privilegien haben wir 25 Agenten-Modell-Kombinationen an 257 realen offensiven Sicherheitsherausforderungen getestet. Die Ergebnisse könnten Sie 👀 überraschen
Diese Schichten ergänzen sich. Ausrichtung sorgt für Basissicherheit, Anbieterfilter blockieren häufig schädliche Inhalte und Leitplanken setzen anwendungsspezifische Sicherheits- und Zugriffskontrollen durch.
In der Praxis funktionieren LLM-Leitplanken wie Anwendungsebenen-Sicherheit für KI-Systeme. Sie setzen Richtlinien vor und nach der Modellinferenz durch und stellen sicher, dass das Modell innerhalb der durch Ihre Identitäten, Daten-Governance-Regeln und Cloud-Berechtigungen definierten Grenzen funktioniert.
Selbst verwaltete oder "sichere" LLMs benötigen Leitplanken. Ein gut ausgerichtetes Modell kann weiterhin durch Prompte Injektion oder durch falsch konfigurierte Identitäten übermäßigen Berechtigungen ausgesetzt. Effektive Leitplanken müssen daher geschichtet, kontextbewusst und eng in die umgebende Cloud-Umgebung integriert sein.
Warum LLM-Leitplanken für die Anwendungssicherheit entscheidend sind
In modernen Anwendungen sind LLMs keine isolierten Chat-Schnittstellen mehr. Sie sind direkt in die Anwendungslogik eingebettet, wo sie Benutzereingaben interpretieren, Daten abrufen, Werkzeuge aufrufen und nachgelagerte Aktionen auslösen. Infolgedessen werden Schwächen im LLM-Verhalten schnell zu Anwendungssicherheitsrisiken.
Eines der sichtbarsten Risiken ist die sofortige Injektion. Angreifer können Eingaben manipulieren, um Systeminstruktionen zu überschreiben oder unbeabsichtigtes Verhalten aus dem Modell zu extrahieren. Forschung zeigt, dass die Erfolgsraten je nach Modellarchitektur, Verteidigungstechniken und Angriffskomplexität stark variieren, was generalisierte Statistiken in der Praxis weniger nützlich macht. Wichtig ist, wie gut deine spezifischen Schutzplanken realistischen, mehrstufigen Angriffen in deiner Umgebung standhalten.
Datenleckage ist ein weiteres großes Problem. LLMs haben häufig Zugang zu internen Wissensdatenbanken, abruf-augmentierten Generierungsquellen oder sensiblen Betriebsdaten. Ohne starke Ausgabekontrollen kann ein Modell Informationen offenlegen, die das System niemals verlassen sollten. Eine einfache Frage wie "Was wissen Sie über unsere internen Systeme?" kann zu unbeabsichtigter Offenlegung führen, wenn die Leitplanken schwach oder schlecht abgegrenzt sind.
Tool-Calling und Funktionsausführung erhöhen die Einsätze erheblich. Wenn ein LLM API-Aufrufe auslösen, Datensätze ändern oder mit Cloud-Ressourcen interagieren kann, kann ein erfolgreicher Angriff reale Auswirkungen haben. Wenn die zugrundeliegende Service-Identität überprivilegiert ist, kann ein kompromittierter Agent auf weit mehr zugreifen als beabsichtigt. Die Durchsetzung von Least-Privileg-Berechtigungen begrenzt standardmäßig den Explosionsradius, sodass selbst missbrauchte Agenten keinen übermäßigen Schaden anrichten können.
Es ist auch wichtig, Zuverlässigkeitsfragen von Sicherheitsfragen zu trennen. Halluzinationen sind ein Zuverlässigkeitsproblem, bei dem das Modell falsche Informationen liefert. Unautorisierte Handlungen, Datenexponierung und Missbrauch von Privilegien sind Sicherheitsprobleme, die Schutzmechanismen verhindern sollen. Diese als dasselbe Risiko zu behandeln, führt zu fehlgeleiteten Kontrollen und falschem Selbstvertrauen.
Letztlich sind LLM-Leitplanken wichtig, weil KI-Systeme nun auf kritischen Vertrauensgrenzen liegen. Sie übersetzen nicht vertrauenswürdige Eingaben in vertrauenswürdige Aktionen. Ohne starke, geschichtete Leitplanken, die an Identität, Datenzugriff und Cloud-Berechtigungen gebunden sind, erweitern KI-Anwendungen die Angriffsfläche, anstatt sie zu kontrollieren.
Wo LLM-Leitplanken in einen modernen KI-Anwendungsstack passen
LLM-Leitplanken decken den gesamten KI-Anwendungsstack ab, anstatt in einem einzigen Kontrollpunkt zu leben. Um zu verstehen, wie sie zusammenarbeiten, hilft es, Leitplanken über fünf Schichten hinweg zu betrachten: Anwendung, API, Identität, Daten sowie Laufzeit und Infrastruktur.
Bei der Anwendungsschicht, Leitplanken prägen, wie Prompts und Antworten behandelt werden. Die Eingabevalidierung prüft Benutzereingaben auf bösartige Muster, während Antwortrichtlinien sicherstellen, dass die Ausgaben Formatierungs-, Sicherheits- und Offenlegungsregeln einhalten. Viele Teams beginnen hier mit prompten Steuerungen, die aber nur einen kleinen Teil des Gesamtrisikos abdecken.
Die API-Schicht regelt, wie Anwendungen mit LLM-Diensten interagieren. Schutzmechanismen auf dieser Ebene umfassen Authentifizierung, rollenbasierte Autorisierung, Ratenbegrenzung und Token-Nutzungsgrenzen. Dies sind vertraute Websicherheitskontrollen, werden aber besonders wichtig für KI-Endpunkte, bei denen eine einzelne Anfrage große Ressourcen beanspruchen oder nachgelagerte Aktionen auslösen kann.
Die Identitätsschicht konzentriert sich auf die Service-Konten und Rollen, die LLM-basierte Komponenten nutzen, um auf Cloud-Ressourcen zuzugreifen. Identitätsschutzmechanismen erzwingen den Least-Privileg-Zugriff, sodass KI-Agenten nur Aktionen ausführen können, die ihnen ausdrücklich erlaubt sind. Wenn die Identitätsberechtigungen zu weit gefasst sind, verlieren Anwendungsschutzmechanismen ihre Wirksamkeit.
Die Datenschicht kontrolliert, auf welche Datensätze, Einbettungen und Abrufquellen ein LLM zugreifen kann. Datenleitplanken definieren, welche Modelle welche Daten lesen können, wie sensible Informationen behandelt werden und wie der Abruf pro Benutzer oder Rolle gefasst wird. Diese Kontrollen sind entscheidend, um unbeabsichtigte Datenexposition durch Trainingspipelines oder die Generierung von Retrieval-Augmented zu verhindern.
Die Laufzeit- und Infrastrukturschicht deckt die Umgebungen ab, in denen KI-Dienste laufen, einschließlich Container, verwalteter LLM-Dienste und Netzwerkgrenzen. Leitplanken auf dieser Ebene umfassen Netzwerkisolation, Workload-Segmentierung und die Erkennung anomalen Verhaltens zur Laufzeit. Diese Steuerungen helfen, echte Angriffe zu fangen, die frühere Proben umgehen.
In der Praxis ist das Eigentum an diesen Schichten auf Teams verteilt. Anwendungsteams verwalten Prompts und Logik, Plattformteams verwalten APIs und Identitäten, und Cloud-Sicherheitsteams verwalten die Infrastruktur. LLM-Leitplanken erfordern Koordination über alle hinweg. Verteidigung in der Tiefe funktioniert nur, wenn Kontrollen über die Schichten hinweg ausgerichtet und konsequent durchgesetzt werden.
Spickzettel für Best Practices für die Sicherheit von GenAI
Dieser Spickzettel bietet einen praktischen Überblick über die 7 Best Practices, die Sie anwenden können, um die GenAI-Sicherheitslage Ihres Unternehmens zu stärken.
Kernarten von LLM-Leitplanken (und was sie tatsächlich schützen)
Die meisten LLM-Leitplanken fallen in eine kleine Anzahl von Kategorien. Jeder schützt einen anderen Teil des Systems und hat klare Grenzen. Das Verständnis dieser Grenzen ist entscheidend, denn kein einzelnes Geländer kann jeden Angriff allein stoppen.
Eingangsleitplanken
Eingabe-Leitplanken befinden sich zwischen Benutzer und Modell. Ihr Ziel ist es, bösartige oder unsichere Prompts zu erkennen und zu blockieren, bevor sie das LLM erreichen. Gängige Techniken sind Musterabgleich, prompte Klassifikation und Durchsetzung von Instruktionsgrenzen.
Eingabe-Schutzplanken können offensichtliche Angriffe stoppen, lassen sich aber leicht durch Codierung, indirekte Phrasierung oder mehrrundige Gespräche umgehen. Daher sollten sie als früher Filter und nicht als primäre Verteidigungslinie behandelt werden.
Ausgangsleitplanken
Ausgabe-Leitplanken inspizieren Modellantworten, bevor sie an die Nutzer zurückgegeben werden. Sie setzen Regeln durch, wie das Entfernen sensibler Daten, das Blockieren verbotener Themen oder die Verpflichtung strukturierter Ausgabeformate.
Diese Kontrollen helfen, unbeabsichtigte Datenlecks zu reduzieren, hängen jedoch von der Erkennungsgenauigkeit ab. Neuartige Angriffstechniken oder subtile Datenexposition können durchrutschen, besonders wenn die Ausgaben lang oder dynamisch generiert sind.
Werkzeug- und Funktionsleitplanken
Tool- und Funktionsleitplanken steuern, welche Aktionen ein LLM ausführen kann, wenn es externe APIs aufrufen oder Code ausführen darf. Hier verlagert sich das KI-Risiko von theoretisch zu operativ.
Effektive Kontrollmechanismen umfassen:
Aktionszuellisten pro Rolle
Definiere, welche Werkzeuge jede Rolle aufrufen darf. Das LLM eines Support-Agenten kann in der Dokumentation suchen oder Tickets erstellen, sollte aber niemals Abrechnungsdaten ändern oder Konten löschen.Vorausführungsrichtlinienprüfungen
Validiere jeden Toolaufruf vor der Ausführung. Bestätigen Sie, dass der Benutzer eine Berechtigung hat, die Aktion im aktuellen Kontext erlaubt ist und die Anfrage keine Geschäftsregeln oder Ratenbeschränkungen verletzt.Menschliche Genehmigung für risikoreiche Maßnahmen
Erfordern explizite menschliche Bestätigungen für destruktive oder sensible Operationen wie Datenlöschung, Finanztransaktionen oder Privilegienänderungen.Anwendungsbereich und Durchsetzung von Privilegien
Stellen Sie sicher, dass Toolaufrufe die Berechtigungen der zugrundeliegenden Dienstidentität nicht überschreiten dürfen. Wenn das LLM unter einer schreibgeschützten Identität läuft, darf es keine Schreiboperationen auslösen können, selbst wenn das Modell diese vorschlägt.Mehragenten-Grenzkontrollen
Wenn mehrere Akteure interagieren, setze strenge Grenzen zwischen ihnen. Ein kundenorientierter Agent darf nicht direkt administrative Tools eines anderen Agenten ohne ausdrückliche Genehmigung und Validierung aufrufen.
Werkzeug-Leitplanken verringern das Missbrauchsrisiko, aber sie versagen, wenn Service-Identitäten überprivilegiert sind. Das macht Identitätskontrollen genauso wichtig wie Anwendungslogik.
Identitäts- und Genehmigungsschutzgeländer
Identity Guardrails steuern die Cloud-Rollen und Servicekonten, die von LLM-betriebenen Komponenten verwendet werden. Ihr Ziel ist es, den Zugang mit minimalem Privilegrecht durchzusetzen, sodass KI-Dienste nur die Ressourcen erreichen können, die sie wirklich benötigen.
Diese Leitplanken begrenzen den Explosionsradius, wenn etwas schiefgeht, sind aber in realen Umgebungen häufig falsch konfiguriert. Übermäßige Berechtigungen können selbst gut gestaltete Anwendungskontrollen still und still untergraben.
Datenzugriffsleitplanken
Datenleitplanken steuern, auf welche Datensätze, Embeddings und Abrufquellen ein Modell zugreifen kann. Sie verhindern, dass sensible Informationen ohne ordnungsgemäße Genehmigung in Aufforderungen oder Antworten eingebunden werden.
Diese Kontrollen basieren auf genauen Datenklassifizierungs- und Zugriffsrichtlinien. Wenn Daten falsch gekennzeichnet sind oder Zugriffsregeln zu weit gefasst sind, verlieren die Schutzmechanismen an Wirksamkeit.
Laufzeit-Leitplanken
Laufzeit-Leitplanken überwachen, was tatsächlich in der Produktion passiert. Sie analysieren das Verhalten über API-Aufrufe, Identitätsaktivitäten und Cloud-Telemetrie, um Anomalien und Missbrauch zu erkennen.
Laufzeiterkennung hilft, Umgehungen zu erkennen, die früheren Kontrollen entgehen, erfordert aber Baselines und Abstimmung, um Fehlalarme zu reduzieren. In Kombination mit Kontext zu Identitätsberechtigungen und Datensensitivität werden Laufzeitsignale deutlich handlungsfähiger.
LLM-Sicherheits-Best Practices [Spickzettel]
Diese 7-seitige Checkliste bietet praktische, implementierungsfertige Schritte, die Sie bei der Sicherung von LLMs über ihren gesamten Lebenszyklus hinweg unterstützen und auf reale Bedrohungen abbilden.
Implementierung von LLM-Leitplanken in Cloud-Umgebungen
Der Übergang von einem Prototyp zu einer Serien-KI-Anwendung erhöht die Komplexität der Leitplankenimplementierung erheblich. Wo und wie Modelle in der Cloud laufen, beeinflusst direkt, wie effektiv diese Kontrollen sind.
Managed LLM-Dienste bieten nützliche Basisschutzmaßnahmen, beseitigen jedoch nicht die Notwendigkeit von Anwendungs- und Cloud-Sicherheitskontrollen. Azure OpenAI unterstützt Netzwerkisolation durch Azure Private Link using Private Endpoints, zusammen mit verwalteten Identitäten zur Authentifizierung. Amazon Bedrock bietet eingebaute Leitplanken, die über grundlegende Inhaltsfilterung hinausgehen, einschließlich abgelehnter Themen, kontextuellen Erdungschecks und Halluzinationserkennung mittels automatisierter Logik. Google Vertex AI bietet Inhaltssicherheitsfilter und integriert sich mit VPC Service Controls, um die Datenexfiltration zu begrenzen.
Vertex AI Security Best Practices Best-Practice-Spickzettel
Entdecken Sie das Vertex AI Security Best Practices Cheat Sheet, einen praktischen Leitfaden zur Sicherung von KI-Workloads mit klaren Empfehlungen, echten Kontrollen und umsetzbaren Schritten, die Sie sofort umsetzen können.
Diese verwalteten Funktionen verringern bestimmte Risikoklassen, aber kritische Entscheidungen bleiben in der Verantwortung des Kunden. Teams kontrollieren weiterhin die Netzwerkexposition, Identitätsberechtigungen, Datenzugriffsrichtlinien und Protokollkonfigurationen. Cloud-native steuert sicher Wie Der Dienst wird zwar genutzt, aber sie adressieren nicht vollständig Wie sich das Modell verhält innerhalb eines Antrags. Risiken wie Prompt Injection, Werkzeugmissbrauch und Logikmissbrauch müssen weiterhin auf der Anwendungsebene über individuelle Leitplanken bewältigt werden.
Dies erzeugt ein Modell der geteilten Verantwortung zwischen dem Cloud-Anbieter und dem Anwendungsbesitzer. Anbieter sichern die zugrundeliegende Plattform und bieten Basisschutzmaßnahmen, während die Kunden für die Durchsetzung unternehmensspezifischer Richtlinien, minimalen Privilegienzugangs und kontextuellen Schutzmechanismen verantwortlich sind.
Multi-Tenant- und Shared Cloud-Umgebungen bergen zusätzliche Risiken. Ein einzelnes falsch konfiguriertes VPC, ein öffentlich zugänglicher KI-Endpunkt oder eine zu breite IAM-Rolle kann Anwendungsrichtlinien stillschweigend schwächen, ohne dass die Modelllogik geändert wird.
Cloud-Fehlkonfigurationen sind ein häufiger Schwachpunkt. Wenn KI-Dienste dem Internet zugänglich gemacht oder unter hochprivilegierten Identitäten betrieben werden, können Angreifer die prompte Validierung und Werkzeugkontrollen vollständig umgehen, indem sie die zugrunde liegenden Cloud-APIs missbrauchen. In diesen Szenarien können Leitplanken während der Tests wirksam erscheinen, bieten aber in der Produktion kaum einen wirklichen Schutz.
Leitplankendrift ist eine weitere Herausforderung. Steuerungen, die in Entwicklungs- oder Staging-Umgebungen vorhanden sind, können in der Produktion aufgrund von Notfalländerungen, neuen Pipelines oder Infrastruktur-Updates geschwächt oder entfernt werden. Mit der Zeit schafft diese Drift Lücken, die Angreifer ausnutzen können.
Die Aufrechterhaltung effektiver Leitplanken erfordert eine kontinuierliche Validierung über den gesamten Lebenszyklus. Kontrollen müssen von der Entwicklung bis zur Bereitstellung und Laufzeit konsequent durchgesetzt werden. Die Integration von Leitplankenkontrollen in CI- und CD-Pipelines hilft, Fehlkonfigurationen zu erkennen, bevor sie in die Produktion gelangen.
Verteidigung in der Tiefe funktioniert nur, wenn Anwendungsebene-Schutzmechanismen, Identitätsberechtigungen, Datenzugriffsrichtlinien und Infrastrukturkontrollen im Laufe der Systementwicklung übereinstimmen. Cloud-native Schutzmaßnahmen werden verstärkt KI-Sicherheit, ersetzen aber nicht den Bedarf an robusten, anwendungsspezifischen Leitplanken, die das Modellverhalten direkt adressieren.
Warum LLM-Leitplanken versagen und wie Angreifer sie umgehen
Selbst gut gemeinte Leitplankeneinsätze scheitern oft unter realem Druck. Zu verstehen, wie Angreifer Kontrollen umgehen, ist entscheidend, um Leitplanken zu entwerfen, die in der Produktion bestehen.
Prompt Injection bleibt die sichtbarste Schwäche. Angreifer verlassen sich selten auf eine einzige bösartige Aufforderung. Stattdessen verwenden sie Mehrrunden-Interaktionen, Rollenmanipulation und indirekte Befehle, die nach und nach die Systemintention übersteuern. Leitplanken, die nur einzelne Hinweise bewerten, übersehen diese Muster oft, sodass schädliches Verhalten im Laufe der Zeit entstehen kann.
Echte Malware-Kampagnen haben begonnen, zu erforschen, wie man Prompts in bösartige Payloads einbetten kann, um das Laufzeitverhalten zu steuern. Zum Beispiel gilt die LameHug Malware sandte base64-codierte Eingaben an ein LLM und forderte Systemaufklärungsbefehle an, um Informationen über den infizierten Host zu sammeln. In diesen Fällen interagierte das Modell nicht mit einem Benutzer, sondern wurde aus einer kompromittierten Umgebung heraus aufgerufen und umging damit effektiv benutzerorientierte Eingabesperren.
Eine übermäßige Abhängigkeit von Ausgangsfiltern ist ein weiterer häufiger Fehler. Filter, die Antworten auf verbotene Inhalte scannen, können durch Codierung, Verschleierung oder durch Auslösen schädlicher Aktionen umgangen werden, ohne offensichtlich gefährlichen Text zu erzeugen. In vielen Fällen treten die schädlichsten Ergebnisse auf, wenn das Modell eine Aktion erfolgreich ausführt, anstatt wenn es problematische Sprache erzeugt.
Werkzeug- und Funktionsmissbrauch ist subtiler, aber oft gefährlicher. In der Amazon Q Developer Extension Kompromiss, Angreifer fügten Eingabeaufforderungen ein, die einen KI-Agenten ausdrücklich anwiesen, alle ihm zugänglichen Dateien und Cloud-Ressourcen zu löschen. Obwohl der Angriff letztlich nicht erfolgreich war, zeigt er, wie böswillige Akteure mit Guardrail-Bypass-Techniken experimentieren, die Werkzeugaufrufe und externe Ausführungskontexte nutzen.
Übermäßige Identitätsberechtigungen untergraben häufig ansonsten solide Leitplanken. Wenn ein LLM unter einer Service-Identität mit weitreichenden Cloud-Berechtigungen arbeitet, kann ein Angreifer, der Einfluss auf das Modell erlangt, Anwendungskontrollen umgehen und direkt mit Cloud-APIs interagieren. In diesen Fällen bieten schnelle Leitplanken wenig Schutz, da die eigentliche Schwäche im Identitäts- und Zugriffsmanagement liegt.
Driften zwischen Umgebungen sind ein weiteres wiederkehrendes Problem. Steuerungen, die sorgfältig in Entwicklungs- oder Staging-Umgebungen implementiert werden, werden in der Produktion oft durch Notfallbehebungen, neue Integrationen oder nicht dokumentierte Änderungen geschwächt. Dies schafft blinde Flecken, die Angreifer lange nach Abschluss der ersten Sicherheitsüberprüfungen ausnutzen können.
Infrastrukturebene kann Anwendungsschutzmechanismen vollständig umgehen. Für selbstgehostete Modelle können öffentlich zugängliche Recheninstanzen Metadatendienste oder Zugangsdaten offenlegen, sodass Angreifer sensible Daten extrahieren und Rechte eskalieren können. Für verwaltete KI-Dienste ermöglichen falsch konfigurierte öffentliche Endpunkte oder schwache Netzwerksteuerungen direkte API-Missbrauch ohne jemals die Anwendungsebene zu berühren.
In diesen Szenarien zeichnet sich ein konsistentes Muster ab. Leitplanken sind notwendig, aber sie allein reichen nicht aus. Echte Missbrauchsmuster, wie sie in jüngsten Malware-Kampagnen mit KI-aktivierenden Nutzlasten beobachtet wurden, zeigen, dass Angreifer bereits mit Wegen experimentieren, promptzentrierte Verteidigungen zu umgehen. Ohne Verstärkung durch cloudnativen Sicherheitskontrollen, die Identität, Datenzugriff und Infrastrukturexposition steuern, schaffen Leitplanken ein falsches Sicherheitsgefühl statt echten Schutzes.
Wie Wiz hilft, KI-Anwendungen über Leitplanken hinaus zu sichern
LLM-Leitplanken definieren, wie KI-Anwendungen funktionieren Angeblich sich zu verhalten, aber sie garantieren nicht, dass diese Kontrollen in realen Cloud-Umgebungen funktionieren, in denen Bedrohungen mit Identitäten, Daten und Infrastruktur interagieren. Wiz verstärkt die Leitplanken, indem es die gesamte KI-Angriffsfläche durch kontinuierliche Sichtbarkeit, Risikobewertung und kontextreiche Verteidigung sichert.
Wiz's KI-Sicherheitshaltungsmanagement (AI-SPM) erweitert seine agentenlose CNAPP Foundation zur Inventarisierung aller KI-Agenten, Modelle, Endpunkte und zugehörigen Dienste in Cloud und SaaS. Dazu gehört ein KI-Stückliste und ein Agenteninventar-Ansicht Das zeigt, wo Agenten laufen, welchen Zugang sie haben und wie sie sich mit sensiblen Arbeitslasten und Daten verbinden. Außerdem werden die Expositionen mit tatsächlichen Cloud-Identitäten und Ressourcen per Wiz Security Graph abgebildet, sodass Teams nicht nur sehen können, was existiert, sondern was zählt.
Die Plattform validiert kontinuierlich sichere Konfigurationen über KI-Dienste wie Azure OpenAI, Amazon Bedrock und Google Vertex AI hinweg, einschließlich der Überprüfung von Anbieter-Schutzmechanismen, Identitätsrichtlinien und Kontrollen für sensible Daten. Dies hilft, Fehlkonfigurationen und fehlende Schutzmaßnahmen zu erkennen, die sonst die Anwendungsleitplanken in der Produktion schwächen würden.
Schließlich korreliert Wiz Laufzeitaktivitäten und Bedrohungssignale mit Cloud-Kontexten, um verdächtiges Agentenverhalten zu erkennen, potenzielle Angriffspfade zu verfolgen und Reaktionsaktionen zu automatisieren. Indem dies mit Identitätsberechtigungen, Datensensitivität und Infrastruktur-Exposition verknüpft wird, können Teams die Behebung basierend auf realer Ausnutzbarkeit statt theoretischer Lücken priorisieren.
