När bör en AI‑agent kräva mänsklig godkännande?

Inte vid varje steg. Om en person måste godkänna varje läsning och varje låg‑risk verktygsanrop kommer de snabbt att börja klicka mekaniskt. Godkännande är värdefullt där ett agentmisstag kan leda till en verklig konsekvens: finansiell, extern, administrativ, juridisk, säkerhetsrelaterad eller svår att återställa.

Det finns en annan viktig poäng: kontrollnivån bör inte bero på hur säker modellen låter sig låta. En självsäker modell kan fortfarande vara felaktig. Vi väljer kontrollen baserat på konsekvensen av handlingen.

En beslutsmodell: fem frågor innan autonomi beviljas

För varje agentåtgärd kontrollerar vi fem egenskaper.

1. Ändrar operationen tillstånd?

En läsning är vanligtvis lägre risk än en skrivning. Inte alltid – en läsning kan exponera känslig data – men att separera läs från skriv är en användbar startpunkt.

2. Lämnar konsekvensen det interna systemet?

Att skicka ett e‑postmeddelande, publicera ett inlägg, aktivera en annons, utfärda ett dokument eller svara en kund är externt synligt. Ett misstag blir omedelbart ett relations‑, kostnads‑ eller ryktesproblem.

3. Skapar operationen kostnad eller åtagande?

En agent kan utföra ett API‑anrop korrekt och ändå fatta fel affärsbeslut. Budget, inköp, betalning, prenumerationer eller resursreservationer kräver en separat gräns.

4. Kan förändringen återställas enkelt?

Att ändra en etikett och att radera ett konto är inte i samma klass. Tänk på återställningskostnad, återställningstid, dataförlust och påverkan på andra användare.

5. Ändrar operationen säkerhet eller behörigheter?

Att bevilja administratörsåtkomst, rotera en hemlighet, göra en resurs publik eller ändra MFA‑policy förtjänar kontroll även om åtgärden tekniskt sett är återställningsbar.

En praktisk autonomimatriser

Nivå	Åtgärdskaraktäristik	Exempel	Standardbeslut
A — autonom	enbart läsning, låg påverkan, strikt avgränsad	tjänststatus, kostnadsrapport, uppgiftslista	agent får utföra
B — autonom med audit	återställningsbar skrivning i ett begränsat område	lägga till en tagg, spara ett utkast, skapa en uppgift	agent får utföra med explicit tillstånd och loggning
C — godkännande före effekt	extern konsekvens, finansiell effekt eller materiell förändring	skicka ett meddelande, publicera, aktivera en kampanj	människa godkänner den specifika operationen
D — stark kontroll	destruktiv, säkerhetskänslig, svår att återställa	radera data, ändra admin‑åtkomst, återkalla en nyckel	separat avgränsning + godkännande + förhandsgranskning; ofta ytterligare verifiering

Detta är en operativ modell, inte en juridisk standard. Ett specifikt system bör anpassa nivåerna efter sina data, regler, konsekvenser och återhämtningsmekanismer.

Godkännande bör bindas till en specifik konsekvens

Ett dåligt godkännandefönster ser ut så här:

Agenten vill utföra en handling. Fortsätt? Ja / Nej.

Personen vet inte vad de godkänner.

En bättre förhandsgranskning ser mer ut så här:

Operation: AKTIVERA KAMPANJ
Konto: Brillnet Ads / [mänskligt läsbar identifierare]
Kampanj: Sök – Pulsar GRC
Genomsnittlig daglig budget: PLN 80
Mål: Polen
Ändring: PAUSED → ENABLED
Återställningsbart tillstånd: kampanj kan pausas igen; ackumulerad förbrukning återställs inte
Konsekvens: efter godkännande kan kampanjen börja generera kostnad
Beslutskälla: uppgift #…

Endast då har en “Godkänn”-knapp meningsfull betydelse. I Google Ads är en genomsnittlig daglig budget inte ett strikt samma‑dagars tak: för de flesta kampanjer är den dagliga faktureringsgränsen dubbelt så hög. Förhandsgranskningen bör förklara denna konsekvens snarare än att lova ett tak på PLN 80.

