Sicherheitsbetrachtungen

Geltungsbereich: In diesem Dokument werden Sicherheitsaspekte im Zusammenhang mit dem Python-SDK von Oracle AI Agent Memory behandelt. Sie gilt nur für Anwendungen, die entweder die Active-Memory-Features des SDK oder die Speicherebene verwenden.

Warum es darauf ankommt: Oracle AI Agent Memory kann Threadinhalte, Bilder und Speicherdatensätze in Oracle AI Database persistieren und, wenn LLM-backed-Features aktiviert sind, Inhalte an konfigurierte Modellendpunkte für die Generierung, Zusammenfassung, Speicherextraktion oder Einbettung von Bildern senden. Ein sicheres Deployment hängt daher von der sorgfältigen Verarbeitung von Anwendungsdaten, dem Abrufumfang, dem Datenbankzugriff, externen Modellendpunkten und Aufbewahrungs-Policys ab.

Überlegungen zur Verarbeitung von LLM-gesichertem Speicher

Oracle AI Agent Memory unterstützt Active-Memory-Features wie Image-Beschreibungsgenerierung, Thread-Zusammenfassung und automatische Speicherextraktion. Wenn diese Features aktiviert sind, kann das SDK Imagebytes, aktuelle Nachrichten, Threadzusammenfassungen, abgerufene Speicher oder Suchtext an den konfigurierten LLM- oder Einbettungsendpunkt senden. Die Bildbeschreibungs- und Extraktionsmodi, die bestimmen, wann Bildbytes an das konfigurierte LLM gesendet werden, finden Sie unter Images und multimodale Nachrichten verwenden.

Wichtig: Senden Sie nur Inhalte an Oracle AI Agent Memory, die für den konfigurierten Modellendpunkt und Ihre Deployment-Policys geeignet sind. Wenn active-memory für Daten aktiviert ist, die anscheinend Secrets, Zugangsdaten oder unnötige sensible Daten enthalten, minimieren oder verdecken Sie diesen Inhalt, bevor Nachrichten in die Speicherpipeline gelangen. Behandeln Sie extrahierte Speicher, Zusammenfassungen, Kontextkarten und anderen vom Modell abgeleiteten Text als nicht vertrauenswürdige Ausgabe, die von der integrierenden Anwendung sicher geprüft und verarbeitet werden muss.

Warnung: Der vom Modell abgeleitete Text kann zu einem persistenten Speicherstatus werden. Wenn automatische Extraktions-, Zusammenfassungs- oder Kontextkartenfunktionen aktiviert sind, kann eine Zusammenfassung, ein extrahierter Speicher oder ein abgerufener Datensatz vom SDK in spätere Prompts wie Speicherextraktion, Zusammenfassung, Kontextkarte oder Agent-Prompts eingefügt werden, bevor die Anwendung diesen bestimmten Zwischenwert prüfen kann. Behandeln Sie dies als normalen, nicht vertrauenswürdigen LLM-Datenfluss: Prüfen und validieren Sie die Ausgaben, die Ihre Anwendung verbraucht, und lassen Sie nicht zu, dass vom Speicher abgeleiteter Inhalt privilegierte Aktionen autorisiert oder die Policy umgeht.

Befolgen Sie diese Empfehlungen, wenn Sie Active-Memory-Features verwenden:

