AWS’ TOLAP bringt objektbezogene Zugriffskontrolle in Werkzeuge für KI-Agenten

Das entscheidende Detail an AWS’ neuem TOLAP-Projekt ist nicht das Akronym, sondern die Stelle, an der die Durchsetzung ansetzt.

AWS Labs hat TOLAP, das für „Tool-Object Level Access Protocol“ steht, als Open-Source-Sicherheitsschicht für Werkzeuge von KI-Agenten veröffentlicht. Das Projekt soll entscheiden, welche Daten ein Werkzeug verlassen dürfen, nachdem ein Agent es aufgerufen hat: Welche Zeilen sind sichtbar? Welche Felder werden verborgen oder maskiert? Welche Endpunkte sind erlaubt? Wie viele Ergebnisse dürfen zurückgegeben werden? Und liegt die angeforderte Aktion noch innerhalb des Zwecks, für den eine Delegation erteilt wurde? Die erste öffentliche Version zeigt, dass sich die Agentensicherheit von einer einfachen Frage wegbewegt – „Darf diese Identität diese API aufrufen?“ – hin zu einer schwierigeren: „Was genau darf dieser konkrete Aufruf offenlegen oder verändern?“

Das ist für Teams relevant, die Agenten über Datenbanken, interne APIs, Wissensbestände, Objektspeicher und MCP-Server bauen. Eine gewöhnliche Berechtigungsprüfung kann eine Verbindung autorisieren und dem Werkzeug trotzdem erlauben, deutlich mehr Daten zurückzugeben, als der Nutzer oder der Workflow benötigt. TOLAP schlägt vor, die Funktion, die Daten tatsächlich abruft oder verändert, mit einer Richtlinienhülle zu versehen und die Richtlinie durchzusetzen, bevor das Ergebnis in den Kontext des Agenten gelangt.

Das Projekt ersetzt weder Identitätsverwaltung noch Netzwerkkontrollen, Datenbankberechtigungen oder menschliche Freigaben. Es ist eine enger gefasste Kontrolle, die die Lücke zwischen Werkzeugzugriff und objektbezogener Offenlegung schließen soll.

Was AWS veröffentlicht hat

AWS Open Source beschreibt TOLAP als Durchsetzungsschicht am Datenquellpunkt. Das Repository steht unter der Apache-2.0-Lizenz bereit und enthält ein Richtlinienschema, Durchsetzungsbibliotheken für .NET, Python und TypeScript, einen Referenz-Richtlinienserver, Beispiele, Dokumentation sowie Integrationen für verbreitete Agenten- und Werkzeug-Frameworks.

Das zentrale Modell ist deklarativ. Eine Richtlinie kann erlaubte Objekte und Aktionen benennen, ausgewählte Felder verbergen, Werte maskieren, Zeilen filtern, Speicherpräfixe oder API-Methoden einschränken, Ergebnisgrenzen anwenden und Prüfvermerke anhängen. Die Beispiele verwenden einen Datensatz im Gesundheitswesen: Ein Agent darf Patientenakten abfragen, erhält aber keine Sozialversicherungsnummern; E-Mail-Adressen können als Hashes zurückgegeben werden; und Zeilen lassen sich auf bestimmte Regionen begrenzen.

Das unterscheidet sich davon, dem Agenten einen Datenbankzugang mit weitreichenden Leserechten zu geben und darauf zu hoffen, dass das Modell verantwortungsvoll handelt. Im TOLAP-Modell kann der Agent weiterhin über das Werkzeug eine Abfrage erstellen, doch die Hülle wendet die wirksame Richtlinie auf das Ergebnis an. Daten, die von der Richtlinie abgelehnt werden, werden entfernt, bevor sie Teil des Modellkontexts werden.

AWS zufolge verwenden die SDKs ein versioniertes gemeinsames Richtlinienschema und gemeinsame Test-Fixtures. Dadurch sollen sich die Implementierungen über verschiedene Sprachen hinweg gleich verhalten. Das Repository enthält außerdem Integrationen für MCP-SDKs, Strands, LangChain, LangChain.js, das Vercel AI SDK, Mastra, OpenAI Agents, Pydantic AI, Semantic Kernel und Bedrock Agents. Diese Integrationen machen TOLAP nicht zu einem MCP-Server. Das Projekt umhüllt die Funktion, die von der Werkzeugebene verwendet wird; die Anwendung bleibt für den Datenabruf zuständig.

