En tjenesteudbyders godkendelsesagent kan fungere for mange kunder, men hver operation bør have én bekræftet kundekontekst. Et kundenavn i en prompt er ikke en adgangskontrolbeslutning. Bind sessionen og jobbet til lejeren, der er identificeret af den betroede applikation, og bær derefter denne identitet gennem hentning, forslag, godkendelse, eksekvering og bevislagring.
Etabler kundegrænsen
Under onboarding skal du indhente den godkendte domæneopgørelse og kundeadministratorens autoritet til den anmodede tjeneste. Registrer lejer-id'er, der er stabile og unikke i stedet for at stole på lignende visningsnavne. Bekræft, at DNS zonerne og rapportdestinationerne tilhører det tilsigtede omfang, før du giver adgang.
Brug kundespecifikke legitimationsoplysninger eller en lige så håndhæver downstream-godkendelsesmekanisme. En central tjenesteidentitet med bred adgang kræver robuste kontroller ved hvert ressourceopslag. OWASP beskriver risikoen for, at generiske privilegerede identiteter får adgang til ressourcer ud over den relevante brugerkontekst. OWASP LLM06.
Hold beviser adskilt
Anvend lejeromfang for at rapportere lager, søgeindekser, caches, samtalekontekst og eksporterede filer. Begræns hentning, før bevis når modellen. At filtrere en anden kundes materiale ud af det endelige svar er for sent, hvis det allerede er kommet ind i arbejdskonteksten. Logs har også brug for adgangskontrol; et delt fejlfindingsdashboard kan besejre ellers omhyggelig adskillelse.
Et IP- eller udbydernavn, der deles af to kunder, giver ikke tilladelse til at deltage i deres private beviser. Registrer fakta om offentlig infrastruktur adskilt fra kundespecifikt kontoejerskab, serviceaktivitet og kontakter. Et lignende domæne-suffiks eller fælles forhandler gør ikke to lejere til én godkendelsesgrænse.
Spor et job i kø på tværs af en tilbagekaldt bevilling
Antag, at et job oprettes under kunde A's gyldige bevilling, så tilbagekalder adgangsadministratoren denne bevilling før udførelse. Eksekutøren skal genkontrollere den nuværende autoritet i stedet for at stole på den tidligere session. Hvis en cache også indeholder kunde B's post under samme korte navn, skal opslaget forblive scoped til A; delt infrastruktur og lignende navne kan ikke retfærdiggøre at hente B's private bevismateriale.
Disse er hypotetiske grænsetilfælde, ikke et testet stik eller medfølgende runbook. Tildel særskilte ansvarsområder for scope-godkendelse, driftsændringer, uafhængig adgangsgennemgang og offboarding. Definer målbare acceptbetingelser for den faktiske implementering, herunder en tilladt A-anmodning og afvist B-anmodning, tilbagekaldte job i kø og passende cache-hentning. Gør ikke krav på nul eksponering mellem lejere, før de relevante stier faktisk er blevet testet.
Tjek jobs såvel som sessioner
Bind godkendelse til lejeren og verificere den samme identitet på udførelsestidspunktet. Lad ikke modellen vælge, hvilken legitimation der skal bruges fra et fritekst kundenavn. Kontroller godkendelsen igen, når et job i kø kører; et tilskud kan være tilbagekaldt efter jobbets oprettelse. Udløbne eller overførte kundeforhold kræver eksplicit håndtering frem for arvet adgang.
Test med bevidst lignende kundenavne, overlappende udbyder-IP'er, genbrugte postnavne og et cachelagret svar fra en anden lejer. Inkluder en tilladt kunde - en læsning, så testen beviser scoped access, ikke en globalt deaktiveret connector. De hypotetiske eksempler ovenfor udfører ikke nogen af disse implementeringstests. Bevar den faktiske anmodningskontekst, godkendelsesbeslutninger og observerede effekter, når de evalueres.
Luk forholdet rent
Offboarding bør stoppe nyt arbejde, tilbagekalde adgang, håndtere job i kø og anvende den aftalte proces for opbevaring af beviser. Bekræft hver handling gennem det ansvarlige system. Bevar den minimale revisionshistorik, der er nødvendig for at forklare tidligere arbejde i henhold til den gældende aftale. Slet ikke beviser automatisk eller behold adgangen på ubestemt tid, blot fordi agenten muligvis skal besvare et senere spørgsmål.