Gespreksgeheugen in PHP: context tussen gebruikers en organisaties isoleren

Wanneer een assistent antwoordt met informatie over een andere persoon of organisatie, is dat niet alleen een kwaliteitsprobleem: het kan een schending van de privacy en toegangscontrole zijn. In een PHP-applicatie voor meerdere gebruikers moet gespreksgeheugen worden behandeld als gegevens met een vastgelegde eigenaar, scope en levenscyclus. Berichten opslaan en ophalen op basis van een sessie-ID volstaat niet.

Gesprekscontext isoleren in PHP-applicaties betekent waarborgen dat het materiaal dat wordt gebruikt om een antwoord te genereren bij het huidige gesprek hoort en nog steeds is geautoriseerd. Dit omvat eerdere berichten, samenvattingen en alle opgehaalde gegevens. Documenten doorzoeken kan de context aanvullen, maar daarvoor gelden andere toegangsregels en doelen.

Gespreksgeheugen, geschiedenis en documenten scheiden

De volledige geschiedenis is het berichtenoverzicht van een gesprek. Geheugen is daarentegen de subset die de applicatie voor een taak ophaalt, bijvoorbeeld de laatste beurten of een bijgewerkte samenvatting. Documenten die via zoekopdrachten zijn opgehaald, vormen een andere bron: ze worden geselecteerd op basis van een query en documentrechten. Deze bronnen mogen niet met elkaar worden verward of worden opgeslagen alsof het berichten zijn die de gebruiker heeft uitgesproken.

Dit onderscheid maakt beslissingen controleerbaar. De geschiedenis kan om audit- of productredenen worden bewaard, terwijl het geheugen dat naar het model wordt gestuurd beperkt blijft. Ook kan elk documentfragment zijn eigen herkomst en toegangscontrole behouden. Als die bronnen worden vermengd zonder ze te identificeren, wordt het lastig uit te leggen welke gegevens een antwoord hebben beïnvloed en het bewaarbeleid toe te passen.

Vaststellen wie eigenaar is van elk gesprek

Leg voordat u het ophalen van gegevens ontwerpt een stabiele identiteit voor het gesprek vast. Houd minimaal rekening met:

• Gesprek: een willekeurige of niet-voorspelbare identificatie, waarbij u er niet van uitgaat dat kennis van die identificatie toegang verleent.
• Gebruiker: de geauthenticeerde identiteit die de interactie is gestart of toestemming heeft om die te raadplegen.
• Organisatie: de gegevensscope waartoe het gesprek behoort, als de applicatie voor meerdere bedrijven of werkruimten wordt gebruikt.
• Actuele rechten: autorisatie die bij elke leesactie wordt beoordeeld, niet een onbeperkt geldige kopie van de oorspronkelijke rechten.

De websessie kan worden gebruikt om een verzoek te authenticeren, maar hoort niet de enige sleutel voor blijvend eigenaarschap te zijn. Iemand kan uitloggen, van organisatie veranderen of een recht verliezen terwijl een gesprek opgeslagen blijft. Bij elk verzoek moet de applicatie controleren of de huidige gebruiker binnen de actieve organisatie toegang heeft tot dat gesprek.

Het is verstandig wijzigingen van context expliciet vast te leggen. Als iemand van organisatie verandert, kan diegene dan het eerdere gesprek voortzetten, moet diegene een nieuw gesprek starten of mag alleen een goedgekeurde samenvatting behouden blijven? Er is geen universeel antwoord: dat hangt af van het product en de privacyvereisten. De beslissing moet worden vastgelegd in controleerbare regels, niet in een impliciete aanname van de interface.

Toegangsscope toepassen voordat context wordt opgehaald

Autorisatie moet deel uitmaken van de query waarmee gegevens worden opgehaald, voordat die aan de prompt worden toegevoegd. Eerst een brede verzameling ophalen en daarna in PHP filteren vergroot het risico dat een fout, alternatieve route of debuglog inhoud van iemand anders blootlegt.

In een relationele database kan de query tegelijk de ID's van het gesprek, de geautoriseerde gebruiker en de organisatie bevatten. Bijvoorbeeld, conceptueel:

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 (/* controleren of een toekenning nog geldig is */)
  )
ORDER BY created_at DESC
LIMIT :message_limit

Het daadwerkelijke schema kan anders zijn, maar het belangrijke principe is dat de toegangsscope bepaalt welke records worden opgehaald. Gebruik gebonden parameters en één consistente autorisatielaag voor lees-, schrijf-, export- en verwijderbewerkingen. Als een vectordatabase of zoekdienst wordt gebruikt, moeten beperkingen op basis van organisatie en rechten worden toegepast in de ophaalquery; het volstaat niet om het model te vragen ongeautoriseerde resultaten te negeren.

Wanneer zoeken in documenten en gespreksgeheugen worden gecombineerd, past u eerst de autorisatie toe die voor elke bron geldt. Bewaar metagegevens over de herkomst en maak documentresultaten niet tot permanent geheugen zonder expliciet beleid.

