Databricks Permission ist nicht gleich Zweck: Omnigent stellt die Absicht vor die Agentenaktion

Databricks hat für Omnigent eine neue Berechtigungsgrenze eingeführt, obwohl der Agent in seinem Test bereits für jedes Tool gültige Zugangsdaten besitzt. Die Kontrolle fragt, warum eine Aktion erfolgt, nicht nur, ob der Agent sie ausführen kann. Diese Unterscheidung macht aus databricks permission statt einer reinen Identitätsprüfung eine aufgabenspezifische Einschränkung.

Die am 23. Juli veröffentlichte Lösung präsentiert absichtsbasierte Autorisierung als Schutz gegen indirekte Prompt Injection. Bei diesem Angriff werden Anweisungen in Inhalte eingebettet, die ein Agent liest – etwa in E-Mails, Dokumente, Support-Tickets oder Datenbankfelder. Omnigent bindet jede Sitzung an einen von Menschen genehmigten Zweck und prüft jeden Tool-Aufruf daran.

Dieser Ansatz stellt das standardmäßige, identitätsorientierte Modell hinter den meisten Unternehmens-Zugriffssystemen infrage. Rollenbasierte Zugriffskontrolle kann bestätigen, dass ein Agent Datenbankzugriff gewähren darf. Sie kann jedoch nicht feststellen, ob das Gewähren von Zugriff Teil einer Überprüfung der Datenqualität ist. Der Unterschied zwischen Fähigkeit und Zweck wird nun zu einer operativen Sicherheitsgrenze.

Databricks Permission prüft jetzt die Aufgabe, nicht nur die Identität

Die unmittelbare Änderung ist einfach: Omnigent bewertet, ob jeder vorgeschlagene Tool-Aufruf dem erklärten Zweck der aktuellen Sitzung dient.

Herkömmliche Autorisierung beginnt mit der Identität. Ein Nutzer, Servicekonto oder Agent erhält die Berechtigung, mit bestimmten Ressourcen zu interagieren. Anwendungen akzeptieren oder verweigern Vorgänge dann nach Rollen, Scopes, Richtlinien und Zugangsdaten.

Dieses Modell setzt voraus, dass der authentifizierte Akteur einen relativ stabilen Entscheidungsträger repräsentiert. Ein Mensch liest Informationen, interpretiert sie und entscheidet, welche erlaubte Schaltfläche er betätigt. Die Autorisierungsebene muss nur selten verstehen, warum die Person darauf geklickt hat.

Ein KI-Agent arbeitet anders. Er liest Daten und entscheidet in derselben automatisierten Schleife, was zu tun ist. Inhalte, die von außerhalb des Systems stammen, können sowohl sein Schlussfolgern als auch seine Auswahl privilegierter Tools beeinflussen.

Laut der Veröffentlichung zur Intent-Autorisierung begegnet Omnigent diesem Unterschied, indem es Identität und Absicht kombiniert. Die Identität definiert die breite Menge an Vorgängen, die dem Agenten zur Verfügung stehen. Die Absicht grenzt diese Menge für eine Aufgabe oder Sitzung ein.

Der Mechanismus erzeugt vor einem Tool-Aufruf drei mögliche Entscheidungen:

• ALLOW: Die vorgeschlagene Aktion passt eindeutig zum genehmigten Zweck.

• ASK: Die Aktion steht mit dem Zweck in Verbindung, erfordert jedoch menschliche Zustimmung.

• DENY: Die Aktion liegt außerhalb des erklärten Zwecks und kann nicht fortgesetzt werden.

Diese Ergebnisse sind wichtig, weil gültige Zugangsdaten die Autorisierungsentscheidung nicht länger abschließend klären. Ein Agent kann über ein Tool verfügen und dennoch außerstande sein, es während einer nicht zusammenhängenden Aufgabe zu nutzen.

Omnigent ist ein Open-Source-Meta-Harness, also eine gemeinsame Orchestrierungs- und Richtlinienebene für verschiedene Agenten-Runtimes. Sein Open-Source-Repository nennt Unterstützung für Claude Code, Codex, Cursor, OpenCode, Hermes, Pi und benutzerdefinierte Agenten.