Godkännande får inte bli ett generellt pass för framtida förändringar

Anta att en person godkänner:

skicka detta meddelande till 12 mottagare

Om agenten ändrar innehållet eller mottagarlistan till 1 200 personer efter godkännandet, bör det ursprungliga godkännandet inte längre gälla.

En praktisk regel är:

Godkännande är bundet till en specifik normaliserad operation. En materiell förändring av parametrarna ogiltigförklarar godkännandet och kräver ett nytt.

En implementation kan binda godkännande‑ID till en hash av operationens parametrar, en resursversion eller någon annan stabil representation av vad som faktiskt godkändes.

Modellen bör inte själv avgöra om godkännande kan hoppas över

En modell kan bli ombedd att uppskatta risk. Det kan vara ett användbart signal. Det bör inte vara den enda kontrollen.

Om policyn är:

när modellen anser en operation riskabel, frågar den en människa

så kontrollerar modellen också den mekanism som är avsedd att begränsa effekten av sina egna misstag.

En starkare design är:

1. Modellen väljer verktyg och parametrar.
2. Gatewayer klassificerar operationen med explicit policy.
3. Policy‑motorn bestämmer om godkännande krävs.
4. En person godkänner när det krävs.
5. Först då sker exekveringen.

Modellen kan leverera förklaringen. Den slutgiltiga klassificeringen kommer från systempolicy.

Exempel från vår egen automation: förbereda en kampanj är inte samma sak som att starta spendering

I vår interna Brillnet Ads MCP separerar vi möjligheten att förbereda eller ändra en kampanj från möjligheten att aktivera spendering.

En ny skapad kampanj får standardvärdet PAUSED när inget annat statusvärde uttryckligen anges. Att spara konfigurationen är inte samtycke till att börja spendera. Att aktivera den operativa effekten kräver ett explicit “operate‑permission” och bekräftelse i begäran. Ett enbart bekräftelsefält bevisar inte att en person har granskat handlingen. Det beviset kräver den oberoende godkännandemechanism som beskrivs ovan.

Denna lilla separation ger ett användbart resultat:

• agenten kan slutföra det mesta av förberedelsearbetet;
• en person behöver inte manuellt fylla i varje fält;
• budgeten startar inte bara för att modellen bedömt att konfigurationen var klar.

Samma mönster kan tillämpas på andra arbetsflöden:

Förberedelse	Effekt som kräver separat beslut
utkast till e‑post	skicka den
föreslå en användarroll	bevilja åtkomst
migrationsplan	verkställa migration
lista filer att ta bort	radera dem
föreslagen prisändring	publicera det nya priset
förberedd betalning	auktorisera betalning

När godkännande kan vara onödigt

Inte all automation behöver vara semi‑automatisk.

Mänskligt godkännande tillför ofta lite värde när alla dessa villkor är sanna:

• operationen är enbart läsning eller har låg påverkan;
• agenten arbetar inom ett smalt, förhandsgodkänt omfång;
• resultatet publiceras inte automatiskt;
• ett misstag är lätt att upptäcka och reparera;
• det finns ingen kostnad eller externt åtagande;
• behörigheter och säkerhetsinställningar förblir oförändrade;
• handlingen lämnar tillräckligt med audit‑evidens för att rekonstruera resultatet.

Exempel: en agent hämtar kampanjstatus varje dag och förbereder en intern rapport. Att kräva mänskligt godkännande för varje läsning ökar inte säkerheten i proportion till den operativa kostnaden.

När vi rekommenderar godkännande som ett minimum

I våra projekt skulle jag inte bevilja autonom exekvering utan separat analys för operationer som:

• skickar kund‑ eller offentliga kommunikationer;
• startar eller ökar spendering;
• raderar eller skriver över data utan en enkel återhämtningsväg;
• beviljar, utökar eller återkallar behörigheter;
• modifierar hemligheter, säkerhetskonfiguration eller MFA;
• accepterar juridiska villkor för en organisations räkning;
• agerar på en tvetydigt identifierad resurs;
• triggar ett annat system som i sin tur kan utföra hög‑påverkande åtgärder.

Det betyder inte att mänskligt godkännande alltid är den enda kontrollen. För kritiska handlingar bör det vara en av flera lager.

Se upp för godkännandetrötthet

Om ett system ber om godkännande 80 gånger per dag, slutar användarna läsa meddelandena. Godkännande blir ett slags anställd‑CAPTCHA.

Det pekar vanligtvis på ett av tre designproblem:

1. riskklassificeringen är för bred;
2. arbetsflödet grupperar inte logiskt relaterade förändringar;
3. agenten har för lite säker autonomi vid låg risk, så allt eskaleras.

Svaret är inte att dölja varningar. Det är att designa bättre gränser.

Vad ett användbart godkännandemechanism bör göra

Visa diffen, inte hela objektet

För konfiguration, visa före → efter och de fält som förändras. Tvinga inte granskaren att manuellt jämföra två skärmar.

Ange konsekvensen

“Spara förändring” är svagare än “Aktivera kampanj — den kan börja generera spendering med en genomsnittlig daglig budget på PLN 80”.

Ha ett omfång och en livslängd

Ett gammalt godkännande bör inte fortsätta att auktorisera en operation efter att kontexten har förändrats.

Avvisa materiellt förändrad operation

Om parametrarna ändras efter godkännande, måste godkännandet upphöra.

Lämna ett oberoende register

Audit‑posten bör ange vem som godkände vad, när och under vilken operationsidentifierare. Den får inte enbart förlita sig på ett modellmeddelande som säger “användaren godkände”.

Read: AI agent audit trails

Checklista för en enskild agentåtgärd

Innan autonomi beviljas, svara på:

• Är handlingen enbart läsning?
• Ändrar den affärstillstånd?
• Skapar den kostnad eller ett åtagande?
• Är resultatet externt synligt?
• Involverar den personuppgifter eller konfidentiell data?
• Ändrar den roller, behörigheter eller säkerhetskonfiguration?
• Är den lätt att återställa?
• Är målresursen entydig?
• Kan en återförsök utföra handlingen två gånger?
• Kan systemet visa en konkret förhandsgranskning före exekvering?
• Kommer godkännandet att bindas till exakt samma parametrar?
• Kan det resulterande tillståndet verifieras efter exekvering?

Om en handling kombinerar flera hög‑risk‑karaktäristik kan ett enda “OK” i sig vara en för svag kontroll.

Genomarbetat exempel: ett tjänsteföretag skickar en kundrapport

Tänk på ett föreslaget arbetsflöde snarare än en rapporterad driftsättning. En agent hämtar godkända poster, jämför deadlines och förbereder en rapport. Kontots ägare förblir ansvarig för innehållet. Processägaren definierar vilka data som får användas och vem som kan auktorisera leverans.

Utkastförberedelse kan köras inom det förhandsgodkända omfånget. Innan utskick, visa kunden, exakt mottagaradress, ämne, meddelande och bilagor, tillsammans med käll‑dataversionen. Granskaren bör kunna inspektera dokumentet direkt. Att bara lita på modellens sammanfattning försvagar granskningen.

Godkännandet täcker just det paketet. Att lägga till en mottagare, byta ut en bilaga eller ändra en materiell rekommendation ogiltigförklarar det. En tidigare definierad regel kan tillåta en stavningskorrigering, men den får inte bli en tillåtelse att ändra meningen. Processägaren definierar vad som är materiella förändringar; exekveringskomponenten verkställer gränsen.

Vad godkännandeposten bör innehålla

Koppla godkännandet till person, roll, tenant, verktyg, målresurs, dataversion, parametrar, utgångstid och uppgiftsidentifierare. Skilj på föreslagen, väntande, godkänd, exekverande och osäker utgång. Operatören bör veta om ett klick förbereder en handling eller triggar den.