• Anwendungsdaten validieren und minimieren: Prüfen Sie, welche Nachrichten, Metadaten und IDs Ihre Anwendung an das SDK sendet. Vermeiden Sie die Weitergabe von mehr Daten, als der Speicher-Workflow benötigt.
• Trusted Model-Endpunkte verwenden: Konfigurieren Sie LLM und Einbettungsendpunkte, die Ihren Anforderungen an Transportsicherheit, Datenresidenz, Aufbewahrung und Betriebsüberwachung entsprechen.
• Generierten Speicher als Anwendungsdaten und nicht vertrauenswürdige Ausgabe behandeln: Extrahierte Speicher, Zusammenfassungen und Kontextkarten sind abgeleitete Ausgaben. Überprüfen Sie, wie Ihre Anwendung sie verwendet, insbesondere bevor sie privilegierte Aktionen, externe Toolanrufe oder kundensichtbare Entscheidungen beeinflussen.
• Account für persistente Prompt-Injection: Vom Aufrufer bereitgestellter, abgerufener oder vom Modell abgeleiteter Text, der im Speicher gespeichert ist, kann in spätere Zusammenfassungs-, Extraktions-, Kontextkarten- oder Agent-Prompts wiedergegeben werden. Prompt-Trennzeichen, Escape- und Extraktionsanweisungen können die Modelleingabe strukturieren, sind jedoch keine Sicherheitsgrenze. Prüfen Sie extrahierte Speicher, Zusammenfassungen, Kontextkarten und anderen persistenten oder an die Eingabeaufforderung gebundenen Zwischentext, bevor Sie sich darauf verlassen. Wenn Ihr Workflow eine Überprüfung erfordert, bevor modellbasierter Text die zukünftige Extraktion oder Kontextkonstruktion beeinflussen kann, deaktivieren Sie die automatische Extraktion und verwenden Sie explizite Speicherschreibvorgänge oder ein anderes anwendungsgesteuertes Prüfgate.
• Abgeleiteten Text für das Ziel "Sanitisieren" oder "Escape" verwenden: Wenn extrahierte Speicher, Zusammenfassungen, Kontextkarten oder anderer vom Modell abgeleiteter Text in HTML, Markdown, Vorlagen, Logs oder anderen Ausgabeoberflächen gerendert werden, wenden Sie kontextbezogene Escaping oder Desinfektion an. Verwenden Sie dieselbe Sorgfalt, bevor Sie abgeleiteten Text in nachgelagerten Prompts, Werkzeugeingaben, Befehlen oder anderen interpretatorähnlichen Kontexten wiederverwenden.
• Wählen Sie den richtigen Betriebsmodus aus: Wenn Ihre Anwendung geprüft werden muss, bevor vom Modell abgeleiteter Text die spätere Extraktion oder Kontexterstellung beeinflussen kann, sollten Sie explizite Speicherschreibvorgänge, Nur-Speicher-Integrationen oder memory_extraction_config=MemoryExtractionConfig(extract_memories=False) für Workflows verwenden, die keine automatische Extraktion durchführen sollten.

Überlegungen zu Persistenz und Datenminimierung

Oracle AI Agent Memory ist so konzipiert, dass Nachrichten, Speicher, Metadaten und Einbettungen in Oracle AI Database persistiert werden, wenn der DB-gestützte Speicher verwendet wird. Dies ermöglicht einen dauerhaften Abruf und einen Speicher für mehrere Sitzungen, aber es bedeutet auch, dass die Anwendung planen sollte, welche Daten aufbewahrt werden sollten.

Die folgende Anleitung hilft dabei, Deployments an sicheren Datenbehandlungspraktiken auszurichten:

