Radware stellte Agent Trust Management am 29. September 2026 vor. Das Unternehmen positioniert es als Weg, KI-Agenten zu identifizieren, erklaerte Absichten zu erfassen, Vertrauen laufend zu bewerten und zu kontrollieren, welche Anwendungsaktionen ein Agent ausfuehren darf. Radware sagt, das Produkt sei jetzt als Teil der Radware Cloud Application Protection Services verfuegbar.
Das ist eine KI-Sicherheitsnachricht, weil sich die Kontrollflaeche aendert. Viele Application-Security-Tools wurden fuer menschliche Nutzer, Bots, APIs und Fraud Scripts gebaut. KI-Agenten fuegen ein anderes Muster hinzu. Sie koennen im Auftrag eines Nutzers kommen, eine Seite navigieren, Optionen recherchieren, sich anmelden, Reisen buchen, einen Checkout abschliessen oder sensible Kontoworkflows nutzen. Jeden Agenten zu blockieren kann nuetzliche Automation verhindern. Jeden identifizierten Agenten zu vertrauen schafft offensichtliche Daten-, Betrugs- und Prozessrisiken.
Was Radware angekuendigt hat
Radware sagt, Agent Trust Management kombiniere prompt-aware, sessionbezogene Sichtbarkeit, Echtzeit-Identifikation, kontinuierliche Vertrauensbewertung und permission-basierte Governance. Das Produkt nutzt Request Header, clientseitiges Verhalten und direkte Agentenantworten, um standardkonforme und nicht standardkonforme Agenten zu identifizieren. Fuer Agenten mit Web Bot Auth sagt Radware, kryptografische Verifikation nutzen zu koennen.
Besonders wichtig ist die erklaerte Absicht. Radware sagt, das System erfasse aktiv, was ein Agent nach eigener Aussage tun will, und pruefe dann, ob spaeteres Verhalten damit konsistent bleibt. Das Unternehmen stellt klar, dass Identitaet allein kein Vertrauen beweist. Ein legitimer oder identifizierbarer Agent kann fehlgeleitet, kompromittiert oder fuer eine schaedliche Aufgabe genutzt werden.
Das Produkt kann anschliessend Berechtigungen auf konkrete Workflows anwenden. Radware nennt Beispiele wie Browsing erlauben, aber Login, Account-Erstellung oder Checkout einschraenken. Die distribuierte Pressemitteilung sagt, die Faehigkeit sei jetzt ueber Radware Cloud Application Protection Services verfuegbar.
Warum das wichtig ist
Agentenverkehr macht Application Security zu einem Task-Integrity-Problem. Eine klassische Bot-Control-Entscheidung fragt oft, ob ein Request automatisiert ist und ob diese Automation missbraeuchlich ist. Agentischer Verkehr stellt eine granularere Frage: Verdient dieser Agent in dieser Session fuer diesen angegebenen Zweck Zugriff auf diesen Workflow?
Dieser Unterschied ist wichtig fuer Commerce, Finance, Travel und jede Seite mit authentifizierten Kontoaktionen. Ein Agent, der ein Produkt recherchiert, ist risikoaermer als ein Agent, der gespeicherte Zahlungsdaten aendert, Treuepunkte nutzt, eine nicht erstattbare Reise bucht oder regulierte personenbezogene Daten einreicht. Dieselbe Agentenidentitaet kann fuer eine Aufgabe akzeptabel und fuer eine andere nicht akzeptabel sein.
Maetras Prompt-Injection-Kontrollen fuer KI-Agenten machen denselben Punkt aus Operator-Sicht. Der gefaehrliche Moment liegt oft zwischen Instruktion, Kontext, den der Agent sieht, und der folgenden Tool- oder Anwendungsaktion.
Was Kaeufer testen sollten
Security-Teams sollten fragen, wie Intent erfasst wird, wie oft er aktualisiert wird und welche Evidenz nach einer abgelehnten oder erlaubten Aktion bleibt. Erklaerte Absicht kann nuetzlicher Kontext sein, ist aber kein Beweis fuer gutartiges Verhalten. Die Kontrolle muss Intent mit Navigation, Datenzugriff, Tool-Nutzung, Risikosignalen und Business-Policy-Grenzen vergleichen.
Sie sollten auch testen, wie Policy auf Workflows gemappt wird. Eine praktische Implementierung braucht mehr als Allow und Block. Sie sollte Browse, Search, Compare, Login, Create Account, Checkout, Transfer, Cancel, Submit und Settings Change unterscheiden. Manche Aktionen koennen fuer authentifizierte Agenten sicher sein. Andere brauchen Step-up Controls, menschliche Bestaetigung oder Ablehnung.
Kaeufer sollten schliesslich Failure Handling pruefen. Wenn ein Agent sich nicht identifizieren kann, ein Intent-Gespraech verweigert oder die Aufgabe mitten in der Session aendert, sollte der sichere Default explizit und protokolliert sein.
Was unklar bleibt
Radwares Quellen beweisen keine Detection Accuracy, False-Positive-Raten, Evasion Resistance oder Kundenergebnisse. Das Unternehmen rahmt auch Marktzahlen aus eigener Threat Analysis, die als Anbieter-Kontext behandelt werden sollten, sofern sie nicht separat verifiziert sind.
Die aktuelle Evidenz stuetzt eine engere Schlussfolgerung: Radware macht Agenten-Intent und Workflow-Berechtigungen zu einem primaeren Application-Security-Control. Das ist ein nuetzliches Produktsignal, auch bevor unabhaengige Leistungsnachweise vorliegen.
Maetra-Analyse
Die Sicherheitslehre lautet, dass Agentenidentitaet notwendig, aber nicht ausreichend ist. Unternehmen muessen wissen, wer oder was der Agent zu sein behauptet, welchen Nutzer oder welche Organisation er vertritt, welche Aufgabe er angibt, welche Ressourcen er beruehrt, welche Aktion er versucht und ob diese Aktion zum autorisierten Scope passt.
Fuer Teams, die eigene Agenten betreiben, gilt intern dieselbe Struktur. Binden Sie Agenten an eine Aufgabe, inspizieren Sie Prompt und Tool Call, pruefen Sie Policy am Aktionspunkt und bewahren Sie Evidenz des Endeffekts. Fuer Teams, die Anwendungen Dritt-Agenten aussetzen, koennen intent-aware Permissions so wichtig werden wie Bot Detection und API Authorization.
Radwares Launch beweist nicht, dass der Markt Agent Trust geloest hat. Er zeigt, dass der Markt von der Frage, ob Traffic automatisiert ist, zur Frage wechselt, ob eine bestimmte automatisierte Aktion vertraut werden sollte.
Quellen
Primaerquelle: Radware Agent Trust Management Blog.
Bestaetigung: Radware Agent Trust Management Mitteilung auf GlobeNewswire.