Vermenging in caches, wachtrijen en gedeelde componenten voorkomen

Correcte toegang tot de database garandeert geen isolatie als andere lagen status delen. Een cachesleutel als conversation:123 kan ontoereikend zijn als dezelfde identificatie in meerdere scopes wordt gebruikt, wordt hergebruikt of een cacheconfiguratie botsingen mogelijk maakt. Neem de organisatie- en gespreks-ID op in de sleutel en, waar van toepassing, een versie van de rechten of gegevens. Gebruik geen gevoelige inhoud als onderdeel van de sleutel.

Geef bij achtergrondtaken een minimale, expliciete context mee: organisatie, gesprek, actor en doel van de taak. Controleer bij uitvoering opnieuw of de taak nog geautoriseerd is en geen identiteit gebruikt die uit gedeelde globale status afkomstig is. Vermijd statische variabelen, singletonservices met veranderlijke gebruikersgegevens en sessieobjecten die tussen verzoeken worden hergebruikt, vooral in persistente PHP-processen.

Leg ook vast wat er bij fouten en nieuwe pogingen gebeurt. Een opnieuw uitgevoerde taak mag door de status van een ander proces niet naar een andere organisatie overschakelen, en een antwoord in de cache mag een intrekking niet overleven als het beleid vereist dat de cache ongeldig wordt gemaakt. Het gedrag moet bewust zijn gekozen en waarneembaar zijn.

Geheugen beperken tot wat nodig is voor de taak

Isoleren betekent niet dat de volledige geschiedenis naar het model moet worden gestuurd. Haal recente beurten of een samenvatting op die waarde toevoegt aan het huidige verzoek, met limieten voor hoeveelheid en omvang. Houd rekening met actualiteit: oude voorkeuren, gecorrigeerde gegevens en ingetrokken besluiten mogen niet automatisch als actuele feiten worden behandeld.

Als samenvattingen worden gebruikt, sla dan hun scope en herkomst op en werk ze volgens duidelijke regels bij. Een samenvatting is geen bron van waarheid en vervangt de controle van rechten niet. Raadpleeg voor kritieke gegevens het geautoriseerde registratiesysteem in plaats van te vertrouwen op een bewering die in een eerder gesprek is opgeslagen. Een klein contextvenster beperkt blootstelling en kosten, maar compenseert geen onjuiste autorisatie.

Testen dat het ene gesprek het andere niet beïnvloedt

Tests moeten zowel toegestane als geweigerde toegang omvatten. Maak scenario's met verschillende gebruikers en organisaties en controleer dat een verzoek geen berichten, samenvattingen of documenten van een andere identiteit ophaalt. Neem ook grensgevallen op:

• Een gebruiker verandert van organisatie en opent opnieuw een oude gespreks-ID.
• Een recht wordt ingetrokken nadat het gesprek is aangemaakt, maar voordat het geheugen ervan wordt opgehaald.
• Twee gebruikers raadplegen de applicatie gelijktijdig en delen processen, cache of wachtrij-infrastructuur.
• Een niet-bestaande of aan iemand anders toebehorende ID leidt tot een gecontroleerd antwoord zonder prijs te geven of die bij iemand anders hoort.
• Een taak wordt opnieuw geprobeerd nadat de rechten of organisatie zijn gewijzigd.

Test naast unit tests ook de volledige route, van het geauthenticeerde verzoek tot de samenstelling van de context. U kunt markeringsberichten in afzonderlijke gesprekken plaatsen en controleren dat de voor elk gesprek opgehaalde resultaten nooit de markering van het andere bevatten. Het doel is de gegevensgrens te testen, niet te beoordelen of het model een overtuigend antwoord formuleert.

Incidenten onderzoeken zonder gevoelige inhoud te loggen

Observability moet het mogelijk maken de gegevensstroom te volgen zonder privéberichten naar logs te kopiëren. Registreer geschikte technische identificaties, de autorisatiebeslissing, het aantal opgehaalde items, de gegevensbron, de duur en het resultaat van elke stap. Gebruik waar mogelijk pseudonieme identificaties en beperk de toegang tot en bewaartermijn van logs.

Signalen zoals onverwacht lege resultaten, een afwijkende organisatie, een ongebruikelijk aantal geweigerde verzoeken of een cachesleutel die buiten zijn scope opnieuw wordt gebruikt, kunnen helpen fouten op te sporen. Registreer standaard geen volledige prompts, documenten of antwoorden. Als gedetailleerde diagnostiek nodig is, stel dan een tijdelijke, geautoriseerde en beperkte procedure in, waarbij gevoelige gegevens worden geredigeerd.

Een veilig ontwerp maakt de eigenaar, scope en geldigheid van elk contextfragment expliciet. Door die regels toe te passen in queries, caches en asynchrone taken, en negatieve scenario's te controleren, wordt isolatie een verifieerbare eigenschap van de PHP-applicatie in plaats van een verwachting die aan de assistent wordt overgelaten.