• Persistieren Sie bei der Nur-Shop-Nutzung nur das, was benötigt wird: Entwerfen Sie Ihre Anwendung so, dass nur nützliche, geschäftsgerechte Inhalte in den Arbeitsspeicher geschrieben werden.
• Wenn Active-Memory-Features aktiviert sind, abgeleitete Datensätze planen: Neben vom Aufrufer bereitgestellten Inhalten wie Nachrichten, Bildern und Metadaten kann ein Workflow auch generierte Bildbeschreibungen, extrahierte Speicher, Zusammenfassungen oder Einbettungen beibehalten.
• Schreibfähige Speicherpfade als vertrauenswürdig behandeln: Datenbankzugangsdaten und Backend-Codepfade, die Nachrichten, Zusammenfassungen, Speicher, Metadaten, Einbettungen oder Thread-Laufzeitstatus schreiben können, können sich auf zukünftige Eingabeaufforderungen und Abrufergebnisse auswirken. Active-Memory-Features persistieren absichtlich den vom Modell abgeleiteten Status. Wenn dies nicht für einen Workflow geeignet ist, deaktivieren Sie die automatische Extraktion, oder verwenden Sie eine Store-Only-/Manual-Write-Integration mit engeren Anwendungssteuerelementen.
• Wählen Sie den richtigen Löschbereich für Aufbewahrungsarbeiten aus: delete_message() entfernt nur den Raw-Nachrichtendatensatz. Abgeleitete Speicher oder andere nachgelagerte Thread-bezogene Artefakte, die aus dieser Nachricht erstellt wurden, können weiterhin durchsucht werden, da extrahierte Speicher derzeit nicht pro Nachrichtenherkunft beibehalten werden. Wenn Sie eine Thread-bezogene Bereinigung benötigen, die auch verknüpfte Speicher und verwaltete Abrufdaten entfernt, verwenden Sie OracleAgentMemory.delete_thread().
• Grenze zum Löschen und Herunterfahren für Hintergrundarbeit planen: Methoden zum Löschen von Clients und Threads warten bis zu 300 Sekunden auf die relevante Hintergrundspeicherextraktion und Bildbeschreibungsgenerierung, die bereits von derselben OracleAgentMemory-Instanz akzeptiert wurden, bevor das Warten beginnt. delete_thread(), delete_message() und Thread-Ebene delete_memory() warten auf ihren Thread. delete_memory() auf Clientseite wartet nur, wenn das gespeicherte Ziel einen Thread-Geltungsbereich hat. delete_user() und delete_agent() warten auf bekannte Threads im Eigentümer, unabhängig davon, ob die kaskadierende Bereinigung aktiviert ist oder nicht. Ein Timeout löst TimeoutError aus, ohne den Löschvorgang auszuführen. Diese Waits und veraltete Image-Beschreibungsprüfungen sind keine globalen Nebenläufigkeitsbarrieren für andere Clientinstanzen oder -prozesse, und gleichzeitige Schreibvorgänge beim Löschen werden nicht unterstützt. Bevor ein anderer Client oder Prozess ein Image aktualisiert oder löscht, dessen Beschreibung im Hintergrund generiert wird, stellen Sie sicher, dass wait_for_memory_extraction() auf der ursprünglichen Instanz zurückgegeben wurde. Verwenden Sie dieselbe Wartezeit vor dem Herunterfahren des Prozesses oder zugehörige administrative Vorgänge, wenn alle bereits vom aktuellen Client akzeptierten Hintergrundarbeiten zuerst beendet werden müssen.
• Aufbewahrungs- und Lösch-Policys im Voraus definieren: Wenn Ihre Anwendung Lösch- oder Aufbewahrungszusagen anbietet, stellen Sie sicher, dass sie Raw-Nachrichten, extrahierte Speicher, Metadaten und andere zugehörige Datensätze abdecken, die vom Workflow erstellt wurden. Wählen Sie ttl_days-Werte pro Datensatz und das Schema memory_retention_config basierend auf dem erwarteten Informationstyp in jedem Datensatz, dem Grund, warum die Anwendung sie beibehalten muss, und anwendbaren Aufbewahrungszusagen aus. Verwenden Sie den automatischen Ablauf, wenn Datensätze nach Alter gelöscht werden sollen, und prüfen Sie, ob der verwaltete Oracle-Löschjob in DB-backed Deployments vorhanden ist, insbesondere wenn der Schema-Setupbenutzer keine Scheduler-Jobberechtigungen hat.
• Ladevorgang für Datenbank mit Löschjob planen: Der verwaltete Oracle-Löschjob wird nach einem Zeitplan ausgeführt und löscht abgelaufene Zeilen aus den SDK-verwalteten Tabellen in Batches und nicht als einen großen Löschvorgang. Überwachen Sie die Laufzeit-, Redo-/Undo-Generierung, die übersprungene Ausführungshistorie und das Zeilen-Volume in Umgebungen mit hohen Schreibraten oder großen Ablaufbatches, und passen Sie Aufbewahrungseinstellungen oder operative Rolloutpläne an, wenn sich die Löschaktivität mit latenzabhängigen Datenbank-Workloads überschneiden könnte. Der verwaltete Job legt eine eintägige schedule_limit fest, sodass verzögerte Ausführungen zu lange übersprungen werden können, anstatt willkürlich zu spät zu beginnen.
• Verhindern Sie, dass Sie sich auf Speicher als Quelle der Wahrheit verlassen: Gespeicherte Speicher sollen den Kontext und den Abruf verbessern. Die Anwendungen sollten weiterhin auf verbindliche Systeme für wichtige Entscheidungen zurückgreifen.

Überlegungen zum Abrufumfang und zur Zugriffskontrolle

Oracle AI Agent Memory verwendet die vom Aufrufer bereitgestellten Werte user_id, agent_id und thread_id, um den Abruf zu begrenzen. Dies ist ein leistungsstarkes Filtermodell, aber es sollte nicht das einzige Steuerelement sein, auf das Ihre Anwendung angewiesen ist, wenn sie entscheidet, wie abgerufener Inhalt verwendet oder angezeigt wird.