Für den Produktionseinsatz enthält das Repository einen von PostgreSQL unterstützten Richtlinienserver, unveränderliche Richtlinienversionen, Veröffentlichungs- und Rollback-Vorgänge, ein Prüfprotokoll, eine durch Cognito authentifizierte Verwaltung sowie die Rotation von Signaturschlüsseln mit einem Überschneidungsfenster. Diese Komponenten sind Referenzinfrastruktur und kein Beleg dafür, dass jede Organisation den gesamten Stack einsetzen sollte.

Warum gewöhnliche Werkzeugautorisierung nicht genügt

Die meisten Agentenarchitekturen verfügen bereits über mehrere Berechtigungsebenen. Ein Nutzer authentifiziert sich bei einer Anwendung. Die Anwendung gibt einem Agenten eine Dienstidentität oder ein delegiertes Token. Ein Gateway prüft das Token. Das Werkzeug ruft eine Datenbank oder API auf. Jede Ebene ist nützlich, doch keine beantwortet automatisch die objektbezogene Frage.

Nehmen wir einen internen Support-Agenten, der eine Kundentabelle abfragen darf. Eine Rollenprüfung kann korrekt feststellen, dass die Supportanwendung das Kundensuchwerkzeug aufrufen darf. Daraus folgt aber nicht automatisch:

• welche Kunden der anfragende Mitarbeiter sehen darf;
• welche Spalten ausgelassen werden müssen;
• ob Ergebnisse Kunden außerhalb der Region des Mitarbeiters enthalten dürfen;
• ob eine Adresse vollständig zurückgegeben werden darf;
• ob die Abfrage 5.000 Zeilen liefern darf;
• ob aus einem Lesevorgang unbemerkt ein Exportvorgang geworden ist.

Ein Gateway kann den Endpunkt autorisieren. Eine Datenbank kann Berechtigungen durchsetzen. Eine Anwendung kann Antworten filtern. Wenn diese Entscheidungen jedoch über eigenen Code verteilt sind, wird die wirksame Grenze schwer zu erfassen und zu testen. Je mehr Frameworks, Konnektoren und Agentenlaufzeiten eine Organisation hinzufügt, desto leichter kann ein Pfad eine Prüfung auslassen.

TOLAP argumentiert architektonisch, dass das Werkzeug der letzte verlässliche Ort ist, um zu verhindern, dass Daten in den Agentenkontext gelangen. Anweisungen im Prompt sind keine Sicherheitsgrenze. Ein Modell kann eine Regel missverstehen, einer bösartigen Anweisung in abgerufenen Inhalten folgen oder einzelne erlaubte Ergebnisse zu einer Offenlegung kombinieren, die der Entwickler nicht erwartet hat. Wenn ein sensibles Feld die Hülle nie passiert, kann das Modell es nicht aus seinem Kontext zurückgewinnen.

Das macht das Werkzeug nicht automatisch vertrauenswürdig. Die Hülle muss der einzige Weg zur geschützten Quelle sein, und die Anwendung muss verhindern, dass alternative Zugangsdaten oder nicht umhüllte Codepfade dieselben Daten erreichen. Durchsetzung am Quellpunkt ist nur dann hilfreich, wenn dieser Quellpunkt tatsächlich kontrolliert wird.

Die Veröffentlichung umfasst mehr als Zeilen- und Feldfilter

Die objektbezogenen Kontrollen der ersten Version sind der unmittelbar verständlichste Teil des Projekts. Die neueren Materialien beschreiben außerdem Kontrollen für Zweck und Abfolge von Agentenaktionen.

TOLAP-Richtlinien können Zweckprofile enthalten, die festlegen, welche Richtlinie für eine Anfrage gilt. Die Aktionsvalidierung prüft anschließend, ob ein Werkzeugaufruf zur erlaubten Aktionsmenge gehört. Ist eine verbotene Aktion enthalten, wird sie abgelehnt. Gibt es eine Liste erlaubter Aktionen und steht die angeforderte Aktion nicht darauf, wird sie ebenfalls abgelehnt.

Das Projekt beschreibt außerdem die Validierung von Delegationsketten. Das ist wichtig, wenn ein Agent einen anderen Agenten aufruft oder ein Workflow Befugnisse über mehrere Dienste weitergibt. Eine nachgelagerte Komponente sollte nicht stillschweigend umfassendere Rechte erhalten als durch die vorgelagerte Genehmigung vorgesehen. In einer gut entworfenen Kette bewahrt jede Delegation den Umfang oder schränkt ihn ein; die resultierende Entscheidung bleibt der ursprünglichen Autorität zuordenbar.