En parameter‑hash hjälper att upptäcka substitution. Den bevisar inte att en person läst förhandsgranskningen. Ett tydligt gränssnitt och en auktoriserad granskare är fortfarande avgörande. En person utan rätt att bevilja administratörsåtkomst får inte erhålla den rättigheten via ett agent‑godkännandefönster.

För batch‑operationer, visa antalet objekt, materiella undantag och total effekt. Ett godkännande kan täcka en exakt definierad batch. Det kan inte täcka godtyckliga ytterligare objekt som väljs efter godkännandet. Detta minskar upprepade dialoger utan att förlora kontroll över omfånget.

Hantera osäker exekvering innan återförsök

En leverantör kan utföra en begäran även när svaret aldrig når agenten. Avsaknad av bekräftelse är inte bevis på misslyckande. Att återförsöka kan skicka ett andra e‑post, skapa ett duplicerat dokument eller medföra extra kostnad. Kontrollera först begärans identifierare och leverantörens tillstånd.

Där idempotensnycklar stöds, bind en sådan till operationen och återanvänd den för samma begäran. Annars, implementera dupliceringsdetektering eller be operatören fatta beslut efter att ha kontrollerat tillståndet. Registrera en osäker utgång ärligt. Att klicka två gånger löser inte ett okänt resultat.

Tystnad är inte godkännande

Tilldela en ställföreträdare och en notifieringskanal för varje process. Utgång utan svar blockerar den gate‑ade operationen. Agenten kan fortsätta förbereda annat godkänt, låg‑risk arbete; den får inte tolka tystnad eller en affärsdeadline som samtycke.

Definiera nödstopp separat. Rättigheten att stoppa ett felaktigt arbetsflöde kan vara snävare än rättigheten att starta det. Bevara exekveringstillståndet och listan över slutförda handlingar. Återställning av konfiguration kan inte återkalla ett kundmeddelande som redan har lästs.

Kontrollera om granskning ändrar beslut

Spåra korrigeringar, avslag, väntetid och försök att exekvera materiellt förändrade parametrar. Jämför operationstyper separat. Långsam godkännande av kundkommunikation bör inte hindra autonom intern uppgiftsförberedelse.

Om varje förslag godkänns omedelbart under veckor, granska ett urval med processägaren. Policyn kan vara för bred, eller förhandsgranskningarna kan sakna viktig information. Ett högt antal godkännanden är inte bevis på säkerhet.

Imorgon, välj en extern handling. Bygg dess förhandsgranskning, identifiera en auktoriserad granskare, definiera utgångstid och verifiera att förändring av mottagare ogiltigförklarar godkännandet. Bekräfta att avslag inte ger någon extern effekt.

Rekommendationer och källgränser

OWASP behandlar kontroller för hög‑påverkande åtgärder och godkännandintegritet. Riktlinjer för transaktions‑auktorisation behandlar server‑sidans verifiering av betydande transaktionsdata. NIST AI RMF är frivillig risk‑hanteringsvägledning. Vår A–D‑matris är en ingenjörsrekommendation, inte ett juridiskt krav på att godkänna varje AI‑åtgärd. Intern Ads MCP‑dokumentation daterad 28 juli 2026 beskriver den citerade kontrolldesignen; den bevisar inte oberoende produktionsdrift för en kund.

Gräns

Denna klassificeringsmodell är vår ingenjörspraxis, inte juridisk rådgivning eller en formell risk‑bedömningsstandard. Reglerade, medicinska, finansiella eller säkerhetskritiska processer kan kräva starkare kontroller.

Se även MCP and AI agents: designing safer tools och Least privilege for AI agents.

Källor

• OWASP AI Agent Security Cheat Sheet. Accessed: 2026-10-02.
• OWASP Transaction Authorization Cheat Sheet. Accessed: 2026-10-02.
• NIST AI Risk Management Framework. Accessed: 2026-10-02.
• Google Ads Help — About spending limits. Accessed: 2026-10-02.