Standardmäßig verwendet der Thread-Bereichsabruf den exakten Abgleich für user_id und agent_id und eine breitere Übereinstimmung für thread_id, sodass relevante Ergebnisse vergangene Threads für dasselbe Benutzer-Agent-Paar umfassen können. OracleAgentMemory.search()- und search_async()-Aufrufe der obersten Ebene erfordern auch expliziten Benutzergeltungsbereich und exakten Benutzerabgleich. Sie lehnen den ausgelassenen Benutzergeltungsbereich und exact_user_match=False ab, sodass die API des öffentlichen Clients nicht versehentlich über mehrere Benutzer hinweg durchsucht wird. Das Übergeben von user_id=None ist nur mit genauer Benutzerübereinstimmung zulässig, und Ziele sind nur nicht kopierte Datensätze.

Verwenden Sie die folgenden Übungen beim Entwerfen des Abrufs:

• Anwendungsregeln dem Speicherbereich zuordnen: Stellen Sie sicher, dass die Geltungsbereiche, die Ihre Anwendung an das SDK übergibt, mit Ihren Mandanten-, Benutzer- und Datenfreigaberegeln übereinstimmen.
• Bei jeder Clientsuche einen expliziten Benutzergeltungsbereich übergeben: Leiten Sie die user_id aus dem authentifizierten Anforderungskontext und nicht aus der JSON-Anforderung oder einer anderen aufrufergesteuerten Eingabe ab, und geben Sie sie bei jedem Aufruf der obersten Ebene OracleAgentMemory.search() oder search_async() an. Verwenden Sie user_id=None nur für Workflows, die absichtlich auf nicht kopierte Datensätze beschränkt sind.
• Vorziehen Sie den engsten Geltungsbereich, der den Anwendungsfall erfüllt: Verwenden Sie exakte Abgleichs- und engere Filter für Workflows, die vertraulichere Daten verarbeiten.
• Cross-Thread-Abruf absichtlich prüfen: Ein umfassenderer Abruf kann die Kontinuität über Sessions hinweg verbessern. Anwendungen sollten ihn jedoch nur dort aktivieren, wo dieses Verhalten angemessen ist.
• Suchergebnisse als abgerufener Inhalt behandeln, nicht als endgültige Entscheidungen: Zurückgegebene Speicher sind möglicherweise relevant, aber die Anwendung bleibt für die Entscheidung verantwortlich, ob und wie sie angezeigt oder bearbeitet werden sollen.
• Gesicherten Umgang mit abgerufenem Text an der Integrationsgrenze: Abgerufene Datensätze können vom Aufrufer bereitgestellten oder vom Modell abgeleiteten Text enthalten. Wenn abgerufene Speicher oder anderer zurückgegebener Text in HTML, Markdown, Vorlagen, Protokolle oder andere Ausgabeoberflächen gerendert werden, wenden Sie eine kontextbezogene Escape- oder Desinfektion an, bevor Sie sie anzeigen, transformieren oder an nachgelagerte Systeme übergeben.

Für die durch Datenbank erzwungene Endbenutzerautorisierung stellt Oracle Agent Memory auch eine Integration mit Oracle Deep Data Security bereit. Dies ist ein eindeutiges Sicherheitsfeature, das auf Datenbankdatenrollen, Datenzugriffsberechtigungen und Endbenutzersicherheitskontexten basiert. Prüfen Sie die Deep Data Security-API und Sicherheitsreferenz, bevor Sie Policys erteilen oder einen gemeinsamen Laufzeitverbindungspool verwenden. Auf dieser Seite werden auch Unified Auditing und die verschiedenen Gültigkeitszeiten für den Widerruf von Datenbank-Policys und Änderungen der OCI IAM-Gruppenmitgliedschaft dokumentiert.

Überlegungen zu Anwendungsintegration und Caller Trust

Oracle AI Agent Memory kann von der Integrationsanwendung oder einem anderen vertrauenswürdigen Backend-Code aufgerufen werden, nicht direkt von den Endbenutzern. Es handelt sich nicht um eine Sicherheitsgrenze für Endbenutzer, und es führt keine Endbenutzerauthentifizierung oder -autorisierung allein durch. Das Package vertraut dem Aufrufer, dass er für jeden Vorgang den korrekten Geltungsbereich user_id, agent_id, thread_id und Retrieval angibt.

Wichtig: Die integrierende Anwendung ist dafür verantwortlich, den Endbenutzer zu authentifizieren, den Zugriff zu autorisieren und die korrekte user_id und den richtigen Geltungsbereich abzuleiten, bevor sie Oracle AI Agent Memory-APIs aufruft. Ein vom Aufrufer bereitgestelltes user_id ist ein Geltungsbereichswert, kein Identitätsnachweis.

