Så utformar du en avgränsad AI-assistent med verktyg och behörigheter

En avgränsad AI-assistent styrs av ett körbart tjänstekontrakt, inte av en uppmaning i systemprompten att uppföra sig försiktigt. Om assistenten har ett verktyg och en giltig identitet som kan skicka ett meddelande finns den tekniska möjligheten kvar även när prompten säger nej. Den verkliga gränsen måste därför finnas i informationsåtkomsten, verktygsgränssnittet, behörighetskontrollen, godkännandet och exekveringsvägen. Utforma dessa delar separat för varje användarsynlig kapabilitet, så att en ofarlig sökning aldrig råkar ärva rätten att uppdatera, radera eller skicka.

Vad ska assistenten få göra?

Teamet bör först skriva ett tjänsteuppdrag i en mening och därefter dela upp uppdraget i konkreta kapabiliteter. En användbar form är: ”För behöriga användare får assistenten utföra en angiven uppgiftsfamilj med godkänd information för att skapa ett tillåtet resultat, men den får inte utföra uttryckliga icke-mål eller fatta konsekvensrika beslut.” Ange även driftsmiljö, mänsklig tillsyn, riskägare och kunskapsgränser. NIST:s AI RMF stödjer behovet av sådana dokumenterade ramar, men meningsmallen och kapabilitetsmetoden är praktisk redaktionell syntes, inte ett NIST-krav.

Ord som ”hjälpa”, ”hantera” eller ”ta hand om” döljer ofta flera helt olika befogenheter. Byt därför ut dem mot operationer som användaren faktiskt ser: söka, sammanfatta, rekommendera, skapa utkast, uppdatera, skicka, radera eller godkänna. OWASP:s princip om minsta nödvändiga verktygsfunktion talar för samma riktning. En smal operation gör både tillåten användning och förväntade avslag lättare att granska, även om den inte tar bort alla risker.

• Namnge de användare och miljöer där kapabiliteten får erbjudas.
• Beskriv vilket resultat som räknas som framgång och vilken mänsklig kontroll som återstår.
• Skriv uttryckliga icke-mål, särskilt beslut eller externa åtaganden som tjänsten aldrig får göra.
• Utse ansvariga för tjänstens beteende, åtkomst, verksamhetsöverlämning och säkerhetsincidenter.

Vilken information får varje kapabilitet använda?

Varje kapabilitet behöver en informationsram som definierar behöriga data och tillitsgränser, inte bara hur många token modellen kan läsa. Dokumentera godkända system, posttyper, informationsklassning, objektfilter, datumintervall, aktualitetskrav och användarens befintliga rättigheter. Lista också data som aldrig får gå in i kontexten. Om nödvändigt stöd saknas, är för gammalt eller inte får hämtas ska assistenten begränsa svaret eller avstå; ett större kontextfönster skapar varken rätt att läsa mer eller stöd för en slutsats.

Skilj tillfällig sessionshistorik från beständigt minne. För båda behöver ni ange vad som är berättigat, hur användare och sessioner isoleras, när information löper ut, hur den raderas och vad som aldrig får sparas. Innehåll som kommer från dokument, bilagor, externa meddelanden, API-svar eller sökresultat ska behandlas som opålitligt material. Det får bidra med fakta inom ramen men får inte tyst bli en ny instruktion till tjänsten.

• Kontrollera användarens behörighet mot varje hämtad post, inte bara mot källsystemet i stort.
• Märk källans tillitsklass och håll hämtat innehåll åtskilt från styrande instruktioner.
• Validera information innan den får bli beständigt minne och skydda minnets integritet.
• Sätt tjänstespecifika gränser för storlek, giltighet och lagring i stället för universella standardtal.

Hur ska identitet, verktyg och behörigheter upprätthålla gränsen?

Autentisering, auktorisering och godkännande ska behandlas som tre separata beslut, medan verktygsgatewayen och mottagande system upprätthåller gränsen. Autentisering fastställer vem användaren, klienten eller arbetsidentiteten är. Auktorisering avgör om den identiteten får utföra en viss operation på en skyddad resurs. Godkännande accepterar en bestämd föreslagen åtgärd. Välj uttryckligen om verktyget agerar med användarens delegerade rättigheter eller med en kontrollerad arbetsidentitet; låt det aldrig omärkligt ärva ett privilegierat operatörskonto.

