Obsidian Security führt eine Laufzeit-Richtlinien-Engine ein, um die Aktionen von KI-Agenten zu kontrollieren

Obsidian Security hat eine Laufzeit-Engine zur Richtlinienentscheidung eingeführt, mit der Unternehmen steuern können, was KI-Agenten in Geschäftsanwendungen tun, bevor eine Aktion ausgeführt wird. Mit der Ankündigung erweitert das Unternehmen seine Plattform für Agentensicherheit um einen MCP Security Proxy, eine Policy Decision API sowie eine größere Abdeckung von Programmiertools und Agenten, die in Software von Drittanbietern eingebettet sind.

Die Einführung zielt auf ein Problem ab, das sich mit herkömmlichen Zugriffskontrollen nicht vollständig lösen lässt: Ein Agent kann über gültige Anmeldedaten verfügen und eine zugelassene Anwendung nutzen, dabei aber trotzdem versuchen, eine unangemessene Aktion auszuführen. Die Berechtigung, Kundendaten zu lesen, bedeutet beispielsweise nicht zwangsläufig, dass diese auch an ein externes Ziel exportiert werden dürfen.

Obsidian bewertet die vorgeschlagene Aktion anhand zentral verwalteter Richtlinien. Dabei berücksichtigt das Unternehmen die Person, die hinter dem Agenten steht, deren Beschäftigungsverhältnis und Berechtigungen, die betreffende Anwendung sowie vom Kunden bereitgestellte Datenklassifizierungen. Angeschlossene Durchsetzungspunkte können die Aktion dann zulassen oder blockieren oder, sofern diese Funktion unterstützt wird, eine Genehmigung verlangen.

Von der Erkennung von Agenten zur Kontrolle ihrer Aktionen

Die Erkennung von Agenten zeigt, welche Tools vorhanden sind und worauf sie zugreifen können. Durch Governance lassen sich unnötige Berechtigungen reduzieren oder riskante Konfigurationen erkennen. Die Laufzeitrichtlinie beantwortet die noch offene Frage: Was darf ein ansonsten autorisierter Agent genau jetzt tun?

Obsidian behandelt in seiner Ankündigung sowohl von Mitarbeitenden betriebene Agenten als auch Agenten, die in bereits im Unternehmen genutzter Software enthalten sind. Zu den erweiterten Funktionen für Erkennung und Governance gehören Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow und Workday.

Dabei handelt es sich um unterschiedliche Kontrollpunkte. Einen Agenten in einer SaaS-Anwendung zu finden, bedeutet nicht automatisch, dass jede Aktion in dieser Anwendung abgefangen wird. Die Durchsetzung von Richtlinien zur Laufzeit hängt von der unterstützten Integration und dem Punkt ab, über den eine Aktion ausgeführt wird.

Das Unternehmen hat außerdem die Unterstützung von Laufzeitrichtlinien für OpenAI Codex ergänzt, zusätzlich zu den bereits vorhandenen Kontrollen für Programmieragenten. In seiner Ankündigung weist es auf Risiken wie destruktive Befehle, die Offenlegung von Anmeldedaten und Lesezugriffe außerhalb des vorgesehenen Projektumfangs hin – Aktionen, die während einer ansonsten legitimen Entwicklungssitzung auftreten können.

Der Knowledge Graph liefert den fehlenden Kontext

Ein Gateway kann eine Anfrage prüfen, doch die Anfrage allein erklärt möglicherweise nicht, welche Befugnisse dahinterstehen. Für eine fundierte Sicherheitsentscheidung kann es erforderlich sein zu wissen, ob das aufrufende Konto einer angestellten oder externen Person gehört, ob das Beschäftigungsverhältnis beendet wurde und über welche Berechtigungen das Konto in der Zielanwendung tatsächlich verfügt.

Obsidian verknüpft mit seiner Knowledge-Graph-Architektur Personen, Konten, Anwendungen, Token, Berechtigungen und deren Beziehungen. Das Unternehmen beschreibt, wie Informationen aus Verwaltungs-APIs, Aktivitätsströmen und Integrationen in einem gemeinsamen Modell normalisiert werden. Versionierte Entitäten und Beziehungen halten dabei Veränderungen im Zeitverlauf fest.

Diese Struktur erleichtert es, Zugriffe über mehrere Systeme hinweg nachzuverfolgen, statt jedes Konto isoliert zu betrachten. Die scheinbare Rolle eines Agenten kann eng umrissen sein, während ein Token oder eine geerbte Berechtigung ihm andernorts weiter reichende Zugriffsmöglichkeiten verschafft. Werden diese Beziehungen miteinander verknüpft, kann die Richtlinien-Engine fundierter beurteilen, ob eine bestimmte Aktion den Regeln der Organisation entspricht.

