Wenn ein Assistent Informationen über eine andere Person oder ein anderes Unternehmen ausgibt, ist das nicht nur ein Qualitätsproblem: Es kann eine Verletzung der Privatsphäre und der Zugriffskontrolle darstellen. In einer mandantenfähigen PHP-Anwendung muss das Konversationsgedächtnis als Datenbestand mit festgelegtem Eigentümer, Geltungsbereich und Lebenszyklus behandelt werden. Es reicht nicht aus, Nachrichten zu speichern und sie über eine Sitzungs-ID abzurufen.
Die Isolierung des Konversationskontexts in PHP-Anwendungen bedeutet sicherzustellen, dass das zur Generierung einer Antwort verwendete Material zur aktuellen Unterhaltung gehört und weiterhin autorisiert ist. Dazu zählen frühere Nachrichten, Zusammenfassungen und alle abgerufenen Daten. Die Dokumentensuche kann den Kontext ergänzen, folgt aber eigenen Zugriffsregeln und Zielen.
Konversationsgedächtnis, Verlauf und Dokumente trennen
Der vollständige Verlauf ist das Protokoll der Nachrichten einer Unterhaltung. Das Gedächtnis hingegen ist die Teilmenge, die die Anwendung für eine Aufgabe abzurufen beschließt: beispielsweise die letzten Gesprächsrunden oder eine aktualisierte Zusammenfassung. Über die Suche abgerufene Dokumente sind eine weitere Quelle, die anhand einer Abfrage und der Dokumentberechtigungen ausgewählt wird. Diese Quellen dürfen nicht verwechselt oder so gespeichert werden, als wären sie vom Nutzer verfasste Nachrichten.
Diese Unterscheidung erleichtert überprüfbare Entscheidungen. Der Verlauf kann aus Audit- oder Produktgründen aufbewahrt werden, während das an das Modell übermittelte Gedächtnis begrenzt wird. Ebenso kann jedes Dokumentfragment seine eigene Herkunft und Zugriffskontrolle behalten. Werden diese Quellen ohne Kennzeichnung vermischt, lässt sich nur schwer erklären, welche Daten eine Antwort beeinflusst haben, und ihre Aufbewahrungsrichtlinien lassen sich schwer durchsetzen.
Festlegen, wem jede Unterhaltung gehört
Legen Sie vor dem Entwurf des Abrufs eine stabile Identität für die Unterhaltung fest. Berücksichtigen Sie mindestens:
- Unterhaltung: eine zufällige oder nicht vorhersagbare ID, wobei der Besitz der ID keinen Zugriff gewähren darf.
- Nutzer: die authentifizierte Identität, die die Interaktion begonnen hat oder zu ihrem Abruf berechtigt ist.
- Organisation: den Datenbereich, zu dem die Unterhaltung gehört, sofern die Anwendung mit mehreren Unternehmen oder Arbeitsbereichen arbeitet.
- Geltende Berechtigungen: eine Autorisierung, die bei jedem Lesezugriff geprüft wird, statt eine unbegrenzt gültige Kopie der ursprünglichen Berechtigungen zu verwenden.
Die Websitzung kann zur Authentifizierung einer Anfrage dienen, sollte aber nicht der einzige Schlüssel für eine dauerhafte Zuordnung sein. Eine Person kann sich abmelden, die Organisation wechseln oder eine Berechtigung verlieren, während eine Unterhaltung weiterhin gespeichert ist. Bei jeder Anfrage muss die Anwendung prüfen, ob der aktuelle Nutzer innerhalb der aktiven Organisation auf diese Unterhaltung zugreifen darf.
Legen Sie Änderungen des Kontexts ausdrücklich fest. Kann jemand nach einem Organisationswechsel die vorherige Unterhaltung fortsetzen, muss eine neue begonnen werden oder darf nur eine genehmigte Zusammenfassung erhalten bleiben? Es gibt keine universelle Antwort: Sie hängt vom Produkt und seinen Datenschutzanforderungen ab. Die Entscheidung muss sich in überprüfbaren Regeln widerspiegeln und darf nicht auf einer unausgesprochenen Annahme der Benutzeroberfläche beruhen.
Zugriffsbereich vor dem Abruf des Kontexts anwenden
Die Autorisierung muss bereits Teil der Abfrage sein, mit der Daten abgerufen werden – bevor diese in den Prompt gelangen. Zuerst eine umfangreiche Sammlung abzurufen und anschließend in PHP zu filtern, erhöht das Risiko, dass ein Fehler, ein alternativer Ausführungspfad oder ein Debug-Protokoll fremde Inhalte offenlegt.
In einer relationalen Datenbank kann die Abfrage gleichzeitig die autorisierte Unterhaltungs-ID, den Nutzer und die Organisation berücksichtigen. Ein konzeptionelles Beispiel:
SELECT message_id, role, content, created_at
FROM conversation_messages
WHERE conversation_id = :conversation_id
AND organization_id = :organization_id
AND conversation_id IN (
SELECT conversation_id
FROM conversations
WHERE owner_user_id = :user_id
OR EXISTS (/* eine gültige Berechtigung prüfen */)
)
ORDER BY created_at DESC
LIMIT :message_limitDas tatsächliche Schema kann anders aussehen, entscheidend ist jedoch, dass der Zugriffsbereich die abgerufenen Datensätze einschränkt. Verwenden Sie gebundene Parameter und eine einheitliche Autorisierungsschicht für Lese-, Schreib-, Export- und Löschvorgänge. Kommen eine Vektordatenbank oder ein Suchdienst zum Einsatz, müssen Einschränkungen nach Organisation und Berechtigungen bereits in der Abrufabfrage angewendet werden. Es reicht nicht, das Modell aufzufordern, nicht autorisierte Ergebnisse zu ignorieren.
Werden Dokumentensuche und Konversationsgedächtnis kombiniert, muss für jede Quelle zuerst die jeweils geltende Autorisierung angewendet werden. Bewahren Sie Herkunftsmetadaten auf und wandeln Sie Dokumentergebnisse nicht ohne ausdrückliche Richtlinie in dauerhaftes Gedächtnis um.
Überschneidungen in Caches, Warteschlangen und gemeinsam genutzten Komponenten vermeiden
Ein korrekter Datenbankzugriff garantiert keine Isolation, wenn andere Schichten Zustand gemeinsam nutzen. Ein Cache-Schlüssel wie conversation:123 kann unzureichend sein, wenn dieselbe ID in mehr als einem Bereich verwendet oder wiederverwendet wird oder die Cache-Konfiguration Kollisionen zulässt. Nehmen Sie Organisations- und Unterhaltungs-IDs sowie gegebenenfalls eine Berechtigungs- oder Datenversion in den Schlüssel auf. Verwenden Sie keine sensiblen Inhalte als Bestandteil des Schlüssels.
Übermitteln Sie bei Hintergrundaufgaben einen minimalen, expliziten Kontext: Organisation, Unterhaltung, Akteur und Zweck der Aufgabe. Prüfen Sie bei der Ausführung erneut, ob die Aufgabe weiterhin autorisiert ist und keine Identität aus einem gemeinsam genutzten globalen Zustand verwendet. Vermeiden Sie statische Variablen, Singleton-Dienste mit veränderlichen Nutzerdaten und zwischen Anfragen wiederverwendete Sitzungsobjekte – insbesondere in persistenten PHP-Prozessen.
Legen Sie auch fest, was bei Fehlern und Wiederholungsversuchen geschieht. Eine erneut ausgeführte Aufgabe darf nicht aufgrund des Zustands eines anderen Prozesses die Organisation wechseln. Ebenso darf eine zwischengespeicherte Antwort nach einem Berechtigungsentzug nicht weiter verfügbar sein, wenn die Richtlinie ihre Invalidierung verlangt. Das Verhalten muss bewusst festgelegt und beobachtbar sein.
Das Gedächtnis auf das für die Aufgabe Notwendige begrenzen
Isolation bedeutet nicht, den gesamten Verlauf an das Modell zu senden. Rufen Sie die letzten Gesprächsrunden oder eine Zusammenfassung ab, die für die aktuelle Anfrage hilfreich ist, und begrenzen Sie dabei Anzahl und Umfang. Berücksichtigen Sie die Aktualität: Ältere Präferenzen, korrigierte Daten und widerrufene Entscheidungen sollten nicht automatisch als aktuell gültige Tatsachen behandelt werden.
Wenn Zusammenfassungen verwendet werden, speichern Sie ihren Geltungsbereich und ihre Herkunft und aktualisieren Sie sie nach klaren Regeln. Eine Zusammenfassung ist keine maßgebliche Quelle und ersetzt keine Berechtigungsprüfung. Bei kritischen Daten sollten Sie das maßgebliche Quellsystem abfragen, statt sich auf eine in einer früheren Unterhaltung gespeicherte Aussage zu verlassen. Ein kleines Kontextfenster reduziert Offenlegung und Kosten, gleicht aber eine fehlerhafte Autorisierung nicht aus.
Prüfen, dass eine Unterhaltung keine andere beeinflusst
Tests müssen sowohl erlaubte als auch verweigerte Zugriffe abdecken. Erstellen Sie Fälle mit unterschiedlichen Nutzern und Organisationen und prüfen Sie, dass eine Anfrage keine Nachrichten, Zusammenfassungen oder Dokumente einer anderen Identität abruft. Berücksichtigen Sie Grenzfälle:
- Ein Nutzer wechselt die Organisation und öffnet erneut eine alte Unterhaltungs-ID.
- Eine Berechtigung wird nach dem Erstellen der Unterhaltung, aber vor dem Abruf ihres Gedächtnisses widerrufen.
- Zwei Nutzer greifen gleichzeitig zu und nutzen Prozesse, Cache oder Warteschlangen-Infrastruktur gemeinsam.
- Eine nicht vorhandene oder fremde ID führt zu einer kontrollierten Antwort, ohne offenzulegen, ob sie einer anderen Person gehört.
- Eine Aufgabe wird nach einer Änderung der Berechtigungen oder der Organisation erneut ausgeführt.
Testen Sie neben Unit-Tests auch den gesamten Ablauf von der authentifizierten Anfrage bis zum Aufbau des Kontexts. Sie können unterschiedliche Unterhaltungen mit Markierungsnachrichten versehen und überprüfen, dass das für jede Unterhaltung abgerufene Ergebnis niemals die Markierung der jeweils anderen enthält. Ziel ist es, die Datengrenze zu prüfen – nicht, zu bewerten, ob das Modell eine überzeugende Antwort formuliert.
Vorfälle untersuchen, ohne sensible Inhalte zu protokollieren
Die Observability muss es ermöglichen, den Ablauf nachzuverfolgen, ohne private Nachrichten in Logs zu kopieren. Protokollieren Sie geeignete technische IDs, die Autorisierungsentscheidung, die Anzahl der abgerufenen Elemente, die Datenquelle, die Dauer und das Ergebnis jedes Schritts. Verwenden Sie nach Möglichkeit pseudonyme IDs und beschränken Sie Zugriff und Aufbewahrungsdauer der Protokolle.
Hinweise wie ein unerwartet leerer Abruf, eine abweichende Organisation, eine ungewöhnlich hohe Zahl verweigerter Zugriffe oder ein außerhalb seines Geltungsbereichs wiederverwendeter Cache-Schlüssel helfen dabei, Fehler zu erkennen. Vermeiden Sie es, vollständige Prompts, Dokumente oder Antworten standardmäßig zu protokollieren. Wenn eine detaillierte Diagnose erforderlich ist, legen Sie ein zeitlich begrenztes, autorisiertes und eingeschränktes Verfahren mit Schwärzung sensibler Daten fest.
Ein sicheres Design macht Eigentümer, Geltungsbereich und Gültigkeit jedes Kontextfragments explizit. Werden diese Regeln in Abfragen, Caches und asynchronen Aufgaben angewendet und Negativfälle überprüft, wird Isolation zu einer überprüfbaren Eigenschaft der PHP-Anwendung – statt zu einer Erwartung, die dem Assistenten überlassen bleibt.