Exponera validerade operationer som ”läs behörigt ärende”, ”skapa svarsutkast” eller ”skicka godkänt svar” i stället för bred åtkomst till e-post, databas, webbläsare eller kommandoskal. Begränsa verb, resurser, poster, fält, mottagare, tokenmottagare och identitetens giltighet där anropet faktiskt körs. För skyddade MCP-integrationer ger specifikationens separata resurs- och auktoriseringsroller samt resursbundna token en relevant modell, men MCP-kraven gäller inte automatiskt andra verktygsarkitekturer.

• Validera parametrar mot ett tydligt schema före verktygsanropet.
• Bevara användarens auktoriseringskontext när åtgärden utförs för den användaren.
• Begränsa frekvens, omförsök, kedjedjup, batchstorlek, tid och kostnad efter tjänstens riskbild.
• Använd idempotens, återställning och kretsbrytare där arbetsflödet kräver säkra stopp.

Samtalet kan vara sammanhängande, men befogenheten ska vara uppdelad i små kapabiliteter som kontrolleras var för sig.

Hur stort handlingsutrymme ska en kapabilitet ha?

Varje kapabilitet behöver ett uttryckligt åtgärdstak, med starkare oberoende kontroller när den går från att lämna information till att ändra omvärlden. En praktisk redaktionell trappa skiljer mellan att svara eller sammanfatta, rekommendera eller föreslå, skapa ett utkast, göra en avgränsad återställbar skrivning, orsaka en betydande extern åtgärd och möta ett förbjudet beslut. Trappan är inte en standard från NIST, NCSC eller OWASP; den översätter deras principer om minsta privilegium, åtgärdsbegränsning och mänsklig kontroll till ett arbetsformat.

1. Svar och sammanfattningar får läsa berättigat underlag men ändrar inget externt tillstånd.
2. Förslag visar ett möjligt nästa steg utan att verkställa det.
3. Utkast skapas i en icke-slutlig arbetsyta med utsedd granskare.
4. Återställbara skrivningar begränsas till godkända poster och fält samt får tydlig revisionshändelse.
5. Betydande externa åtgärder kräver giltig auktorisering, inspekterbar förhandsvisning och godkännande av den exakta åtgärden.
6. Förbjudna beslut saknar kapabilitet och nekas även om någon försöker godkänna dem i samtalet.

Håll alltid utkast skilt från sändning, återställbar uppdatering skild från radering och förslag skilt från ansvarigt beslut. För betalningar, åtkomsttilldelning, destruktiva ingrepp, produktionsändringar, väsentliga externa åtaganden och professionella högriskbedömningar behövs kvalificerad mänsklig kontroll och deterministisk verksamhetspolicy. Ett godkännande bekräftar bara den visade åtgärden: det fyller inte i en saknad behörighet, breddar inte stående åtkomst och gör inte ett förbjudet beslut tillåtet.

Vad ska hända när assistenten når en gräns?

Avslag, säker delhjälp, mänsklig överlämning och säkerhetseskalering ska vara uttryckliga tjänsteutfall med verkliga stoppvillkor. Assistenten bör ange gränsen begripligt utan att avslöja känsliga policyregler och får aldrig påstå att en källa kontrollerats, ett verktyg körts, ett godkännande erhållits eller en skrivning lyckats när det inte har skett. Om en säker del återstår kan den exempelvis skapa ett märkt utkast, lämna en checklista eller be om saknad information, men den får inte fortsätta den stoppade exekveringen i bakgrunden.

• Uppgiften ligger utanför tjänstens uppdrag eller kräver en förbjuden bedömning.
• Informationen är obehörig, otillgänglig, saknad eller för gammal för slutsatsen.
• Auktorisering eller ett giltigt åtgärdsbundet godkännande saknas.
• Ett verktyg är otillgängligt eller en gräns för tid, kostnad, frekvens eller kedjelängd har nåtts.
• Ett säkerhetstecken tyder på exempelvis privilegiehöjning, dataexfiltration, minnesförgiftning eller kringgående av godkännande.
• En kvalificerad specialist eller ansvarig verksamhetsägare måste göra bedömningen.