Kunden können eigenen Kontext hinzufügen, darunter Klassifizierungskennzeichnungen. So kann eine Richtlinie zwischen einer gewöhnlichen Datei und einer Datei unterscheiden, die das Unternehmen als hochsensibel einstuft, statt sich ausschließlich auf die allgemeine Definition vertraulicher Daten eines Sicherheitsanbieters zu stützen.

Wie aus der Entscheidung eine Durchsetzung wird

Die Architektur trennt die Entscheidung von ihrer Umsetzung. Wie Obsidian in seiner Erläuterung zur Laufzeit-Engine beschreibt, hält ein Durchsetzungspunkt einen vorgeschlagenen Vorgang an, übermittelt dessen Einzelheiten zur Bewertung und setzt anschließend die zurückgegebene Entscheidung samt Begründung um.

Die neue Richtlinienentscheidungs-API erweitert dieses Modell auf von Kunden betriebene Gateways, Agenten-Umgebungen und Workflows. Unternehmen können ihre bestehende Infrastruktur beibehalten und Obsidian zugleich um eine kontextbezogene Entscheidung bitten. Die Durchsetzungskomponente des Kunden muss diese Entscheidung dann umsetzen, bevor der Vorgang fortgesetzt wird.

Obsidian dokumentiert außerdem einen Flag-Modus, mit dem sich Richtlinienübereinstimmungen anhand des tatsächlichen Datenverkehrs testen lassen, bevor Vorgänge blockiert werden. Entscheidungsprotokolle erfassen den Agenten, die aufrufende Person, das Tool, die Argumente, das Ergebnis und die zutreffende Richtlinie. So können Sicherheitsteams untersuchen, warum eine Aktion zugelassen oder gestoppt wurde.

Die Unterstützung von Genehmigungen ist enger gefasst als die allgemeine Architektur zum Zulassen oder Blockieren: Laut der aktuellen Dokumentation des Unternehmens lässt sich eine Genehmigung derzeit für Claude Code-Richtlinien verlangen, die vor einem Vorgang ausgeführt werden. Bei der Gestaltung von Kontrollen für eine vielfältige Agentenlandschaft kommt es daher auf die Funktionen der jeweiligen Integration an.

Der MCP-Proxy hält Anwendungstoken von KI-Clients fern

Der MCP-Sicherheitsproxy steuert die Verbindungen zwischen KI-Clients und unterstützten Geschäftsanwendungen. Das Model Context Protocol, kurz MCP, bietet Agenten eine standardisierte Möglichkeit, Tools aufzurufen, die von externen Servern bereitgestellt werden. Obsidian schaltet eine Richtlinienprüfung zwischen den Client und den MCP-Server der Anwendung.

In der Produktdokumentation wird beschrieben, wie die direkte MCP-URL des Anbieters durch einen von Obsidian kontrollierten Endpunkt ersetzt wird. Nutzer autorisieren den Zugriff über den Zustimmungsprozess des Anwendungsanbieters; der KI-Client erhält ein vom Proxy ausgestelltes Token, anstatt das Zugriffstoken der Anwendung selbst zu speichern.

Der Proxy ordnet eine Sitzung dem Nutzer, dessen Anwendungskonto und dem jeweiligen Mandanten zu, etwa einer bestimmten Salesforce-Organisation oder einem bestimmten Arbeitsbereich. Er prüft Tool-Aufrufe, bevor er sie weiterleitet, und protokolliert, ob sie zugelassen oder blockiert wurden. Laut Obsidian erfolgt dies im Rahmen der bestehenden Anwendungsberechtigungen des Nutzers, statt über ein gemeinsames Dienstkonto zusätzliche Berechtigungen zu gewähren.

In der Ankündigung wird außerdem eine Zusammenarbeit mit Cloudflare und dessen MCP Server Portal genannt. Ziel ist es, die Position eines Gateways im Datenverkehrspfad mit dem Identitäts-, Anwendungs- und Datenkontext von Obsidian zu verbinden.

Warum Kontrollen auf Aktionsebene wichtig sind

Für Unternehmen, die Agenten einsetzen, besteht die praktische Herausforderung darin, nützliche Arbeit zu ermöglichen und zugleich folgenschwere Fehler einzudämmen. Ein pauschales Verbot kann einen Arbeitsablauf vollständig stoppen; eine eng umrissene Entscheidung kann routinemäßige Lesezugriffe zulassen und gleichzeitig einen nicht autorisierten Export verhindern oder für eine destruktive Änderung eine Überprüfung verlangen.

Obsidian führt diese Entscheidungen in einer gemeinsamen Richtlinienebene für unterstützte Tools und Durchsetzungspunkte zusammen. Der Nutzen hängt von der Qualität des zugrunde liegenden Zugriffskontexts und davon ab, wie vollständig die kontrollierten Pfade erfasst sind. Je mehr operative Verantwortung Agenten übernehmen, desto wichtiger wird es für die Unternehmenssicherheit, Entscheidungen vor ihrer Ausführung zu erklären und durchzusetzen.