Verwenden Sie die folgenden Übungen, wenn Sie das SDK in eine Agent-Anwendung integrieren:

• user_id als sicherheitsrelevante Anwendungseingabe behandeln: Wenn die integrierende Anwendung user_id aus einer JSON-Anforderung oder einer anderen aufrufergesteuerten Eingabe anstelle eines authentifizierten Kontexts ableitet, kann dies den nutzerübergreifenden Speicherzugriff ermöglichen. Leiten Sie user_id aus dem authentifizierten Anwendungskontext ab, anstatt dass Endbenutzer beliebige Werte auswählen können.
• Anwendungsautorisierung vor jedem Speicheraufruf anwenden: Die integrierende Anwendung muss entscheiden, welche Werte für user_id, agent_id, thread_id und Suchgeltungsbereich für die aktuelle Anforderung gültig sind, und Lese- und Schreibvorgänge innerhalb der beabsichtigten Mandanten- und Benutzergrenze beibehalten.
• Raw-Speicher-APIs für Endbenutzer nicht verfügbar machen: Package-APIs wie add_memory oder Such-Helfer sollten in Anwendungslogik gewrappt werden, die den Aufrufer validiert, die Policy durchsetzt und kontrolliert, welche Daten geschrieben oder zurückgegeben werden können.
• Benutzer-ID-Discovery und Aufzählungsberechtigung beibehalten: Wenn das Package Helfer zum Auflisten oder Auflisten von user_id-Werten hinzufügt, behandeln Sie diese nur als administrative Funktionen und stellen sie Endbenutzern über die integrierende Anwendung niemals zur Verfügung.
• Überschreibungen des Geltungsbereichs sorgfältig prüfen: Jeder Workflow, der den Thread-Geltungsbereich erweitert, den genauen Abgleich deaktiviert oder auf Filial-APIs der unteren Ebene löscht, sollte auf vertrauenswürdige Komponenten beschränkt und auf nutzer- oder mandantenübergreifende Effekte geprüft werden.

Hinweise zur Protokollierung und Diagnose

Oracle AI Agent Memory verwendet Python-Standardlogging und konfiguriert keine Anwendungslog-Handler oder Logebenen für die integrierende Anwendung. Anwendungen können den oracleagentmemory-Logger aktivieren und SDK-Logs über die vorhandene Loggingkonfiguration weiterleiten.

Verwenden Sie die folgenden Vorgehensweisen beim Konsumieren von SDK-Logs:

• Produktions-Deployments auf einer Nicht-DEBUG-Ebene halten: Das DEBUG-Logging ist nur für kontrollierte Entwicklungs- oder Supportdiagnosen gedacht und eignet sich nicht für die Erfassung von Produktionslogs.
• Zugriff auf Diagnoselogs einschränken: Speichern Sie Logs in geschützten Senken mit entsprechenden Policys für Zugriffskontrolle, Aufbewahrung und gemeinsame Nutzung. Prüfen Sie Support-Bundles, bevor Sie Logs außerhalb der Betriebsumgebung senden.
• Vermeiden Sie das Hinzufügen von sensiblem Kontext in Anwendungslogging-Wrappern: Reichern Sie SDK-Logdatensätze nicht mit Prompts, Speicherinhalten, Zugangsdaten, Rohmetadaten, Datenbankzeilenwerten oder aufrufergesteuerten IDs an.
• Logtext als Diagnoseausgabe und keine Auditschnittstelle verarbeiten: Logmeldungen können bei der Fehlerbehebung im SDK-Verhalten helfen. Anwendungen sollten jedoch ihre eigenen expliziten Auditereignisse für Sicherheits- und Complianceworkflows verwenden.

Überlegungen zu Datenbankzugriff, Schemaverwaltung und Secrets

Oracle AI Agent Memory verwendet eine vom Aufrufer bereitgestellte Oracle AI Database-Verbindung oder einen Pool. Das Package erstellt oder verwaltet keine Datenbankzugangsdaten selbst. Außerdem wird keine Datenbanknetzwerkverschlüsselung im Namen des Aufrufers erstellt, ausgehandelt oder aktualisiert.