Överlämningen bör innehålla det ursprungliga målet, relevant icke-känslig kontext, försökt kapabilitet, orsak, tillgängligt eller saknat underlag, föreslaget nästa steg och ett spårnings-id. Skilj rutinmässig användaröverlämning från verksamhetsgodkännande och säkerhetsincident; de kan dela evidens men har olika ägare och brådska. Pågående exekvering ska förbli stoppad tills rätt mottagare har agerat, och en ändrad mottagare, text eller parameter kräver ny validering.

Hur gör teamet gränserna till en operativ design?

Teamet bör fylla i en kapabilitetsrad för varje användarsynlig operation och koppla raden till verkställbara kontroller, evidens, tester, mätetal och en ansvarig ägare. Anteckna användare och autentisering, informationsram, session och minne, smal verktygsoperation, agerande identitet, resursomfång, åtgärdstak, godkännande, driftsgränser, avslagsbeteende, loggpost, utvärderingsscenarier och eskaleringsmål. Duken är en praktisk syntes, inte en kontrollram i sig. En rad utan teknisk kontroll, observerbart utfall och beslutsför ägare är bara dokumentation.

• Definiera framgång och tillåtna resurser lika konkret som avslagsfallen.
• Knyt varje kontroll till minst ett positivt test, ett gränsfall och ett förväntat avslag.
• Bestäm vilket driftmått som avslöjar felaktig användning, svagt underlag eller oväntade verktygssekvenser.
• Ge ägaren mandat att pausa, ändra eller avveckla kapabiliteten när underlaget inte längre håller.

Exemplet visar varför en gemensam samtalsyta inte ska innebära gemensam auktoritet. Sammanfattning, utkast och sändning kan dela användarupplevelse men behöver skilda data, operationer, identiteter, åtgärdstak, tester och ägare. Loggningen ska göra begäran, tillämpad kapabilitet och policy, använda käll- och verktygsklasser, auktoriserings- och godkännandebeslut samt utfall rekonstruerbara. Hemligheter och obegränsad känslig kontext ska däremot inte sparas bara för att de kan vara praktiska vid felsökning.

Vilket underlag krävs för lansering och fortsatt drift?

Lansering kräver belägg för att både tillåten service och förväntade avslag fungerar under förhållanden som liknar den avsedda driften. Testa därför lyckade uppgifter sida vid sida med korsvis kontoåtkomst, obehöriga verktyg, gammalt eller manipulerat underlag, förbjudna data, kringgånget godkännande, ändrade parametrar, dubbla omförsök, beroendefel, dataexfiltration och okontrollerade handlingskedjor. Kända begränsningar och felmoder ska vara synliga för användare och driftansvariga. Ett godkänt testpaket är ett tidsbundet underlag, inte ett permanent bevis på säkerhet.

• Övervaka oväntad verktygsanvändning, upprepade avslag, auktoriseringsfel och ändrade godkännanden per kapabilitet.
• Följ avvikande handlingssekvenser, drift, svarstid, resursanvändning och beroendefel enligt verksamhetens risk- och integritetskrav.
• Granska åtkomst, stopp, överlämningar och incidenter med tydliga ägare och mandat att pausa tjänsten.
• Maskera hemligheter och begränsa känsligt logginnehåll samt dess åtkomst och lagringstid.

Öppna berörda tester och lanseringsunderlag på nytt när en modell, prompt, hämtningskälla, minnesregel, verktygsoperation, behörighet, policy, datamängd, leverantör eller driftmiljö ändras väsentligt. Börja med den minsta användbara kapabiliteten och utöka befogenheten genom granskade förändringar, inte genom en promptändring ensam. Ta in organisationens säkerhets-, identitets-, integritets-, informationshanterings-, risk- och tjänsteägare när känslig information, beständigt minne, privilegierad åtkomst, externa åtaganden, destruktiva ändringar eller incidentrespons berörs. Juridiska, regulatoriska och andra professionella högriskbedömningar hör hemma hos kvalificerade specialister i en separat styrd process.