Diese Positionierung macht die Richtlinie umfassender als eine Schutzmaßnahme für ein einzelnes Modell. Die Intent-Prüfung sitzt um die Tool-Aktivität des Agenten herum und kann dadurch unterschiedliche Reasoning-Systeme über eine gemeinsame Ebene steuern.

Die Veröffentlichung bringt auch eine wichtige Einschränkung mit sich. Omnigent befindet sich weiterhin in der Alpha-Phase; die Demonstration sollte daher als Designvorschlag und funktionierende Implementierung verstanden werden. Sie ist kein Beleg für Zuverlässigkeit im Produktionsmaßstab über alle Modelle, Tools und Unternehmensabläufe hinweg.

Der architektonische Punkt ist dennoch konkret. Eine Autorisierungsentscheidung kann die aktuelle Aufgabe einbeziehen, ohne bestehende Identitätskontrollen zu ersetzen. Für Sicherheitsteams entsteht dadurch ein zusätzlicher Prüfpunkt zwischen der Entscheidung eines Modells und einer folgenreichen Aktion.

Die neue Kontrolle ergänzt zudem Omnigents weitere kontextbezogene Richtlinien. Diese Richtlinien können Sitzungsrisiken, sensible Daten, kumulative Tool-Nutzung oder dienstspezifische Einschränkungen berücksichtigen. Wenn mehrere Richtlinien denselben Aufruf bewerten, überstimmt eine Ablehnung freizügigere Entscheidungen.

Diese Regel verhindert, dass eine neu hinzugefügte Richtlinie unbemerkt eine strengere aufhebt. Sie ordnet die Absicht außerdem als eine Ebene innerhalb einer umfassenderen Verteidigung ein, statt sie als vollständige Antwort auf die Sicherheit von Agenten darzustellen.

Der Datenqualitäts-Test legt die Zwecklücke offen

Databricks wählte einen kleinen Daten-Workflow, um zu zeigen, warum übermäßige Berechtigungen manchmal operativ notwendig, aber dennoch unsicher sind.

Der Testagent führt eine routinemäßige Aufgabe zur Datenqualität aus. Er liest eine Kundentabelle, berechnet Qualitätsindikatoren und veröffentlicht eine Zusammenfassung auf einem internen Dashboard.

Zu seinen verfügbaren Tools gehören eine Tabellenabfrage, ein Dashboard-Update und eine Funktion, die einem anderen Nutzer Zugriff auf die Tabelle gewährt. Die letzte Fähigkeit ist für diese konkrete Prüfung nicht erforderlich. Derselbe Agent nutzt sie jedoch bei anderen legitimen Aufgaben.

Das Entfernen des Tools zur Zugriffsvergabe würde das unmittelbare Risiko verringern. Es würde den Agenten jedoch auch daran hindern, gültige Bereitstellungsaufgaben ohne separate Konfiguration oder Identität abzuschließen. Hier wird statisches Least Privilege für universell einsetzbare Agenten schwierig.

Die Sitzung beginnt mit einer engen Anforderung: die Kundentabelle prüfen und eine Zusammenfassung veröffentlichen. Ein Angreifer hat zuvor eine Anweisung in einem nutzergesteuerten Feld dieser Tabelle platziert.

Der versteckte Text gibt sich als Audit-Hinweis aus. Er weist den Agenten an, einer externen Adresse Zugriff auf die Kundendaten zu gewähren und anschließend die ursprüngliche Qualitätsprüfung fortzusetzen.

Dabei handelt es sich um eine indirekte Prompt Injection, weil die bösartige Anweisung über abgerufene Daten eintrifft. Der Nutzer hat den Agenten nie gebeten, Berechtigungen zu ändern, und der Angreifer benötigte keinen direkten Zugriff auf die Unterhaltung des Agenten.

Ohne die Intent-Richtlinie folgt der Testagent von Omnigent der eingeschleusten Anweisung. Seine Identität ist für die Nutzung des Tools zur Zugriffsvergabe autorisiert, sodass eine herkömmliche Berechtigungsprüfung einen gültigen Vorgang von einem gültigen Akteur erkennt.

Der Agent protokolliert die Freigabe anschließend als normale Audit-Aktivität. Dieses Detail veranschaulicht ein zweites Problem: Aktivitätsprotokolle können einen Vorgang korrekt erfassen, ohne offenzulegen, dass er gegen das tatsächliche Ziel des Nutzers verstieß.