Wichtig: Produktionscode muss eine TLS-fähige Oracle AI Database-Verbindung oder einen Pool an Oracle AI Agent Memory übergeben. Das SDK verwendet die vom Aufrufer bereitgestellte Verbindung oder den vom Aufrufer bereitgestellten Pool unverändert und führt kein Upgrade eines Nur-Text-DSN durch. Verwenden Sie keine Klartext-Datenbankverbindungen über nicht vertrauenswürdige, freigegebene oder externe Netzwerke hinweg. Befolgen Sie bei der Verwendung von python-oracledb den offiziellen Abschnitt Securely Encrypting Network Traffic to Oracle AI Database, und konfigurieren Sie TLS oder einen anderen genehmigten verschlüsselten Transport im Rahmen der Verbindungs- oder Poolerstellung.

Wichtig: Integrieren Sie API-Schlüssel, Kennwörter oder andere Secrets niemals direkt in Anwendungscode, eingecheckte Konfiguration oder exportierte Artefakte. Verwenden Sie immer sichere Injection-Mechanismen und befolgen Sie das Prinzip der geringsten Berechtigung für den Zugangsdatenzugriff.

Die folgenden Deployment-Praktiken werden empfohlen:

• Datenbankbenutzer nur mit den erforderlichen Berechtigungen verwenden: Erteilen Sie nur das, was für das ausgewählte Deployment-Modell und die ausgewählte Schema-Policy erforderlich ist.
• Separate Schemaadministration von Anwendungszugriff: Verwenden Sie einen privilegierten Datenbankbenutzer einmal, um das verwaltete Agent-Speicherschema zu erstellen oder zu aktualisieren. Erteilen Sie dem Anwendungsbenutzer nur die erforderlichen Laufzeitberechtigungen, und verbinden Sie die Anwendung mit SchemaPolicy.REQUIRE_EXISTING und schema_owner, die für den Schemaeigentümer festgelegt sind. Der Anwendungsbenutzer kann dann Speicherdaten lesen und schreiben, ohne Berechtigungen für die Schemaerstellung, das Upgrade oder die Neuerstellung zu erhalten. Informationen zu den erforderlichen Berechtigungen finden Sie im Handbuch zur Fehlerbehebung.
• Beim Löschen von Workflows einen separaten Datenbankbenutzer verwenden: Wenn Ihre Anwendung Datensätze entfernen muss, bevorzugen Sie eine dedizierte Verbindung oder einen dedizierten Pool für diese Pfade, und erteilen Sie DELETE in den verwalteten Oracle AI Agent Memory-Tabellen nur diesem Datenbankbenutzer. Begrenzen Sie die Hauptlaufzeitverbindung auf die für die normalen Vorgänge erforderlichen Nicht-Löschberechtigungen, sodass versehentliche oder unerwünschte Löschvorgänge einen engeren Strahlungsradius aufweisen. Wenn ein Aufrufer delete() über eine Verbindung aufruft, die keine Berechtigung DELETE hat, lehnt Oracle AI Database die Anweisung ab.
• Verschlüsselte Datenbankverbindungen und Pools erstellen: Produktionscode muss eine TLS-fähige Oracle AI Database-Verbindung oder einen TLS-fähigen Pool an das SDK übergeben. Oracle AI Agent Memory verwendet die vom Aufrufer bereitgestellte Verbindung oder den vom Aufrufer bereitgestellten Pool genau wie angegeben. Daher bevorzugen python-oracledb TLS-fähige Verbindungen wie protocol="tcps" oder einen entsprechenden TCPS-DSN, konfigurieren das erforderliche Wallet oder CA-Material und halten die Validierung des Serverzertifikats aktiviert.
• Standardschema-Policy beibehalten, es sei denn, Sie benötigen explizit DDL-Änderungen: SchemaPolicy.REQUIRE_EXISTING ist der Standardwert und vermeidet das Erstellen, Ändern oder Löschen von Schemaobjekten während des normalen Anwendungsstarts.
• Beschränken Sie destruktive Setupmodi: SchemaPolicy.RECREATE ist für Setup-, Test- oder administrative Workflows gedacht und darf nicht in normalen Produktionspfaden verwendet werden.
• Verlassen Sie sich auf Package-verwaltete SQL-Pfade, nicht auf dynamische SQL-Assemblierung im Anwendungscode: In den verwalteten DB-Pfaden werden Datensatzwerte und Suchfilter mit Bind-Variablen gesendet, und verwaltete Objektnamen werden aus validierten Präfixen abgeleitet.
• Verbindungs- und Providerzugangsdaten schützen: Speichern Sie Datenbank, LLM, und betten Sie Zugangsdaten in einen Secrets-Manager wie OCI Vault ein, und rotieren Sie sie regelmäßig.
• Validierte TLS sowohl im Thin- als auch im Thick-Modus bevorzugen: Die offiziellen python-oracledb-Dokumente weisen darauf hin, dass sowohl der Thin- als auch der Thick-Modus TLS unterstützen und der Thick-Modus auch die Oracle Native Network Encryption verwenden kann, wobei dies Ihr genehmigter Standard ist.
• Sicheren Transport zur Datenbank verwenden: Datenbanknetzwerksicherheit, TLS-Konfiguration und Authentifizierungsmethode werden von der vom Aufrufer bereitgestellten Verbindung bestimmt und müssen den Standards Ihrer Organisation entsprechen.

