Sicherheitsbetrachtungen

Geltungsbereich: In diesem Dokument werden Sicherheitsaspekte im Zusammenhang mit dem Python-SDK für den Oracle AI Agent-Speicher 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 Thread-Inhalte und Speicherdatensätze in Oracle Database persistieren und, wenn LLM-backed-Features aktiviert sind, Inhalte an konfigurierte Modellendpunkte zur Zusammenfassung, Speicherextraktion oder Einbettung 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-Funktionen wie Threadzusammenfassung und automatische Speicherextraktion. Wenn diese Features aktiviert sind, kann das SDK aktuelle Nachrichten, Threadzusammenfassungen, abgerufene Speicher oder Suchtext an den konfigurierten LLM- oder Einbettungsendpunkt senden.

Wichtig: Senden Sie nur Inhalte an den Oracle AI Agent-Speicher, 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.
• Asynchrone Extraktion nur auswählen, wenn verzögerte abgeleitete Schreibvorgänge zulässig sind: Im Hintergrundmodus können Schreibvorgänge von Raw-Nachrichten abgeschlossen werden, bevor abgeleitete Speicher, Zusammenfassungen oder zugehörige Laufzeitstatus geschrieben werden. Wenn für einen Workflow eine Prüfung oder eine engere Commit-Grenze erforderlich ist, bevor der vom Modell abgeleitete Status dauerhaft ist, verwenden Sie die Inline-Extraktion, oder deaktivieren Sie die automatische Extraktion für diesen Workflow.
• 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 ausführen sollten.

Überlegungen zu Persistenz und Datenminimierung

Oracle AI Agent Memory ist so konzipiert, dass Nachrichten, Speicher, Metadaten und Einbettungen in Oracle Database persistiert werden, wenn der DB-Backed Store 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 und Metadaten kann ein Workflow auch extrahierte Speicher, Zusammenfassungen oder Einbettungen persistieren.
• 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: delete_thread(), delete_user(cascade=True) und delete_agent(cascade=True) warten nur auf die frühere akzeptierte Hintergrundextraktion, die diesem Client bereits bekannt ist, wenn das Warten beginnt. Sie stellen keine globale Barriere für den gleichzeitigen Zugriff auf andere Handles, Komponenten oder Prozesse dar, und gleichzeitige Schreibvorgänge beim Löschen werden nicht unterstützt. Wenn eine Beibehaltung oder Herunterfahren-Grenze eine bereits akzeptierte Hintergrundextraktion vom aktuellen Client erfordert, um sie zuerst abzuschließen, rufen Sie wait_for_memory_extraction() auf, bevor Sie den Prozess herunterfahren oder zugehörige administrative Vorgänge ausführen.
• 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 für die Beibehaltung der Anwendung und anwendbaren Aufbewahrungszusagen. 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

Der Oracle AI Agent-Speicher 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.

Überlegungen zu Anwendungsintegration und Caller Trust

Oracle AI Agent Memory soll 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 richtige 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

Der Oracle AI Agent-Speicher verwendet eine vom Aufrufer bereitgestellte Oracle 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 Database-Verbindung oder einen Pool in den Oracle AI Agent-Speicher ü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 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.
• 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-Speichertabellen 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 Database die Anweisung ab.
• Verschlüsselte Datenbankverbindungen und Pools erstellen: Produktionscode muss eine TLS-fähige Oracle Database-Verbindung oder einen TLS-fähigen Pool an das SDK übergeben. Der Oracle AI Agent-Speicher 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.
• Ü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 Residenzanforderungen entsprechen, bevor Sie Active-Memory-Features für regulierte oder sensible 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.