Bei aktivierter absichtsbasierter Autorisierung bleiben dieselben Tools und Zugangsdaten verfügbar. Das Ergebnis ändert sich, weil jeder Vorgang mit dem genehmigten Zweck der Datenqualitätsprüfung verglichen wird.

Das Lesen der Tabelle erhält eine ALLOW-Entscheidung. Die Veröffentlichung des angeforderten Dashboard-Updates erhält eine ASK-Entscheidung, sodass ein Mensch den Schreibvorgang bestätigen kann. Das Gewähren von Zugriff für die externe Adresse erhält eine DENY-Entscheidung.

Die legitime Aufgabe wird nach der Genehmigung des Dashboard-Updates dennoch abgeschlossen. Die eingeschleuste Aktion scheitert, weil sie nicht zum erklärten Zweck der Sitzung beiträgt.

Dieses Beispiel gibt databricks permission-Kontrollen eine präzisere Bedeutung. Die Frage lautet nicht mehr nur, ob der Agent Zugriffe ändern kann. Das System bewertet auch, ob diese Änderung in eine Datenqualitätssitzung gehört.

Der Test spiegelt ein praktisches Unternehmensproblem wider. Ein Agent, der mit einer durchsuchbaren Wissensbasis, einer Datenplattform oder einer Support-Umgebung verbunden ist, kann auf Text aus vielen Vertrauensebenen treffen. Ein Nutzerkommentar und eine Administratoranweisung können in denselben Modellkontext gelangen.

Menschen erkennen organisatorischen Kontext nicht perfekt, können eine ungewöhnliche Anforderung jedoch hinterfragen. Modelle können ausgefeilten bösartigen Text als Teil der Aufgabe interpretieren, insbesondere wenn er einer gewöhnlichen Geschäftsanweisung ähnelt.

Die Sicherheitsforscher von Google definieren indirekte Prompt Injection als bösartige Anweisungen, die in Inhalte eingebettet sind, welche ein KI-System verarbeitet. Ihre aktuelle Analyse von Webbedrohungen fand sowohl bösartige Versuche als auch viele harmlose Texte, die Injektionsmustern ähneln.

Diese Mischung erschwert die Inhaltsfilterung. Ein Detektor, der nach Formulierungen wie „ignore previous instructions“ sucht, wird auf Forschungspapiere, Sicherheitsanleitungen und harmlose Diskussionen stoßen. Ein ausgefeilter Angriff kann Geschäftssprache ohne offensichtliche bösartige Marker verwenden.

Absichtsbasierte Autorisierung nähert sich dem Problem von der Aktionsseite. Sie muss nicht beweisen, dass ein Tabellenfeld feindselig ist, bevor sie eine nicht zusammenhängende Berechtigungsänderung blockiert. Sie fragt, ob der daraus resultierende Tool-Aufruf die Aufgabe unterstützt.

Das ist die zentrale Umkehrung in der Demonstration von Databricks. Für das Identitätssystem wirkt der gefährliche Vorgang nicht unautorisiert. Er wird erst unautorisiert, wenn der Zweck in die Entscheidung einfließt.

Warum identitätsbasierter Zugriff Agenten übermäßig exponiert

Der größte Druck trifft Identitäts- und Zugriffssysteme, die den Scope von Zugangsdaten als endgültige Grenze für autonome Software behandeln.

Rollenbasierte Zugriffskontrolle bleibt unverzichtbar. Sie begrenzt, welche Ressourcen eine Identität erreichen und welche Vorgänge sie anfordern kann. Intent-basierte Kontrollen können nicht zuverlässig dafür kompensieren, dass ein Agent Administratorzugriff auf eine gesamte Organisation besitzt.

Rollen bleiben jedoch tendenziell stabil, während sich Agentenaufgaben schnell ändern. Ein Coding-Agent kann in unterschiedlichen Sitzungen ein Repository prüfen, einen Branch erstellen, einen Dienst bereitstellen oder ein Issue ändern. Jede Aufgabe erfordert eine andere Teilmenge derselben verfügbaren Fähigkeiten.