Die Reihenfolge zählt. Die Zweckfilterung wählt die anwendbare Richtlinie. Die Aktionsvalidierung prüft, was das Werkzeug tun soll. Die objektbezogene Durchsetzung kontrolliert danach, welche Daten zurückgegeben oder verändert werden dürfen. Jede Stufe wird als ausfallsicher im Sinne von „fail closed“ und unabhängig testbar beschrieben.

AWS dokumentiert außerdem eine optionale Ebene zur semantischen Abstimmung, die ein LLM als Prüfer verwendet. Das ist der empfindlichste Teil des Entwurfs. Deterministische Regeln können Tabelle, Feld, Zeilenfilter, Aktion oder Endpunkt prüfen. Sie können jedoch nicht immer feststellen, ob eine Folge einzeln gültiger Abfragen mit dem erklärten Zweck vereinbar ist. Ein Prüfer kann Zweckbeschreibung, aktuellen Werkzeugaufruf und ein Zeitfenster der jüngeren Historie betrachten und abhängig von Konfidenzschwellen erlauben, blockieren oder eskalieren.

Das Projekt setzt diesen Prüfer hinter die deterministische Durchsetzung und nicht davor. Diese Reihenfolge ist plausibel: Ein Modell sollte ein zweites Modell nicht dazu überreden können, ein Feld offenzulegen, das eine strukturelle Richtlinie bereits verbietet. Der Prüfer ist optional und standardmäßig deaktiviert; sein Prompt wird von einem Administrator kontrolliert und kann vom Agenten nicht geändert werden.

Organisationen sollten den Prüfer als zusätzliches Signal und nicht als Ersatz für deterministische Zugriffskontrolle behandeln. Seine Ausgabe ist probabilistisch, seine Konfiguration muss evaluiert werden, und unklare Fälle brauchen einen ausdrücklich definierten Prüfpfad. Die stärkste Grenze dieser Veröffentlichung bleibt die gewöhnliche: Daten, die die Richtlinie verbietet, werden nicht zurückgegeben.

Was sich für MCP- und Agentenwerkzeug-Teams ändert

Die praktische Wirkung ist für Teams am größten, die schneller Werkzeuge hinzufügen, als sie ihr Autorisierungskonzept weiterentwickeln.

MCP macht es vergleichsweise einfach, Fähigkeiten für ein Modell bereitzustellen. Die Sicherheitsfrage lautet nicht nur, ob der Server eine Authentifizierung verlangt. Ebenso wichtig ist, ob jedes Werkzeug einen engen Datenvertrag besitzt und ob der Server das Ergebnis filtert, bevor Client oder Modell es sehen. Ein Werkzeug, das ein uneingeschränktes Datenbankergebnis zurückgibt, bleibt weitreichend, auch wenn die MCP-Verbindung ein kurzlebiges Token verwendet.

Dasselbe Problem tritt außerhalb von MCP auf. Ein OpenAI-Agents-Werkzeug, ein LangChain-Retriever, eine Aktionsgruppe eines Bedrock Agent, ein Endpunkt für Function Calling oder ein eigener Python-Wrapper kann unbeabsichtigt zur Offenlegungsgrenze werden. TOLAP setzt bewusst unterhalb des Modell-Frameworks an: Die Richtlinie wird um die Funktion gelegt, die mit der Quelle spricht. So bleibt das Durchsetzungsmodell erhalten, wenn sich die Orchestrierungsebene ändert.

Diese Trennung bringt einen betrieblichen Vorteil. Teams können das Sicherheitsverhalten prüfen, ohne zugleich testen zu müssen, ob das Modell Anweisungen befolgt. Ein Richtlinientest kann feststellen, dass eine verbotene Spalte fehlt, ein Zeilenfilter angewendet wird, eine Ergebnisgrenze eingehalten wird und eine verbotene Aktion scheitert. Das sind gewöhnliche Software- und Sicherheitstests. Anschließend kann das Modell auf dem bereits verkleinerten Ergebnissatz auf seine Nützlichkeit geprüft werden.

Es gibt einen Zielkonflikt. Eine Hülle an der Werkzeuggrenze sieht, was das Werkzeug zurückgibt, versteht aber möglicherweise nicht jede geschäftliche Bedeutung der Daten. Eine Richtlinie kann ein Feld verbergen und eine Region filtern. Schwieriger kann es sein, auszudrücken, dass „diese fünf erlaubten Abfragen zusammen eine verbotene Schlussfolgerung ermöglichen“, ohne Historie zu führen oder eine semantische Prüfstufe hinzuzunehmen. Deshalb sollten die deterministischen und semantischen Ebenen als Ergänzung und nicht als austauschbare Lösungen verstanden werden.