Überlegungen zur Netzwerkkommunikation und zu externen Endpunkten

Oracle AI Agent Memory kann mit externen Services kommunizieren, wenn das Deployment Remote-LLM oder Einbettungsprovider konfiguriert. Das SDK leitet Prompts und Anforderungsparameter über den konfigurierten Clientpfad weiter, aber die umgebende Anwendung und das Deployment bleiben für die Sicherung dieser Verbindungen verantwortlich.

Folgende Einstellungen werden empfohlen:

• HTTPS für Modellendpunkte verwenden und private oder eingeschränkte Netzwerkpfade bevorzugen, sofern verfügbar.
• Modell-Endpunktzertifikate explizit konfigurieren: Bei einem HTTPS-OpenAI-kompatiblen Endpunkt, der eine private CA verwendet, übergeben Sie das vertrauenswürdige PEM-Zertifikat oder -Bundle über ca_file auf Llm oder Embedder. Bei gegenseitigem TLS übergeben Sie das Clientzertifikat und den Private Key gemeinsam an cert_file und key_file, und schützen Sie den Private Key mit den entsprechenden Dateisystemberechtigungen. Die Verifizierung des Serverzertifikats bleibt aktiviert. Ersetzen Sie kein vertrauenswürdiges CA-Material durch ein nicht vertrauenswürdiges Zertifikat.
• Proxyumgebungseinstellungen des Kontrollproviders absichtlich: Provideranforderungen erfüllen standardmäßig HTTPX-Proxy- und TLS-bezogene Umgebungsvariablen. Übergeben Sie proxy, wenn ein bestimmter Proxy verwendet werden muss. Ein expliziter Proxy hat Vorrang vor Proxyumgebungsvariablen. Legen Sie trust_env=False fest, wenn die Anwendung diese Umgebungseinstellungen ignorieren muss. Ein expliziter proxy bleibt mit trust_env=False in Kraft.
• Überwachen Sie ausgehenden Traffic und Providerauslastung für unerwartete Ziele, ungewöhnliches Anforderungs-Volume oder anomale Tokenauslastung.
• Wählen Sie Provider aus, die Ihren Compliance- und Residency-Anforderungen entsprechen, bevor Sie Active-Memory-Features in regulierten oder sensiblen Workflows aktivieren.

Überlegungen zu Vektoren zur Erschöpfung von Ressourcen

Speicherworkflows können die Datenbanknutzung erhöhen, den Datenverkehr einbetten und den LLM-Tokenverbrauch im Laufe der Zeit erhöhen. Dies gilt sowohl für böswillige Übernutzung als auch für unschuldige Implementierungsfehler wie übergroße Nachrichten oder zu breite Abrufmuster.

Verwenden Sie diese Steuerelemente als Teil Ihrer Produktionshärtung:

• Praktische Prompt- und Meldungsgrenzen festlegen: Konfigurieren Sie Werte wie max_message_token_length und memory_extraction_token_limit entsprechend Ihren Workload- und Providerlimits. max_message_token_length begrenzt die von Extraktionsworkflows verwendete Prompt-Time-Kopie. Gespeicherte Nachrichten bleiben unverändert.
• Bound Retrieval-Größen: Verwenden Sie angemessene max_results-Werte und Datensatztypfilter für Anwendungssuchen.
• Infrastrukturlimits außerhalb des SDK anwenden: Verwenden Sie Datenbankkontingente, Verbindungslimits, Netzwerkkontrollen, Endpunkttimeouts und Ratenbegrenzung im umgebenden Deployment.
• Wachstum im Zeitverlauf überwachen: Verfolgen Sie das gespeicherte Nachrichtenvolumen, das dauerhafte Speicherwachstum, die Providernutzung und die Abfragelatenz, sodass Änderungen an der Aufbewahrung oder Optimierung vorgenommen werden können, bevor sie sich auf die Zuverlässigkeit auswirken.

Empfohlenes Oracle Deep Data Security-Deployment

