Oracle Database · · 3 Min.

Deep Data Security in 26ai

Warum Identität und Autorisierung bei AI-Agenten bis in den Database Layer durchgereicht werden müssen.

Veröffentlicht am 26.09.2026 · Verfasst von Veysi Guenay

Traditionelle Anwendungen greifen häufig mit einem technischen Service-Account auf die Datenbank zu. Die Anwendung kennt den Endnutzer und wendet dessen Berechtigungen im Code an. Bei dynamischen AI-Agenten wird dieses Modell schwieriger: Ein Agent kann unterschiedliche Tools, Abfragen und Datenquellen kombinieren. Oracle Deep Data Security in Oracle AI Database 26ai setzt deshalb stärker auf datenbanknahe, identitätsbewusste Autorisierung.

Einordnung: Database-native Security ersetzt kein Identitäts- und Rollenmodell. Sie sorgt dafür, dass die fachliche Autorisierung nicht ausschließlich in jeder einzelnen Anwendung oder jedem Agenten neu implementiert werden muss.

1. Warum die Anwendungsschicht allein nicht genügt

Wenn mehrere Anwendungen, Reports und Agenten auf dasselbe Schema zugreifen, entstehen schnell unterschiedliche Regeln für dieselbe Person. Ein Fehler im Prompt, ein neues Tool oder ein zusätzlicher Service kann dann zu einem Datenzugriff führen, den die ursprüngliche Anwendung nicht vorgesehen hat.

Eine Datenbankregel bildet eine zweite, zentrale Kontrollschicht. Sie kann sicherstellen, dass der Zugriff weiterhin an die Identität, Rolle oder den Kontext des Endnutzers gebunden bleibt – auch wenn die Anfrage über eine neue Anwendung oder einen AI-Workflow kommt.

2. Identität bis zur Abfrage erhalten

Für einen wirksamen Schutz muss die Identität des Endnutzers vom Authentifizierungs- und Anwendungskontext bis zur Datenbank gelangen. Der technische Service-Account darf nicht die einzige Information sein, die die Datenbank sieht. Ansonsten kann eine Policy nur die Anwendung, nicht aber die konkrete Person bewerten.

Planen Sie deshalb die Identitätsweitergabe, Rollen, Session-Kontext und Audit-Anforderungen gemeinsam. Testen Sie ausdrücklich mehrere Zugriffspfade: APEX, ORDS, Batch-Prozess, BI-Tool und AI-Agent sollten für dieselbe Person konsistente Ergebnisse liefern.

3. Agenten mit Least Privilege begrenzen

Agenten benötigen häufig Zugriff auf Daten, dürfen aber nicht automatisch alle Aktionen ausführen. Deep Data Security unterstützt das Prinzip, dass Anwendungen und Agenten nur die Daten und Operationen erhalten, die für den konkreten Zweck erforderlich sind. Für sensible Aktionen kann eine kontrollierte, zeitlich begrenzte Privileg-Erhöhung vorgesehen werden.

Ein gutes Modell trennt Lesen, Ändern und administrative Tätigkeiten. Zusätzlich sollten Tools nur erlaubte Parameter akzeptieren und fachliche Prüfungen nicht allein dem Sprachmodell überlassen. Die Datenbank bleibt die letzte Instanz für die Frage, ob eine Operation zulässig ist.

4. Einführungsplan für DBAs

  1. Schutzobjekte und Datenklassen identifizieren, die von Agenten oder mehreren Anwendungen genutzt werden.
  2. Rollen, Identitätsattribute und bestehende VPD-, Database-Vault- oder Authorization-Scheme-Regeln inventarisieren.
  3. Einen Read-only-Anwendungsfall mit einem kleinen, nichtkritischen Datenbereich als Pilot auswählen.
  4. Ergebnisse für denselben Nutzer über APEX, API und Agent vergleichen und im Audit nachvollziehen.
  5. Schreibende Aktionen erst nach Policy-, Tool-, Freigabe- und Recovery-Tests aktivieren.
Praxisregel: Testen Sie nicht nur „darf Benutzer A Tabelle X sehen?“, sondern auch „sieht Benutzer A über jeden Agenten, jedes Tool und jeden alternativen Zugriffspfad dieselben erlaubten Zeilen?“

Fazit

Deep Data Security in Oracle AI Database 26ai adressiert ein zentrales Problem agentischer Anwendungen: Die Datenbank muss die Identität und Autorisierung des Endnutzers auch dann durchsetzen, wenn die Anfrage dynamisch entsteht. Für DBAs bedeutet das eine zentrale, auditierbare Schutzschicht, die Anwendungen und AI-Agenten auf Least Privilege verpflichtet.

Weiterführend: Oracle: Deep Data Security für AI-Agenten, der Produktüberblick und die Security-Dokumentation für AI Database 26ai.