Databricks: Unschuldig, bis eine kombinierte Richtlinie das Agentenrisiko am Schnittpunkt blockiert
Databricks hat ein neues Omnigent-Sicherheitsmuster veröffentlicht, das einen Agenten erst blockiert, nachdem drei für sich genommen gewöhnliche Fähigkeiten eine gefährliche Kette bilden. Der Ansatz von Databricks, „unschuldig, bis kombiniert“, zielt auf den Moment, in dem private Daten, nicht vertrauenswürdige Inhalte und externe Kommunikation innerhalb einer Sitzung verfügbar werden.
Diese Kombination ist als tödliche Dreierkombination bekannt. Ein Agent kann möglicherweise sicher eine interne Datei lesen, eine öffentliche Webseite prüfen oder eine Nachricht senden, wenn jede Aktion für sich erfolgt. Werden jedoch alle drei Fähigkeiten in einem Ausführungspfad zusammengeführt, kann eine eingeschleuste Anweisung legitimen Zugriff in Datendiebstahl verwandeln.
Die wesentliche Veränderung ist nicht eine weitere Warnung vor Prompt Injection. Databricks verlagert die Durchsetzungsentscheidung aus dem Modell heraus und in Omnigent, sein Open-Source-Meta-Harness zum Ausführen und Steuern von Agenten. Die Richtlinienebene merkt sich, worauf eine Sitzung gestoßen ist, und verändert anschließend die Behandlung späterer Aktionen.
Statische Berechtigungen fragen, ob ein Agent ein Tool aufrufen darf. Kontextbezogene Richtlinien fragen zusätzlich, was vor diesem Aufruf geschehen ist. Dieser Unterschied setzt Teams unter Druck, die über Coding-Agenten, Browser-Agenten und Model Context Protocol-Integrationen einen breiten, dauerhaften Tool-Zugriff einsetzen.
Was Databricks in Omnigent geändert hat
Databricks behandelt die Historie eines Agenten als Teil seines effektiven Berechtigungssatzes.
Die Sicherheitsfallstudie des Unternehmens erweitert eine Reihe von Beiträgen über kontextbezogene Richtlinien in Omnigent. Frühere Beispiele konzentrierten sich auf den Sitzungszustand, schleichende Angriffe und Berechtigungen, die an die ursprüngliche Absicht des Nutzers gebunden sind.
Das jüngste Beispiel wendet dieses Modell auf die tödliche Dreierkombination an. Der Sicherheitsforscher Simon Willison definierte das Muster im Juni 2025 als Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und einen externen Kommunikationskanal. Sein Bedrohungsmodell warnt davor, dass die Kombination aller drei eingeschleusten Anweisungen einen Weg zum Informationsdiebstahl eröffnet.
Omnigent sitzt über einem Agenten-Harness, also der Laufzeitumgebung, die Modell, Tools und Ausführungsschleife verwaltet. Das Projekt unterstützt etablierte Coding-Agent-Umgebungen und benutzerdefinierte Agenten, sodass eine gemeinsame Richtlinienebene deren Aktivitäten beobachten kann.
Diese Position ist wichtig, weil die Richtlinie nicht darauf angewiesen ist, dass das zugrunde liegende Modell jede bösartige Formulierung erkennt. Sie kann die Tool-Nutzung auf Grundlage der während der Sitzung erfassten Fakten steuern.
Stellen Sie sich einen Agenten vor, der ein internes Produktdokument prüfen soll. Das Lesen dieses Dokuments ist erwartet. Auch das Senden einer genehmigten Zusammenfassung an einen Unternehmenskanal kann erwartet sein.
Angenommen, der Agent besucht nun ein öffentliches Issue, eine Webseite oder ein Repository mit versteckten Anweisungen. Eine spätere ausgehende Anfrage erhält eine andere Sicherheitsbedeutung, weil die Sitzung eine weitere Vertrauensgrenze überschritten hat.
Eine herkömmliche Allowlist sieht während des gesamten Workflows dieselben genehmigten Tools. Eine kontextbezogene Richtlinie sieht eine Sequenz, deren Risiko sich im Zeitverlauf verändert hat.
Omnigent-Richtlinien können die Entscheidungen „allow“, „ask“ oder „deny“ zurückgeben. „Allow“ erlaubt die Aktion, „ask“ leitet sie an eine Person weiter, und „deny“ blockiert sie. Die Reaktion kann daher strenger werden, wenn die Sitzung sensible Zugriffe oder riskante Ereignisse ansammelt.
Dieses Durchsetzungsmodell erfordert nicht, dass jede Quelle, jedes Tool oder jede Aktion für sich gefährlich ist. Stattdessen überwacht die Richtlinie Kombinationen, die einen unsicheren Datenpfad erzeugen.
Databricks bietet Omnigent außerdem als verwaltete Beta an, die mit Workspace-Identität und Modelldiensten verbunden ist. Die verwaltete Bereitstellung unterstützt derzeit integrierte Handler für kontextbezogene Richtlinien, während beliebige benutzerdefinierte Richtlinienfunktionen dort weiterhin nicht verfügbar sind.
Diese Einschränkung trennt das Open-Source-Design vom verwalteten Produkt. Teams, die die Ankündigung bewerten, müssen zwischen einem demonstrierten Richtlinienmuster und den in ihrer gewählten Bereitstellung verfügbaren Kontrollen unterscheiden.
Dennoch ist die zentrale Veränderung klar. Die Autorisierung von Agenten wird sitzungsabhängig, statt bei der Anmeldung oder Tool-Registrierung festgelegt zu werden.
Warum Databricks' Ansatz „unschuldig, bis kombiniert“ die Sicherheitsgrenze verändert
Das riskante Objekt ist nicht länger ein einzelner Tool-Aufruf, sondern der Pfad, der mehrere erlaubte Aufrufe verbindet.
Herkömmliche Zugriffskontrollen bewerten Identitäten, Ressourcen und Aktionen. Ein Servicekonto kann eine Datenbank lesen, in einen Bucket schreiben oder eine API aufrufen. Diese Regeln bleiben notwendig, weil Agenten weiterhin über gewöhnliche Zugangsdaten arbeiten.
Sie reichen nicht aus, wenn nicht vertrauenswürdige Sprache beeinflusst, wie diese Zugangsdaten verwendet werden. Ein Angreifer muss möglicherweise weder ein Token stehlen noch Anwendungscode ausnutzen. Es genügt, dass bösartige Inhalte ein Modell erreichen, das auf Daten zugreifen und extern handeln kann.
Das erste Element sind private Daten. Diese Kategorie umfasst interne Dokumente, Quellcode, Zugangsdaten, Kundendaten, E-Mails, Datenbankergebnisse und alle Informationen außerhalb der Berechtigung des Angreifers.
Das zweite Element sind nicht vertrauenswürdige Inhalte. Eine Webseite, ein Support-Ticket, ein Pull Request, eine E-Mail, eine geteilte Datei, eine Tool-Antwort oder ein Bild kann Anweisungen enthalten, die von jemandem außerhalb der Vertrauensgrenze des Agenten kontrolliert werden.
Das dritte Element ist externe Kommunikation. E-Mails und HTTP-Anfragen sind offensichtliche Beispiele, doch die Kategorie ist weiter gefasst. Einen Kommentar zu veröffentlichen, Code zu pushen, eine Remote-Ressource zu laden oder in ein gemeinsam genutztes System zu schreiben, kann einen ausgehenden Kanal schaffen.
Keine dieser Fähigkeiten ist ungewöhnlich. Gerade ihr Nutzen erklärt, warum diese Kombination in so vielen Agentendesigns vorkommt.
Ein Recherche-Agent benötigt externe Quellen und internen Kontext. Ein Coding-Agent kann ein privates Repository lesen, öffentliche Dokumentation konsultieren und einen Branch pushen. Ein E-Mail-Assistent liest nicht vertrauenswürdige Nachrichten, durchsucht private Korrespondenz und sendet Antworten.
Eine Fähigkeit dauerhaft zu entfernen, kann den Agenten erheblich weniger nützlich machen. Ständige Genehmigungsaufforderungen schaffen ein anderes Problem, weil sich Nutzer daran gewöhnen können, routinemäßige Anfragen zu akzeptieren.
Die Databricks-Einordnung „unschuldig, bis kombiniert“ bietet eine weitere Option. Operationen mit geringem Risiko können fortgesetzt werden, doch die Richtlinie eskaliert, wenn der Sitzungszustand eine verbotene Kombination vervollständigt.
Damit verlagert sich die Sicherheitsgrenze vom einzelnen Connector auf den Workflow. Ein Browser ist nicht einfach vertrauenswürdig oder nicht vertrauenswürdig. Seine Relevanz hängt davon ab, ob dieselbe Sitzung auch sensible Informationen und einen ausgehenden Weg enthält.
Dieses Modell ähnelt der Informationsflusskontrolle, bei der ein System verfolgt, wie Daten zwischen Vertrauensstufen bewegt werden. Sobald vertrauliche Informationen in einen Kontext gelangen, werden spätere Schreibvorgänge in ein weniger geschütztes Ziel strenger behandelt.
Der veröffentlichte Richtlinienkatalog von Omnigent enthält bereits eine ähnliche Google Drive-Kontrolle. Sobald eine Sitzung eine als vertraulich deklarierte Datei liest, kann die Richtlinie Schreibvorgänge außerhalb der vertraulichen Menge verhindern.
Der Katalog enthält außerdem eine Richtlinie für Risikobewertungen. Sie sammelt Punkte aus Tool-Aufrufen und Kennzeichnungen sensibler Daten und eskaliert anschließend geschützte Tools nach einem konfigurierten Schwellenwert.
Diese Beispiele zeigen, warum der Zustand zentral ist. Eine Schreibanfrage verändert ihre API-Form nicht, nachdem der Agent ein sensibles Dokument gelesen hat. Ihre Bedeutung verändert sich aufgrund der Historie der Sitzung.
Dasselbe Prinzip gilt für die tödliche Dreierkombination. Die Richtlinie sucht nach einer gefährlichen Zusammensetzung, nicht nach einer universell verbotenen Operation.
Diese Unterscheidung sollte Plattformteams stärker interessieren als ein weiterer Prompt-Filter. Filter versuchen zu entscheiden, ob Text bösartig wirkt. Kontextbezogene Durchsetzung kann eine unsichere Aktion weiterhin blockieren, wenn das Modell oder der Filter die Injection nicht erkennt.
Statische Berechtigungen verlieren die Sequenz aus dem Blick
Eine statische Allowlist kann verfügbare Fähigkeiten beschreiben, aber nicht erklären, wie der Agent zu einer Aktion gelangt ist.
Angenommen, ein Entwickler autorisiert einen Agenten, ein privates Repository zu lesen, Dokumentation zu durchsuchen und Pull Requests zu öffnen. Jede Berechtigung unterstützt einen normalen Coding-Workflow.
Ein Angreifer platziert dann eine Anweisung in einem Issue, einem Abhängigkeitsdokument oder einer abgerufenen Webseite. Die Anweisung fordert den Agenten auf, ein Geheimnis zu sammeln und in eine öffentliche Pull-Request-Beschreibung aufzunehmen.
Das Lesen des Repositorys ist erlaubt. Der Webabruf ist erlaubt. Das Öffnen eines Pull Requests ist erlaubt. Eine Kontrolle, die jede Anfrage unabhängig bewertet, kann die gesamte Kette genehmigen.
Ein Inhaltsfilter könnte die Anweisung erkennen. Er könnte aber auch eine indirekte Aufforderung, kodierte Daten, eine unbekannte Sprache oder eine auf das Zielmodell zugeschnittene Nutzlast übersehen.
Studien legen nahe, vorsichtig zu sein, wenn man sich allein auf Modellverhalten verlässt. Der WASP-Benchmark testete realistische Prompt-Injection-Angriffe gegen Web-Agent-Systeme mit mehreren Modellen und Scaffolds.
Die Forschenden stellten fest, dass Agenten in den getesteten Konfigurationen zwischen 16 und 86 Prozent der Angreiferanweisungen auszuführen begannen. Der End-to-End-Erfolg der Angreifer war geringer und lag zwischen null und 17 Prozent.
Diese Lücke ist ermutigend, aber nicht beruhigend. Aktuelle Agenten scheitern häufig, bevor sie einen komplexen Angriff abschließen, doch eine höhere Zuverlässigkeit von Agenten kann auch bösartige Workflows leichter abschließbar machen.
Ein System sollte nicht darauf bauen, dass ein Agent im richtigen Moment verwirrt wird. Es benötigt eine Kontrolle, die wirksam bleibt, wenn Modelle bei mehrstufiger Ausführung besser werden.
Statische Berechtigungen haben zudem Schwierigkeiten mit verzögerten Angriffen. Die eingeschleuste Anweisung löst möglicherweise keine unmittelbare ausgehende Aktion aus. Sie kann einen späteren Plan, eine delegierte Aufgabe, eine generierte Datei oder einen Tool-Aufruf beeinflussen.
Eine sitzungsbewusste Richtlinie kann sicherheitsrelevante Fakten über diese Verzögerung hinweg bewahren. Sie benötigt nicht jedes verdächtige Ereignis unmittelbar neben der abschließenden Aktion im aktiven Kontext des Modells.
Diese Persistenz adressiert eine praktische Schwäche lang laufender Agenten. Der Gesprächsverlauf kann komprimiert, zusammengefasst oder auf mehrere Worker verteilt werden. Ein Modell kann sich möglicherweise nicht mehr an eine frühere Einschränkung erinnern, obwohl seine Tools und Zugangsdaten weiterhin verfügbar sind.
Der Richtlinienzustand sollte daher außerhalb des Textfensters liegen. Die Durchsetzungsebene benötigt eine eigene dauerhafte Aufzeichnung sensibler Lesevorgänge, nicht vertrauenswürdiger Eingaben, Ziele, Genehmigungen und Risikoänderungen.
Diese Architektur verringert zudem die Abhängigkeit von der Selbstauskunft des Agenten. Das Modell zu fragen, ob es auf nicht vertrauenswürdige Inhalte gestoßen ist, ist schwächer, als zu erfassen, welcher Connector die Inhalte geliefert hat.
Die stärksten Signale kommen aus der Infrastruktur. Ein Dokumentensystem kennt die Klassifizierung einer Datei. Ein Netzwerk-Gateway kennt das Ziel. Eine Identitätsebene kennt Nutzer und Workspace. Ein Tool-Broker weiß, welche Operation angefordert wurde.
Omnigent kann diese Signale kombinieren, weil es die Ausführungsumgebung umschließt. Der Agent schlägt eine Aktion vor, doch die Richtlinie entscheidet, ob diese Aktion im aufgezeichneten Kontext weiterhin akzeptabel ist.
Dies ist der Druckpunkt für konkurrierende Agentenplattformen. Tool-bezogene Genehmigungen sind leichter zu erklären und umzusetzen. Sie wirken weniger überzeugend, wenn Agenten längere Sitzungen über mehr Connectoren hinweg ausführen.
Anbieter werden zeigen müssen, ob ihre Kontrollen Daten- und Vertrauensübergänge über Tools hinweg verfolgen. Eine lange Liste von Berechtigungen beantwortet die zentrale Sicherheitsfrage nicht mehr.
Kontextbezogene Richtlinien unterbrechen die Kette, bevor Daten das System verlassen
Der nützliche Kontrollpunkt ist der Übergang, der den Angriffspfad vervollständigt, in der Regel ein sensibler Lesevorgang oder eine ausgehende Aktion.
Eine kontextbezogene Richtlinie beginnt mit beobachtbaren Ereignissen. Dazu können ein Tool-Aufruf, ein Tool-Ergebnis, eine Datenkennzeichnung, ein Ziel, eine Modellanfrage oder eine Nutzerfreigabe gehören.
Die Richtlinie speichert ausgewählte Fakten im Sitzungsstatus. Sie kann festhalten, dass der Agent nicht vertrauenswürdige Inhalte verarbeitet, auf ein vertrauliches Objekt zugegriffen oder versucht hat, außerhalb einer genehmigten Grenze zu kommunizieren.
Spätere Ereignisse werden anhand dieses Status bewertet. Wenn der nächste Vorgang eine verbotene Kombination vervollständigt, kann die Richtlinie eine Freigabe verlangen oder die Anfrage ablehnen.
Die Reihenfolge kann variieren. Ein Agent könnte private Daten lesen, bevor er eine nicht vertrauenswürdige Seite besucht. Er könnte zuerst auf eingeschleuste Inhalte stoßen und dann Zugriff auf eine interne Datei anfordern.
Eine solide Implementierung muss beide Wege erkennen. Die Gefahr entsteht dadurch, dass Fähigkeiten miteinander verbunden werden – nicht durch eine feste Reihenfolge.
Die Durchsetzung kann zudem an mehr als einer Stelle erfolgen. Eine Richtlinie könnte das Lesen sensibler Daten blockieren, nachdem nicht vertrauenswürdige Inhalte in die Sitzung gelangt sind. Ein anderes Design könnte die Analyse erlauben, aber eine anschließende externe Kommunikation verhindern.
Das Blockieren ausgehender Datenübertragungen erhält oft mehr lokalen Nutzen. Der Agent kann weiter lesen und Entwürfe erstellen, ohne einen Weg zur Preisgabe von Informationen zu erhalten. Allerdings müssen Egress-Kontrollen mehr als offensichtliche Sendefunktionen abdecken.
Ein generierter Link kann Daten kodieren. Eine Anfrage nach einem Remote-Bild kann Abfrageparameter übertragen. Ein Source-Control-Push, ein Issue-Kommentar, ein Analytics-Aufruf oder ein Schreibvorgang in ein geteiltes Dokument kann die Vertrauensgrenze überschreiten.
Auch der Kontext des Ziels ist wichtig. Eine Zusammenfassung an einen genehmigten internen Kanal zu senden, unterscheidet sich davon, sie in einem öffentlichen Repository zu veröffentlichen. Alle Schreibvorgänge gleich zu behandeln, würde unnötige Unterbrechungen verursachen.
Menschliche Freigaben sind wertvoll, wenn Kontext und Ziel klar sind. Ein hilfreicher Hinweis sollte erklären, dass die Sitzung vertrauliche Daten gelesen, später nicht vertrauenswürdige Inhalte verarbeitet hat und nun einen bestimmten externen Endpunkt kontaktieren möchte.
Eine generische Meldung wie „Dieses Tool zulassen“ verbirgt den Grund für die Eskalation. Sie fördert Freigabemüdigkeit, weil die prüfende Person den Ablauf manuell rekonstruieren muss.
Eine harte Ablehnung passt zu Kombinationen, die eine Organisation niemals akzeptiert. Beispielsweise kann eine Richtlinie verhindern, dass eine Sitzung, die öffentlichen Inhalten ausgesetzt war, Informationen aus einem eingeschränkten Datensatz außerhalb ihres Bereichs sendet.
Die Richtlinien-Engine muss sicher fehlschlagen, wenn erforderlicher Kontext fehlt. Eine fehlende Datenkennzeichnung, ein nicht unterstütztes Tool oder ein nicht beobachteter Netzwerkpfad kann einen blinden Fleck schaffen.
Omnigents breiterer Ansatz kombiniert Richtlinien mit Sandboxing. Eine Sandbox beschränkt Datei- und Netzwerkzugriffe an der Betriebssystemgrenze und reduziert damit, was ein Agent erreichen kann, selbst wenn das Modell dies anfordert.
Diese Ebenen erfüllen unterschiedliche Zwecke. Die Sandbox begrenzt die rohe Fähigkeit. Eine kontextbezogene Richtlinie passt Berechtigungen anhand des über die Sitzung angesammelten Zustands an.
Keine von beiden ersetzt gewöhnliche Identitätskontrollen, Connector-Autorisierung, Protokollierung oder Schutz vor Datenverlust. Die Ankündigung ist am nützlichsten, wenn sie als eine Durchsetzungsebene innerhalb dieses Stacks verstanden wird.
Der Agentic Security Report von OWASP identifiziert Prompt Injection als eine führende Angriffstechnik gegen KI-Systeme. Seine übergeordnete Botschaft lautet, dass Agentensicherheit Kontrollen rund um Ausführung, Tools, Identität und Datenbewegung erfordert.
Das stützt die architektonische Richtung von Databricks. Ein probabilistisches Modell kann eine Aktion vorschlagen, doch eine deterministische Grenze sollte entscheiden, ob diese Aktion zulässig ist.
Was die Databricks-Richtlinie nicht klärt
Kontextbezogene Durchsetzung verengt den Angriffspfad, doch ihre Zuverlässigkeit hängt von vollständiger Sichtbarkeit und vertrauenswürdiger Klassifizierung ab.
Die erste ungelöste Frage ist die Abdeckung. Eine Richtlinie kann keinen Kanal blockieren, den sie nicht beobachtet.
Ein Agent kann über einen Connector, einen Shell-Befehl, eine Browseranfrage, eine eingebettete Ressource oder ein generiertes Artefakt kommunizieren. Jeder Pfad, über den Daten die Grenze verlassen können, muss im Richtlinienmodell abgebildet oder anderweitig eingeschränkt sein.
Die zweite Frage ist die Klassifizierung. Das System muss wissen, welche Inhalte nicht vertrauenswürdig und welche Daten sensibel sind.
Einfache Regeln können öffentliche Webseiten als nicht vertrauenswürdig und benannte Dokumente als vertraulich klassifizieren. Unternehmensumgebungen enthalten schwierigere Fälle, darunter geteilte Laufwerke, Auftragnehmerkonten, kopierter Text, generierte Dateien und Daten, die aus mehreren Quellen mit geringer Sensibilität zusammengesetzt wurden.
Falsch-negative Ergebnisse lassen die gefährliche Kombination unentdeckt. Falsch-positive Ergebnisse unterbrechen die normale Arbeit und können Nutzer dazu bringen, Warnungen ohne Prüfung zu genehmigen.
Die dritte Frage ist der Geltungsbereich des Zustands. Eine Sitzung ist eine praktische Einheit, doch Informationen können über Dateien, Speicherablagen, Caches, Subagenten und kopierte Zusammenfassungen zwischen Sitzungen wandern.
Wenn ein Worker vertrauliche Daten liest und ein anderer Worker das Ergebnis sendet, kann die Verfolgung pro Sitzung den kombinierten Fluss übersehen. Multi-Agenten-Systeme benötigen Weitergaberegeln, die relevante Kennzeichnungen über Delegierungen hinweg erhalten.
Die vierte Frage ist die Integrität der Richtlinien. Die Durchsetzungsebene, Konfiguration und der Ereignisstrom werden zu sicherheitskritischer Infrastruktur. Angreifer könnten auf Richtlinienlücken, fehlerhafte Tool-Metadaten, mehrdeutige Ziele oder Fail-open-Verhalten zielen.
Teams sollten die tatsächliche Richtliniengrenze testen, nicht nur das Modell. Gegenspielerische Evaluierungen müssen alternative Egress-Routen, verzögerte Aktionen, agentenübergreifende Übertragungen und unvollständige Metadaten einschließen.
Die fünfte Frage ist die Nutzbarkeit. Eine Kontrolle, die zu oft um Freigabe bittet, kann genau die Schwäche reproduzieren, die sie lösen sollte.
Risikobasierte Eskalation benötigt sorgfältig gewählte Schwellenwerte und informative Hinweise. Sicherheitsteams sollten Freigabehäufigkeit, Genauigkeit von Ablehnungen, Override-Raten und die Gründe messen, aus denen Nutzer Ausnahmen akzeptieren.
Die verwaltete Omnigent-Beta bringt eine weitere praktische Einschränkung mit sich. Databricks dokumentiert derzeit Unterstützung für integrierte Handler, nicht für beliebigen benutzerdefinierten Richtliniencode, in der verwalteten Umgebung.
Organisationen mit spezialisierten Klassifizierungen oder proprietären Connectors sollten prüfen, ob die verfügbaren Richtlinien genügend Kontext bereitstellen. Open-Source-Flexibilität lässt sich nicht automatisch in Parität bei verwalteten Diensten übertragen.
Es gibt zudem noch keine Grundlage dafür, eine einzelne Demonstration als universelle Validierung zu behandeln. Der Databricks-Artikel erläutert ein Sicherheitsmuster und einen Implementierungsansatz. Er belegt nicht, dass jede Omnigent-Konfiguration jede Prompt-Injection-Technik blockiert.
Die richtige Aussage ist enger gefasst. Sitzungsbewusste Durchsetzung kann einen Pfad der tödlichen Dreierkombination unterbrechen, selbst wenn jedes einzelne Tool legitim bleibt.
Das ist dennoch bedeutsam. Sicherheitsarchitektur gelingt oft dadurch, dass eine notwendige Bedingung eines Angriffs entfernt wird – nicht dadurch, dass man der Anwendung beibringt, jede Angreifernachricht zu erkennen.
Die stärksten Bereitstellungen werden kontextbezogene Richtlinien mit eingeschränkten Zugangsdaten, Ziel-Allowlistings, Sandboxing, Audit-Logs und unabhängigen Tests kombinieren. Sie werden Richtliniendefinitionen außerdem als versionierten Sicherheitscode behandeln.
Drei Signale werden zeigen, ob das Modell trägt
Der nächste Test besteht darin, ob kontextbezogene Richtlinien zu messbarer Infrastruktur statt zu einer überzeugenden Demonstration werden.
Das erste Signal ist eine breitere Abdeckung über Tools und Agenten-Harnesses hinweg. Databricks muss zeigen, dass Sicherheitskennzeichnungen und Sitzungsstatus gängige Workflows mit Browsern, Code-Repositories, Dokumentensystemen, Shells und delegierten Agenten überdauern.
Unterstützung auf einer Funktionsliste reicht nicht aus. Teams benötigen Belege dafür, dass gleichwertige Aktionen über unterschiedliche Harnesses und Connector-Implementierungen hinweg gleichwertig durchgesetzt werden.
Eine konsistente Abdeckung würde das Argument für ein gemeinsames Meta-Harness stärken. Wesentliche Unterschiede zwischen Laufzeitumgebungen würden das Versprechen einer Governance-Ebene über Agenten hinweg schwächen.
Das zweite Signal ist die gegenspielerische Evaluierung. Omnigent benötigt wiederholbare Tests, die verzögerte Exfiltration, indirekten Egress, sitzungsübergreifende Übertragung und Manipulation von Metadaten versuchen.
Nützliche Ergebnisse sollten Erkennung, Freigabe, Ablehnung und erfolgreiche Datenbewegung voneinander trennen. Sie sollten auch die Erledigung gutartiger Aufgaben berichten, denn eine Richtlinie, die jeden Workflow blockiert, ist zwar sicher, aber unbrauchbar.
Öffentliche Test-Fixures würden Sicherheitsteams ermöglichen, Ergebnisse mit ihrer eigenen Konfiguration zu reproduzieren. Eine unabhängige Bewertung hätte mehr Gewicht als ein vom Anbieter ausgewähltes Szenario.
Das dritte Signal ist die operative Einführung in verwalteten Databricks-Umgebungen. Achten Sie auf erweiterte Richtlinienunterstützung, klarere Telemetrie, Administrationskontrollen und dokumentierte Integrationen mit unternehmensweiten Datenklassifizierungen.
Die Einführung sollte messbare Ergebnisse erzeugen. Teams müssen wissen, wie oft Richtlinien ausgelöst werden, welche Fähigkeitskombinationen Eskalationen verursachen und ob Prüfer die Entscheidung aufheben oder genehmigen.
Diese Signale sind wichtig, weil das zugrunde liegende Sicherheitsproblem mit dem Nutzen von Agenten wachsen wird. Bessere Agenten werden längere Aufgaben erledigen, mehr Tools nutzen und mehr Vertrauensgrenzen ohne ständige Aufsicht überschreiten.
Der Ansatz von Databricks, Komponenten als unschuldig zu behandeln, bis sie kombiniert werden, bietet ein glaubwürdiges Designprinzip: Nützliche Komponenten zulassen, während die gefährliche Zusammensetzung blockiert wird. Er verlagert die Aufmerksamkeit von der Frage, ob ein Modell einen Angriff versteht, auf die Frage, ob das umgebende System dem Angriff erlaubt, zu Ende geführt zu werden.
Entwickler sollten abbilden, welche Sitzungen auf private Daten zugreifen, von Angreifern kontrollierte Inhalte aufnehmen und extern kommunizieren können. Unternehmenskäufer sollten fragen, ob eine Plattform diese Bedingungen über Zeit, Tools und delegierte Worker hinweg verfolgt.
Wenn alle drei ohne kontextbezogene Durchsetzung verfügbar bleiben, löst ein ausgefeilter Freigabebildschirm das Problem nicht. Der praktische nächste Schritt besteht darin, zu identifizieren, wo die dritte Fähigkeit in jeden Workflow eintritt, und dann an dieser Grenze eine testbare Richtlinie zu platzieren.