Für jede mögliche Aufgabe eine eigene Identität zu erstellen, würde einen großen Bereitstellungsaufwand verursachen. Einer wiederverwendbaren Identität weitreichende Scopes zu geben, schafft ein Problem der Ambient Authority, bei dem Zugangsdaten über ihren unmittelbaren Zweck hinaus verfügbar bleiben.

Kurzlebige und eng abgegrenzte Zugangsdaten können diese Exposition verringern. Sie funktionieren am besten, wenn Systeme die exakt benötigten Ressourcen und Aktionen vor der Ausführung vorhersagen können. Offene Agenten-Workflows entdecken diese Anforderungen häufig erst während der Arbeit.

Das Omnigent-Modell fügt eine Einschränkung auf Sitzungsebene hinzu, ohne für jede Unterhaltung eine neue Identität zu verlangen. Ein Mensch erklärt, was der Agent erreichen soll; anschließend bewertet die Richtlinie vorgeschlagene Aktionen anhand dieser Erklärung.

Bei autonomen Agenten kann die Absicht laut Databricks bereits zur Entwicklungszeit in der Agentenspezifikation festgelegt werden. Der laufende Agent kann sie nicht erweitern oder entfernen.

Interaktive Agenten behandeln die Entscheidung anders. Der Agent entwirft aus der natürlichsprachlichen Beschreibung des Nutzers eine Richtlinie, doch ein Mensch genehmigt sie zu Beginn der Sitzung. Die Richtlinie kann sich während dieser Sitzung nicht im Hintergrund ändern.

Dieser menschliche Genehmigungsschritt ist wichtig, weil die Ableitung von Absichten eine eigene Schwachstelle schafft. Könnte das Modell den Zweck nach dem Lesen eingeschleuster Inhalte stillschweigend neu definieren, könnte ein Angreifer es dazu bewegen, die unerwünschte Aktion zu autorisieren.

Omnigent verweigert dem laufenden Agenten außerdem Tools zum Entfernen, Bearbeiten oder Deaktivieren seiner Absicht. Das Hinzufügen einer weiteren Richtlinie erfordert menschliche Genehmigung, und eine freizügige Ergänzung kann eine bestehende Ablehnung nicht überstimmen.

Diese Kontrollen schaffen Manipulationsresistenz rund um die Richtlinienkonfiguration. Sie machen die zugrunde liegende Intent-Bewertung jedoch nicht unfehlbar.

Die Dokumentation der integrierten Richtlinie besagt, dass ihre Kontrolle intent_based_authorization die erste Nutzernachricht als Sitzungsabsicht erfasst. Anschließend fragt sie vor Tool-Aufrufen ohne plausible Verbindung zu dieser Absicht nach. Die Dokumentation erklärt außerdem, dass die Richtlinie eine LLM-Konfiguration benötigt und ohne diese standardmäßig offen fehlschlägt.

Dieses letzte Verhalten verdient Aufmerksamkeit. Ein Sicherheitsmechanismus, der freizügig wird, wenn sein Evaluator fehlt, schafft einen Bereitstellungszustand, den Teams testen und überwachen müssen. Produktionsumgebungen benötigen in der Regel sichtbare Fehler, Konfigurationsvalidierung und Warnmeldungen, wenn eine erforderliche Richtlinienkomponente nicht verfügbar ist.

Der Einsatz eines LLM-Evaluators bringt einen weiteren Zielkonflikt mit sich. Natürlichsprachliches Schlussfolgern kann Aufgabenbeziehungen erfassen, die statische Regeln übersehen. Es kann jedoch auch inkonsistente Entscheidungen hervorbringen, wenn sich Prompts, Modelle oder der umgebende Kontext ändern.

Diese Spannung erklärt, warum Databricks Intent als Teil einer mehrschichtigen Agentensicherheit präsentiert. Eine Richtlinie kann eine aufgabenfremde Zugriffsgewährung stoppen, während ein anderer Mechanismus kumulative Risiken begrenzt. Separate Regeln zur Verhinderung von Datenverlust können steuern, welche Informationen durch einen ansonsten erlaubten Aufruf fließen.

Auch NIST hat Autorisierung als ungelöstes Agentenproblem identifiziert. Sein Vorschlag zur Agentenidentität vom Februar 2026 fragt, wie Organisationen Identitäts-, Autorisierungs-, Audit- und Nichtabstreitbarkeitskontrollen auf autonome Software anwenden sollten.

