Multi-tenant LLM-analytics: sikker agent

De fleste multi-tenant AI-løsninger læner sig op ad én ting: adgangskontrol i applikationslaget. Det virker, indtil der opstår en fejl i koden, en forkert konfigureret rolle, eller en prompt der lokker modellen til at hente data, den ikke skulle røre. PARs arkitektur bygger i stedet på et princip, der er velkendt fra klassisk systemsikkerhed, men sjældent set implementeret konsekvent i AI-agenter: forsvar i dybden. Hvert lag er selvstændigt i stand til at stoppe et databrud, og lagene deler ikke den samme svaghed.

Det giver et konkret gevinst for enhver virksomhed, der overvejer at bygge agenter, som flere afdelinger, kunder eller samarbejdspartnere skal bruge samtidig på den samme infrastruktur. I stedet for at spørge "kan vores adgangskontrol fejle?", bliver spørgsmålet "hvad sker der, når et lag fejler, og hvor mange andre lag skal også fejle, før data lækker?"

Første lag håndterer selve transporten af forespørgsler. Hver anmodning til systemet signeres kryptografisk med AWS SigV4, den samme signeringsstandard AWS selv bruger til at autentificere kald mod sine egne tjenester. Signaturen bindes til den konkrete bruger og den konkrete tenant, så en forespørgsel ikke bare beviser, at den kommer fra en gyldig bruger, men også hvilken kundekonto den hører til.

Det lukker et hul, mange multi-tenant systemer overser: at en gyldig session kan misbruges til at spørge på tværs af tenants, hvis applikationslaget selv skal huske at tjekke tenant-id på hvert eneste kald. Med signeringen bygget ind i selve transportlaget, findes der ingen sti gennem systemet, hvor tenant-tilhørsforholdet kan glemmes eller overskrives af en fejl i forretningslogikken.

Signaturen beviser, hvem der spørger. Den siger intet om, hvad der bliver spurgt om. Det er andet lags opgave. Her kører forespørgslen igennem en semantisk validering på Amazon Bedrock, som vurderer, om selve indholdet i forespørgslen giver mening for den tenant, der stiller den, og om agenten er ved at blive manipuleret til at hente eller afsløre data uden for sit eget scope.

Dette lag er det, der fanger de angreb, klassisk adgangskontrol slet ikke er designet til at se: prompt injection, forsøg på at få modellen til at "glemme" sine instruktioner, eller subtile omformuleringer, der forsøger at franarre agenten information om en anden kundes konti. Fordi valideringen sker semantisk, ikke bare syntaktisk, kan den fange forsøg, der aldrig ville udløse en alarm i et traditionelt regelsæt.

Tredje lag er formentlig det mest afgørende, fordi det ikke er afhængigt af, at nogen af de to første lag fungerer korrekt. PAR har bygget dataisolationen direkte ind i databaselaget gennem det, de kalder Split-Plane SQL, en programmatisk adskillelse, hvor selve forespørgslen mod databasen konstrueres, så den fysisk ikke kan returnere rækker uden for den korrekte tenants scope.

Forskellen mellem det og traditionel row-level security er, at isolationen ikke afhænger af, at applikationskoden korrekt sætter et tenant-filter på hver query. Filtreringen er indbygget i selve konstruktionen af SQL-planen, hvilket betyder, at selv en fejlkonfigureret eller kompromitteret komponent højere i stakken ikke kan tvinge databasen til at udlevere data, den ikke skal udlevere.

Det er her de tre lag for alvor viser deres værdi sammen. Forestil dig et scenarie, hvor en angriber finder en vej til at manipulere selve sprogmodellen, og den semantiske validering i andet lag ikke fanger det. Uden et tredje lag ville et sådant angreb kunne resultere i et reelt databrud. Med Split-Plane SQL som sidste barriere kan den kompromitterede model i bedste fald forsøge at bede om data uden for sit scope, men databasen er fysisk ude af stand til at levere dem.

Det er en vigtig pointe for enhver, der bygger agentiske systemer i dag: modeller vil fejle, blive manipuleret eller opføre sig uventet på et tidspunkt. Spørgsmålet er ikke, om det sker, men om resten af arkitekturen er bygget til at overleve det. PARs tilgang er et konkret eksempel på, at svaret kan være ja, hvis isolationen lægges så tæt på dataene som muligt, i stedet for kun i applikationslaget eller i modellens egne instruktioner.

Vi ser i praksis, at mange virksomheder, der bygger multi-tenant AI-løsninger, starter med kun ét sikkerhedslag, typisk adgangskontrol i applikationskoden, og først lægger flere lag på, efter et nærved-hændelse eller en revisionsanmodning har afdækket sårbarheden. Kim Like, principal konsulent hos AI Enterprise, har set det gentagne gange i større AI-projekter: den dyreste fejl er ikke at bygge et svagt lag, men at bygge kun ét lag og stole fuldt på det.

For en dansk virksomhed, der planlægger en agent, flere afdelinger, kunder eller eksterne parter skal dele, er den praktiske lektie at tænke isolation ind på tre niveauer samtidig: hvem sender forespørgslen, hvad står der i den, og kan databasen fysisk levere data uden for scope, uanset hvad de to første lag beslutter. Det kræver mere arbejde at bygge end en enkelt adgangskontrol, men det er forskellen mellem et system, der er robust over for menneskelige fejl og modelfejl, og et system, der kun er sikkert, indtil det første lag glipper.

Sammenlign gerne med, hvordan en multi-tenant pool-model på AgentCore løser samme problemstilling.