Sikr AI-chatbot tool-kald: Rettigheder, bekræftelse og rollback-stier

En website-chatbot ændrer sig fundamentalt, så snart den ikke kun svarer, men også må udløse handlinger. En forespørgsel på en kalenderaftale er til at overse. En aflysning af en aftale, en adresseændring eller en refundering ændrer derimod den reelle forretningstilstand. Sprogmodellen må i den forbindelse gerne foreslå et passende tool-kald. Hvorvidt handlingen er tilladt, skal dog afgøres af et separat, deterministisk applikationslag. Sikre AI-chatbot tool-kald opstår derfor ikke ved hjælp af en særligt streng system-prompt, men gennem begrænsede funktioner, rettighedskontrol på serversiden, en forståelig bekræftelse og en kontrolleret afviklingssti.

Hvorfor en god sprogmodel ikke erstatter autorisation

En model arbejder med sandsynligheder. Den kan misforstå en hensigt, tilføje en parameter eller reagere på manipulerede input. OWASP-risikobeskrivelsen for Excessive Agency nævner tre typiske årsager: for megen funktionalitet, for vide rettigheder og for megen autonomi. Problemet er altså ikke kun et ondsindet input. Også en flertydig forespørgsel eller en plausibel modelfejl kan forberede en uønsket handling.

Den vigtigste arkitekturregel lyder derfor: Modellen formulerer et forslag, men applikationen autoriserer og udfører det. Et tool-call som cancelAppointment er i første omgang kun en struktureret hensigt. Først et policy-tjek verificerer bruger, tenant, objekt, tilladt handling, aktuel status og den nødvendige bekræftelse. Denne adskillelse supplerer beskyttelsen mod prompt injection i website-chatbots; den er fortsat nødvendig, selvom intet angreb er opdaget.

Klassificer hvert tool efter virkning i stedet for navn

Teams bør ikke generelt klassificere hele chatbotten som enten "sikker" eller "kritisk". Det afgørende er virkningen af det enkelte tool. En simpel risikomatrix skaber klarhed:

• Læseadgang og lav følsomhed: Hente åbningstider eller offentligt tilgængelige produktinformationer.
• Læseadgang og personhenførbare data: Vise en ordrestatus eller kundedata; her skal identitet, tenant og objektsammenhæng kontrolleres.
• Skriveadgang, men let reversibel: Oprette et internt ønske om opringning eller tilføje et uforpligtende notat.
• Indgribende eller vanskeligt reversibel: Annullere en booking, ændre kontaktoplysninger, publicere indhold, sende meddelelser eller igangsætte betalinger.

Ud fra denne klasse følger rettigheder, bekræftelsesniveau, grænser og logning. En generel godkendelse som "Chatbotten må bruge CRM-systemet" er for grov. Det er bedre med en liste over konkrete evner med definerede parametre og tilladte tilstandsovergange.

Least Privilege starter ved udformningen af funktionerne

OWASP Authorization Cheat Sheet anbefaler Least Privilege og Deny by Default. For tool-kald betyder det: En chatbot får kun den funktion og det dataudsnit, der er nødvendigt for det enkelte trin.

Små værktøjer i stedet for universelle grænseflader

Et tool getOrderStatus(orderId) er lettere at sikre end en åben databaseadgang. Et tool requestCallback(topic, timeWindow) er mere kontrollerbart end en generel funktion til afsendelse af vilkårlige meddelelser. Frie SQL-, shell-, URL- eller e-mailfunktioner øger den mulige skadevirkning unødigt. Testværktøjer, der ikke længere er brug for, bør også fjernes fra det produktive katalog.

Kør i konteksten af den indloggede bruger

Backend må ikke stole blindt på, at modellen overfører det korrekte kunde-ID. Den skal udlede den aktuelle bruger og tenant fra den betroede session og for hvert objekt igen kontrollere, om der er adgang. Den praktiske forskel på en offentlig chat og et beskyttet område forklares i detaljer i artiklen om identitet og dataadgang i kundeportalen. En generel servicekonto med fuld adgang er for det meste den forkerte genvej til brugerrelaterede handlinger.

Validér parametre deterministisk

Tool-parametre har brug for et snævert skema: tilladte felter, typer, længder, værdigränser og tilstandsregler. Et aftale-ID skal tilhøre brugeren, en dato skal ligge inden for et tilladt interval, og en handling skal passe til den aktuelle status. Ukendte felter afvises. Applikationen bør desuden sikre, at selve tool-navnet kommer fra en fast allowlist og ikke afvikles ud fra frit genereret tekst.

Bekræftelsen skal vise den reelle handling

Ved indgribende ændringer er spørgsmålet "Er du sikker?" ikke tilstrækkeligt. OWASP-retningslinjen for transaktionsautorisation beskriver princippet "What You See Is What You Sign": Brugere skal kunne se og bekræfte de væsentlige data for den konkrete handling. For en website-chatbot betyder det for eksempel:

• "Aflys aftale den 18. august kl. 14:30" i stedet for "Bekræft ændring"
• "Ændr leveringsadresse for ordre ...84 til København" i stedet for "Gem data"
• "Opret ønske om opringning vedrørende regning" i stedet for "Send anmodning"

Bekræftelsen knyttes på serversiden til netop dette handlingsudkast. Hvis destination, beløb, dato, modtager eller andre væsentlige parametre ændres, bortfalder den. Den får en kort gyldighedsperiode og kan ikke genbruges til en anden handling. Ved særligt kritiske processer kan det desuden kræves, at brugeren logger ind igen eller afventer godkendelse fra et menneske. Modellen må hverken springe dette trin over eller erstatte det med et beroligende formuleret svar.