Oracle Deep Data Security (Deep Sec) kann Zeilen- und Spalten-Constraints des Agent-Speichers in der Datenbank durchsetzen. Beispiel: Endbenutzer können nur Zeilen lesen und schreiben, die ihre eigene user_id enthalten. Die Policy UserOwnRowsDeepDataSecurityPolicy verhindert auch, dass Endbenutzer Eigentümer- und Identitätsspalten nach dem Einfügen aktualisieren. Die genauen Berechtigungen für jede Tabelle finden Sie unter Deep Data Security.

Um diese Sicherheitsfunktionalität in vollem Umfang zu nutzen, empfehlen wir, für jede Sicherheitsverantwortung einen separaten DB-Benutzer zu verwenden, damit die Anwendung keinen privilegierten Fallback hat, wenn kein Endbenutzerkontext vorhanden ist.

Wir empfehlen die folgende Kontotrennung in der Produktion:

• Sicherheitsadministrator: Erstellt und verwaltet Datenrollen, Datenzugriffsberechtigungen, Anwendungsidentitäten und deren Zuordnungen zu IAM-Gruppen. Dieser Account ist ein administrativer Setupaccount und wird nicht für normale Agent-Speicheranforderungen verwendet.
• Eigentümer des verwalteten Schemas: Erstellt und ist Eigentümer der Oracle Agent-Speichertabellen und verwalteten Schemaobjekte. Dieses Konto verfügt über Eigentümerberechtigungen für diese Tabellen, sodass eine Verbindung ohne Endbenutzersicherheitskontext auf alle Zeilen zugreifen kann. Verwenden Sie es nicht als Laufzeitanwendungskonto. Beschränken Sie die Verwendung auf Schemasetup, Migrationen und kontrollierte administrative Vorgänge. Dieser Benutzer muss über die Berechtigung zum Erstellen von JOBs verfügen.
• App-DB-Benutzer: Verbindet sich zur Laufzeit und verfügt nur über die erforderlichen Berechtigungen, um eine Datenbanksession einzurichten und einen Endbenutzersicherheitskontext anzuhängen, normalerweise CREATE SESSION und CREATE END USER SECURITY CONTEXT. Erteilen Sie diesem Benutzer keine normalen SELECT-, INSERT-, UPDATE- oder DELETE-Berechtigungen für die verwalteten Tabellen. Eine Anforderung, die diesen Account ohne gültigen Endbenutzerkontext erreicht, kann dann nicht geschlossen werden, anstatt auf umfassendere Tabellenberechtigungen zurückzugreifen.

Authentifizieren Sie für jede Endbenutzeranforderung den Benutzer außerhalb des OAM-SDK, erwerben Sie eine Anwendungspoolverbindung, hängen Sie den Endbenutzersicherheitskontext dieses Benutzers an, und führen Sie den Agent-Speichervorgang über diese Verbindung aus. Löschen Sie den Kontext, bevor Sie die Verbindung zu einem Pool freigeben. Ein Kontext gehört zu einer physischen Datenbanksession. Er darf nicht für einen anderen Benutzer wiederverwendet werden. Die Deep Sec End-User Security Context Lifecycle-Dokumentation von Oracle beschreibt das entsprechende Verhalten bei Anhängen, Ersetzen und Freigaben.

Übergeben Sie keinen allgemeinen Anwendungspool direkt an eine Agent-Speicherinstanz, es sei denn, der Datenbanktreiber ist so konfiguriert, dass der Endbenutzerkontext der aktuellen Anforderung an jede erworbene Verbindung angehängt wird. Andernfalls kann ein SDK-Vorgang eine Session ohne Kontext oder mit dem falschen Anforderungskontext ausleihen. Ermitteln und konfigurieren Sie stattdessen die Verbindung in der Anwendung, und übergeben Sie diese kontextabhängige Verbindung dann an die Agent-Speicherkomponente mit Anforderungsbereich.

Hintergrund- oder verzögerte Arbeiten, die Benutzerdatensätze lesen oder schreiben, benötigen denselben Schutz. Halten Sie die autorisierte Verbindung und ihren Endbenutzerkontext so lange gültig, bis die Arbeit abgeschlossen ist, oder veranlassen Sie, dass der Worker eine neue Verbindung erhält und den richtigen Kontext des authentifizierten Benutzers anhängt. Führen Sie diese Arbeit niemals über den Schemaeigentümer aus, um einen fehlenden Endbenutzerkontext zu umgehen.