Grenzen, die weiterhin bei der Anwendung liegen

TOLAP beseitigt den Bedarf an herkömmlichen Sicherheitskontrollen nicht.

Identität bleibt wichtig. Die Richtlinie braucht ein verlässliches Subjekt, eine Gruppe, Rolle, ein Dienstkonto oder einen delegierten Principal. Wenn jede Anfrage mit derselben überprivilegierten Dienstidentität eintrifft, haben objektbezogene Regeln möglicherweise zu wenig Kontext für eine sinnvolle Entscheidung.

Auch das Zugangsdaten-Design bleibt wichtig. Ein umhülltes Werkzeug sollte keine Zugangsdaten besitzen, mit denen es die Hülle umgehen und direkt auf die Quelle zugreifen kann. Kurzlebige Zugangsdaten, eingeschränkte Rollen, Netzwerkbeschränkungen, Geheimnisrotation sowie getrennte Identitäten für Entwicklung und Produktion bleiben grundlegende Kontrollen.

Das Quellsystem bleibt wichtig. Row-Level Security in Datenbanken, API-Autorisierung, Speicherregeln und Geschäftslogik auf Anwendungsebene sollten weiterhin ihre eigenen Grenzen durchsetzen. TOLAP kann die Datenmenge reduzieren, die ein Agent erhält, sollte aber nicht der einzige Schutz für eine kritische Datenbank oder eine nicht rückgängig zu machende Operation sein.

Auch das Freigabedesign bleibt wichtig. Das Verbergen von Feldern macht eine destruktive Aktion nicht sicher. Das Löschen eines Datensatzes, die Änderung einer Zahlung, die Rotation eines Schlüssels oder die Bereitstellung von Code kann eine menschliche Freigabe, ein Vier-Augen-Prinzip, eine Transaktionsvorschau oder einen umkehrbaren Workflow erfordern. TOLAPs Aktionsvalidierung kann Aufrufe außerhalb eines Umfangs ablehnen; eine erlaubte Aktion kann dennoch zu folgenreich sein, um automatisch ausgeführt zu werden.

Die Beobachtbarkeit bleibt wichtig. Das nützliche Prüfereignis lautet nicht nur „Werkzeug aufgerufen“. Es sollte die Person oder den Dienst, der die Befugnis delegiert hat, die Agentenidentität, den Zweck, das Werkzeug, die wirksame Richtlinienversion, den Datenumfang, die Ergebnisgröße, die Entscheidung und jede Freigabe miteinander verbinden. Ohne diesen Kontext wissen Incident-Responder womöglich, dass eine Abfrage lief, aber nicht, warum sie erlaubt war.

Schließlich bleibt Governance wichtig. Richtlinien brauchen Verantwortliche, Ablaufdaten, Prüftrigger, Versionskontrolle, Rollback und Tests, die bei Änderungen an einem Konnektor laufen. Eine Richtlinienhülle kann ein falsches Sicherheitsgefühl erzeugen, wenn niemand prüft, ob das zugrunde liegende Werkzeug einen neuen Parameter oder einen neuen Weg um die Durchsetzungsfunktion herum erhalten hat.

Ein sinnvoller Evaluierungsplan

Teams müssen nicht den gesamten TOLAP-Stack übernehmen, um aus der Veröffentlichung zu lernen. Der Entwurf legt eine praktische Prüfung bestehender Agentenwerkzeuge nahe.

Zuerst sollten die tatsächlichen Datenpfade erfasst werden. Für jedes Agentenwerkzeug gilt es, die Funktion zu identifizieren, die die Quelle liest oder verändert, die verwendeten Zugangsdaten, alternative Zugriffswege und den Punkt, an dem das Ergebnis für das Modell sichtbar wird. Zeichnet den Weg von der Nutzeranfrage über den Werkzeugaufruf bis zur Antwort der Quelle. Wenn ein Team den Durchsetzungsort nicht benennen kann, kann es die Grenze wahrscheinlich auch nicht nachweisen.

Danach sollten Fähigkeitsautorisierung und Datenautorisierung getrennt werden. „Der Agent darf die Kundensuche verwenden“ ist eine Aussage über eine Fähigkeit. „Der Agent darf die diesem Mitarbeiter zugeordneten Kunden sehen, ohne Geburtsdatum und mit maskierter E-Mail-Adresse“ ist eine Datenrichtlinie. Beide Aussagen sollten in testbarer Form vorliegen.