Der Vorschlag umfasst ausdrücklich Kontrollen zur Verhinderung und Eindämmung von Prompt Injection. Dieser Umfang zeigt, warum Identität und Zweck nicht getrennt diskutiert werden können.

Ein authentifizierter Agent kann dennoch eine schädliche Entscheidung treffen. Eine zweckkonforme Aktion kann weiterhin sensible Daten offenlegen, wenn ihre Argumente oder ihr Ziel unsicher sind. Wirksame Kontrollen müssen Identität, Aufgabe, Daten, Aktion und Konsequenz gemeinsam berücksichtigen.

Für Unternehmenskäufer ist die erforderliche Antwort architektonischer Natur. Sicherheitsprüfungen können nicht länger mit einer Liste von OAuth-Scopes oder Service-Account-Rollen enden. Teams müssen dokumentieren, wie jede folgenreiche Aktion während der Ausführung mit einem vom Nutzer genehmigten Ziel verbunden bleibt.

Intent-basierte Autorisierung bringt Urteilsvermögen und neue Fehlermodi

Omnigent schließt eine Autorisierungslücke, indem es modellgestütztes Urteilsvermögen direkt in den Durchsetzungspfad integriert.

Dieses Design bietet Flexibilität, schafft aber auch Unsicherheit. „Plausibel mit der Aufgabe verbunden“ ist keine vollständig deterministische Eigenschaft.

Stellen Sie sich einen Agenten vor, der einen Produktionsausfall untersuchen soll. Das Lesen von Logs passt eindeutig zur Aufgabe. Das Neustarten eines Dienstes könnte passen, nachdem der Agent einen Fehler identifiziert hat. Das Rotieren von Zugangsdaten könnte erforderlich sein, wenn die Belege auf eine Kompromittierung hindeuten.

Eine enge Richtlinie könnte die für die Wiederherstellung nötigen Aktionen blockieren. Eine weit gefasste Richtlinie könnte es einem Angreifer erlauben, eine unabhängige Änderung von Zugangsdaten als Reaktion auf einen Vorfall darzustellen. Menschliche Genehmigungen können einen Teil der Unklarheit auflösen, doch häufige Aufforderungen können die Arbeit verlangsamen und automatische Zustimmung fördern.

Das Modell ALLOW, ASK und DENY hängt daher von sorgfältiger Kalibrierung ab. ASK ist besonders wichtig, weil es unsicheren, aber legitimen Vorgängen einen Weg nach vorn eröffnet, ohne ihnen stille Autonomie zu gewähren.

Zu viele ASK-Entscheidungen führen zu Genehmigungsmüdigkeit. Operatoren könnten Anfragen genehmigen, ohne Grund, Ziel oder betroffene Daten zu prüfen. Zu wenige ASK-Entscheidungen verschieben mehrdeutige Vorgänge in Richtung automatischer Erlaubnis oder unnötiger Ablehnung.

Die Richtlinie beurteilt zudem Tool-Aufrufe, nicht jede Folge eines erlaubten Aufrufs. Databricks weist ausdrücklich darauf hin, dass Intent begrenzt, welche Aktionen ausgeführt werden, nicht aber, was durch diese Aktionen übertragen wird.

Ein genehmigtes Dashboard-Update könnte weiterhin vertrauliche Daten enthalten. Eine erlaubte E-Mail-Antwort könnte an den falschen Empfänger gehen. Eine legitime Datenbankabfrage könnte mehr Datensätze zurückgeben, als die Aufgabe erfordert.

Intent-basierte Autorisierung muss daher mit Argumentvalidierung, Data-Loss-Prevention, Zielkontrollen, Ratenbegrenzungen und Auditsystemen zusammenwirken. Ihr Wert liegt darin, Autorisierung um Zweck zu ergänzen, nicht diese Kontrollen zu ersetzen.

OpenAI beschreibt in seiner Analyse zur Agentensicherheit ein verwandtes Quellen-und-Senken-Modell. Ein gefährliches Ergebnis erfordert häufig sowohl vom Angreifer kontrollierte Inhalte als auch eine Fähigkeit, die im falschen Kontext schädlich wird.