Planlæg idempotens, grænser og rollback-sti

Selv et korrekt autoriseret tool-kald kan teknisk set modtages dobbelt: Browseren gentager en forespørgsel, en timeout udløser et retry, eller brugeren sender den samme meddelelse igen. Skrivende tools bør derfor anvende et idempotens-ID på serversiden. For det samme ID udføres den samme handling højst én gang; et retry modtager det allerede kendte resultat.

Derudover har hvert tool brug for passende grænser: maksimale kald pr. session, korte timeouts, begrænsede retries og afbrydelse ved usædvanlige kæder. Før udførelsen kontrollerer backend tilstanden endnu en gang. På den måde bliver f.eks. en allerede annulleret booking ikke behandlet en ekstra gang. Hvor det er muligt, bør en handling i første omgang oprettes som et udkast eller en reserveret ordre. Ved uundgåelige direkte ændringer skal det være klart, hvordan de kompenseres, tilbagekaldes eller overdrages til et supportteam. En forberedt degraded mode og rollback-plan forhindrer, at der skal improviseres i tilfælde af driftsforstyrrelser.

Logføring uden at indsamle hemmeligheder

En sikkerhedslog skal kunne besvare, hvem der har godkendt hvilken handling på hvilket grundlag, og med hvilket resultat den blev udført. Det er hensigtsmæssigt at registrere et pseudonymiseret aktør-ID, tool og version, objektreference, policy-version, autorisationsafgørelse, bekræftelses-ID, idempotens-ID, tidspunkt og resultat. Adgangskoder, tokens, fuldstændige chathistorikker og unødvendigt personhenførbart indhold hører ikke hjemme i denne log.

OWASP AI Agent Security Cheat Sheet anbefaler strukturerede beslutningsdata for risikofyldte handlinger samt adskillelse af beslutning og udførelse. Dette er noget andet end fuldstændig teknisk tracing: Til sikkerhedsaudit tæller et kortfattet, pålideligt bevis for godkendelseskæden. Opbevaring og adgang bør tilpasses det faktiske kontrolbehov.

En robust arkitektur i fem lag

1. Dialog og forslag: Modellen genkender hensigten og opretter et struktureret handlingsudkast, men udfører intet direkte.
2. Policy-beslutning: En deterministisk komponent kontrollerer tool-allowlist, bruger, tenant, objekt, parametre, risikoklasse og grænser.
3. Bekræftelse: Brugerfladen viser de væsentlige handlingsdata. Godkendelsen er kortvarig og bundet til det uændrede udkast.
4. Udførelse: En snævert begrænset executor kontrollerer autorisationen igen umiddelbart før kaldet og anvender et idempotens-ID.
5. Dokumentation og reaktion: Resultat, fejl og godkendelseskæde logføres med dataminimering; alarmering, kompensation og overdragelse til et menneske er defineret.

NIST AI RMF Core placerer sådanne opgaver under Govern, Map, Measure og Manage. I praksis betyder det: Fastlæg ansvar og risikogrænser, forstå brugskonteksten, test kontrolelementer og reager på observerede afvigelser.

Testmatrix før go-live

Positive tests alene er ikke nok. Et tool bør også fejle sikkert under ugunstige forhold. Som minimum bør følgende tilfælde indgå i en genanvendelig testmatrix:

• En ikke-indlogget eller ueget bruger anmoder om handlingen.
• En gyldig session henviser til et objekt, der tilhører en anden tenant.
• Væsentlige parametre ændres efter bekræftelsen.
• Den identiske forespørgsel gentages på grund af timeout eller dobbeltklik.
• Et tool returnerer manipulerede instrukser eller uventede ekstra felter.
• Et kald overskrider tids-, mængde- eller omkostningsgrænser.
• Målsystemet nedbrydes mellem kontrol og udførelse.
• En rettighed trækkes tilbage umiddelbart før udførelsen.

Der forventes ikke kun succesfulde handlinger, men klare afvisninger, uændrede data og brugbare sikkerhedshændelser. Før skrivetilladelser aktiveres for reelle brugere, kan forløbet testet i shadow mode med realistiske forespørgsler uden at udføre de foreslåede handlinger.

Tjekliste til website-teams

• Er hvert tool lille, målrettet og fra en fast allowlist?
• Kontrolleres bruger, tenant, objekt og handling på serversiden?
• Gælder Deny by Default og minimale tekniske rettigheder?
• Ser brugerne alle væsentlige data før kritiske handlinger?
• Udløber bekræftelsen ved ændringer og efter kort tid?
• Forhindrer et idempotens-ID dobbelt udførelse?
• Findes der grænser, timeout, afbrydelse, kompensation og human handoff?
• Holdes tokens, hemmeligheder og unødvendige persondata ude af loggene?
• Dækker testmatrixen rettighedsfejl, manipulation, retries og nedbrud?

Konklusion: Modellen foreslår, applikationen bestemmer

En handlingsduelig website-chatbot behøver ikke at starte med fuld adgang. Begynd med en snævert begrænset, reversibel handling, og opbyg godkendelseskæden synligt omkring den. Når tool-udformning, autorisation på serversiden, konkret bekræftelse, idempotens og rollback-stier designes i fællesskab, forbliver chatten hjælpsom uden at give modellen rollen som sikkerhedssystem. For det næste skridt kan det betale sig med en workshop sammen med produkt, udvikling, support og databeskyttelse: Vælg en reel handling, vurder dens risiko, og definer det sikre afvisningstilfælde før den første live-godkendelse.