Anschließend braucht es Negativtests. Es sollte geprüft werden, ob die Hülle eine verbotene Tabelle blockiert, ein eingeschränktes Feld entfernt, Zeilen außerhalb des erlaubten Umfangs filtert, sensible Werte maskiert, ungewöhnlich breite Antworten begrenzt, eine nicht genehmigte Aktion ablehnt und bei einem Fehler bei Richtlinienauflösung oder Signatur standardmäßig verweigert. Testet den direkten Zugriff mit den Zugangsdaten des Werkzeugs ebenso wie den normalen Weg über den Agenten.

Testet nicht nur einzelne Aufrufe, sondern auch deren Kombination. Ein Modell kann sensible Informationen über mehrere harmlos wirkende Abfragen erhalten oder Befugnisse von einem Agenten an einen anderen weitergeben. Sequenzen, Delegationsänderungen und wiederholte Exporte sollten protokolliert und überprüft werden. Wenn der Geschäftszweck entscheidend ist, sollte festgelegt werden, wann eine Sequenz menschliche Prüfung benötigt, statt jede Interpretation in einen Prompt pressen zu wollen.

Zum Schluss sollte der Entwicklungsaufwand gemessen werden. Eine Sicherheitsschicht, die zu schwer zu integrieren ist, wird umgangen. Die entscheidende Frage lautet nicht, ob eine Hülle jede denkbare Richtlinie ausdrücken kann. Entscheidend ist, ob die Organisation für jeden unterstützten Konnektor und jedes Framework den sicheren Weg zum einfachsten Weg machen kann.

Warum diese Veröffentlichung beobachtenswert ist

TOLAP ist eine frühe Open-Source-Antwort auf ein Problem, das viele Agenteneinsätze derzeit mit verstreuter Middleware und Konventionen lösen. Der wichtigste Beitrag ist konzeptionell: Der Zugriff auf ein Werkzeug ist nicht dasselbe wie die Autorisierung für jedes Objekt, das dieses Werkzeug erreichen kann.

Diese Unterscheidung wird dringlicher, wenn Agenten sich von der Gesprächssuche zu Workflows bewegen, die Produktionssysteme abfragen, private Datensätze zusammenfassen, APIs aufrufen und Aufgaben an andere Agenten delegieren. Bestehende Identitätsplattformen bleiben notwendig; Anbieter ergänzen Agentenidentitäten, bedingten Zugriff und Richtlinienkontrollen. Doch eine Identität auf der äußeren Ebene begrenzt nicht automatisch die Form eines Ergebnisses auf der inneren Ebene.

Das Projekt sollte als Infrastruktur und nicht als fertiges Sicherheitssiegel bewertet werden. Lest das Bedrohungsmodell. Prüft, ob jeder Quellpfad umhüllt ist. Bewertet das Richtlinienschema und das Fehlerverhalten. Führt die Beispiele mit repräsentativen Daten aus. Prüft, ob Lizenz, Abhängigkeiten, unterstützte Laufzeiten und Betriebsmodell zur Organisation passen. Behandelt den optionalen LLM-Prüfer als Hilfsmittel für Reviews, das eine eigene Validierung benötigt.

Der unmittelbare Rat für Plattform- und Sicherheitsteams ist klar: Für jedes Agentenwerkzeug, das sensible Daten berührt, sollte vorab der kleinste nützliche Ergebnissatz definiert werden. Diese Definition muss am Datenrand im Code durchgesetzt werden; die Zugangsdaten dürfen sie nicht umgehen können; und es muss festgehalten werden, welche Richtlinie die Entscheidung getroffen hat. AWS’ TOLAP-Veröffentlichung liefert ein konkretes Open-Source-Projekt, das Teams untersuchen können, und macht diese Architektur leichter besprechbar.

Das ist die eigentliche Veränderung: Die Sicherheitsgrenze eines KI-Agenten ist nicht nur die Identität, die eine Anfrage startet. Sie ist auch die Funktion, die entscheidet, was in den Kontext des Agenten gelangen darf.

Quellen

Die Übersetzung und Einordnung stützen sich auf die im Ausgangsartikel genannten Quellen: den AWS Open Source Blog mit dem Beitrag „Introducing TOLAP: object-level access control for AI agent tools“, das AWS-Labs-Repository „TOLAP – Tool-Object Level Access Protocol“ und dessen Architekturdokumentation. Als Kontext wurden außerdem Microsoft Learn zur Sicherheit von KI-Agenten, das NIST-NCCoE-Papier zu Identität und Autorisierung für Software- und KI-Agenten, die arXiv-Arbeit „Authorization Architectures for Tool-Using AI Agents“ sowie die genannte Diskussion auf Reddit aufgeführt.