Diese Perspektive unterstützt Omnigents Fokus auf die Begrenzung von Aktionen. Sie verdeutlicht auch, warum kein einzelner Klassifikator das Problem lösen kann. Systeme sollten die Folgen von Manipulation begrenzen, selbst wenn sie die bösartige Eingabe nicht erkennen.

Unabhängige Forschung weist in dieselbe Richtung. Die ACL-2025-Arbeit Task Shield bewertet, ob jede Anweisung und jeder Tool-Aufruf zu einem vom Nutzer festgelegten Ziel beiträgt.

Auf dem AgentDojo-Benchmark berichteten die Forschenden mit GPT-4o eine Angriffserfolgsrate von 2,07 Prozent und einen Task Utility von 69,79 Prozent. Diese Ergebnisse gelten für diesen Benchmark und diese Konfiguration, nicht für Omnigents Implementierung.

Der Utility-Wert macht den Zielkonflikt hinter aufgabenorientierten Schutzmaßnahmen sichtbar. Ein System kann Angriffe blockieren und zugleich legitime Arbeit verhindern. Sicherheit verbessert sich nur, wenn die Richtlinie ausreichend Aufgabenabschluss bewahrt, um nutzbar zu bleiben.

Databricks hat für seinen neuen Mechanismus keine vergleichbaren Benchmark-Ergebnisse veröffentlicht. Die Demonstration zeigt ein injiziertes Feld, einen Agenten, drei Tools und einen erklärten Zweck. Sie belegt keine allgemeine Leistung über lange Sitzungen oder mehrdeutige Unternehmensaufgaben hinweg.

Ebenso gibt es bislang keine öffentlichen Belege zu falschen Genehmigungen, falschen Ablehnungen, Evaluator-Latenz oder zum Richtlinienverhalten nach Modellupdates. Diese Messwerte werden darüber entscheiden, ob der Ansatz über überzeugende Beispiele hinausgeht.

Auch Angreifer werden sich anpassen. Sie können injizierte Anweisungen formulieren, die mit der erklärten Aufgabe verbunden wirken. Eine Anweisung könnte behaupten, dass die Gewährung von Zugriff erforderlich sei, um dieselbe untersuchte Tabelle zu verifizieren.

Die veröffentlichte Demonstration nutzt diese Strategie bereits, indem sie den externen Empfänger als Auditor beschreibt. Die Richtlinie blockiert die Gewährung dennoch, weil der genehmigte Intent eng gefasst bleibt; komplexere Aufgaben werden jedoch weniger eindeutige Grenzen erzeugen.

Eine bösartige Anweisung könnte auch Argumente innerhalb eines erlaubten Tools angreifen. Wenn die Sitzung Dashboard-Updates zulässt, könnte ein Angreifer versuchen, vertrauliche Felder in den Dashboard-Inhalt einzufügen. Eine reine Zweckausrichtung auf Tool-Ebene würde diese Variante nicht unbedingt erkennen.

Teams, die Databricks-Berechtigungen bewerten, sollten Richtlinienentscheidungen daher auf mehreren Ebenen testen. Sie benötigen gewöhnliche Anfragen, mehrdeutige Anfragen, injizierte Inhalte, irreführende geschäftliche Begründungen und bösartige Argumente innerhalb erlaubter Vorgänge.

Sie sollten außerdem festhalten, warum jede Entscheidung getroffen wurde. Ein Sicherheitsteam kann inkonsistente Durchsetzung nicht untersuchen, wenn Logs nur ALLOW, ASK oder DENY ohne den relevanten Intent und die vorgeschlagene Aktion enthalten.

Der nützlichste Vergleich lautet nicht Intent-Kontrolle gegen perfekte Sicherheit. Er lautet Intent-Kontrolle gegen reine Identitätsautorisierung innerhalb eines mehrschichtigen Systems.

Unter diesem Vergleich schließt Omnigent eine echte Lücke. Die verbleibende Frage ist, ob Teams den Zweck präzise genug definieren können, um Schutz zu gewinnen, ohne jede nützliche Agentenaktion in eine manuelle Prüfung zu verwandeln.

Drei Signale werden zeigen, ob Omnigents Modell Bestand hat

Die nächste Phase sollte anhand messbarer Durchsetzungsqualität beurteilt werden, nicht anhand der Klarheit der ersten Demonstration.

Das erste Signal ist eine reproduzierbare Evaluierungssuite. Omnigent benötigt Tests über verschiedene Modelle, Harnesses, Tools und indirekte Injection-Strategien hinweg.

Nützliche Ergebnisse würden Angriffserfolg, legitimen Aufgabenabschluss, falsche Genehmigungen, falsche Ablehnungen und Raten menschlicher Eskalation getrennt ausweisen. Sie sollten außerdem zeigen, ob kleine Änderungen der Formulierung zu wesentlich anderen Entscheidungen führen.

Starke Leistungen in adversarialen Tests würden Databricks’ Argument stärken, dass Zweck zu einem verlässlichen Autorisierungseingang werden kann. Hohe Varianz zwischen Modellen oder Prompts würde die Argumentation für modellgestützte Intent-Prüfungen als Durchsetzungsgrenze schwächen.

Das zweite Signal ist ein bereitstellungssicheres Fehlerverhalten. Omnigents Dokumentation besagt, dass die integrierte Richtlinie bei fehlender LLM-Konfiguration offen fehlschlägt.

Nutzer sollten auf Startvalidierung, administrative Warnungen, Fail-Closed-Optionen und klare Auditaufzeichnungen achten, wenn der Evaluator nicht ausgeführt werden kann. Eine kontextbezogene Richtlinie bietet wenig Schutz, wenn Konfigurationsdrift sie unbemerkt entfernen kann.

Ein sichtbarer Umgang mit Evaluator-Ausfällen würde das Design stärken. Anhaltend permissives Verhalten ohne deutliche Warnungen würde eine erhebliche operative Lücke hinterlassen.

Das dritte Signal ist die Akzeptanz außerhalb der Beispiele der Autoren. Reale Teams müssen Richtlinien für Programmierung, Support, Datenoperationen, E-Mail, Kalender und Multi-Agent-Delegation veröffentlichen.

Diese Beispiele sollten zeigen, wie Organisationen Intent für Aufgaben definieren, die sich legitim weiterentwickeln. Sie sollten außerdem offenlegen, wie häufig Nutzer ASK-Aufforderungen erhalten und ob diese Aufforderungen Entscheidungen verbessern.

Eine breitere Nutzung würde das zentrale Versprechen des Designs prüfen: Ein Agent kann nützliche Fähigkeiten behalten und zugleich nur die Teilmenge ausüben, die für die aktuelle Aufgabe erforderlich ist. Wiederholte Richtlinienumgehungen oder unerträgliche Genehmigungsmüdigkeit würden dieses Versprechen schwächen.

Deshalb ist die Omnigent-Veröffentlichung über ein einzelnes Open-Source-Framework hinaus relevant. Agentenentwickler bauen Systeme, die nicht vertrauenswürdige Informationen lesen und über gültige Unternehmenszugangsdaten handeln. Das daraus entstehende Risiko liegt zwischen herkömmlicher Zugriffskontrolle und Modellsicherheit.

Databricks-Berechtigungen werden zu einer zweiteiligen Entscheidung: Darf diese Identität handeln, und dient diese Aktion dem genehmigten Zweck?

Diese zweite Frage wird Prompt Injection nicht beseitigen. Sie schafft einen Punkt, an dem eine injizierte Anweisung gestoppt werden kann, nachdem sie das Modell beeinflusst hat, aber bevor sie ein folgenreiches Tool erreicht.

Entwickler sollten zunächst Aktionen identifizieren, deren Autorisierung sich mit dem Aufgabenkontext verändert. Sicherheitsteams können dann testen, ob Intent-Richtlinien unabhängige Vorgänge ablehnen, mehrdeutige eskalieren und legitime Arbeit bewahren.

Unternehmenskäufer sollten Anbieter nach Belegen für diese drei Ergebnisse fragen. Ein Mechanismus, der alles blockiert, ist keine nützliche Autorisierung. Ein Mechanismus, der jeden Workflow bewahrt und adversariale Anfragen übersieht, ist kein sinnvoller Schutz.

Die praktische Frage ist nun unausweichlich: Wenn ein KI-Agent die Berechtigung besitzt, eine Aktion auszuführen, welche unabhängig durchgesetzten Belege zeigen, dass diese Aktion dem aktuellen Zweck des Nutzers dient?