Kunskap

Granska en AI-operation: auktorisering, resultat och verifierat tillstånd

Författare: Piotr AdamskiPublicerad: 2026-09-12Uppdaterad: 2026-10-10

Ett användbart auditspår svarar inte bara på “vad sade modellen?”. Det svarar vem som begärde åtgärden, vad systemet auktoriserade, vilket verktyg som användes, vad som hände i målsystemet och vilket tillstånd som återstod efter operationen.

Den distinktionen är viktig. En fullständig prompt och svar kan hjälpa vid felsökning, men de ersätter inte ett operativt register. De kan dessutom innehålla data som aldrig får kopieras in i ett loggsystem.

Börja med incident‑rekonstruktionsfrågan

Anta att en agent ändrade en kampanjbudget eller en användares behörighet för två veckor sedan. Idag frågar någon:

vem som initierade ändringen;
om operatören hade behörighet att begära den;
hur operationen klassificerades;
om mänsklig godkännande krävdes;
vem som godkände exakt vad;
vilka relevanta parametrar som skickades till verktyget;
vad den externa leverantören returnerade;
om det resulterande tillståndet verifierades;
vilken version av säkerhetspolicyn som tillämpades.

Om svaren på dessa frågor kräver att man manuellt kombinerar chatt‑historik, HTTP‑loggar, en databas och leverantörskonsolen, har vi loggar. Vi har ännu inte ett bra auditspår.

Ett minimalt operationsregister för en agent

Varje system kommer att skilja sig. För verktygs‑användande agenter är ett användbart kärninnehåll:

Fält	Varför registrera
`event_id`	unikt identifiera händelsen
`timestamp`	ordning och tidpunkt
`operator_id`	person eller principal som begärde åtgärden
`agent_id` / `agent_version`	identifiera den involverade agenten/modellen
`task_id` / `correlation_id`	koppla flera anrop till ett arbetsflöde
`tool`	verktyg eller metod som användes
`operation_class`	read / write / operate / destructive eller motsvarande lokalt
`target_resource`	konto, tenant, projekt eller resurs som påverkades
`authorization_decision`	allow / deny samt vilka scopes/policy som användes
`approval_id`	bevis på godkännande när det krävs
`request_fingerprint`	fingeravtryck av normaliserade parametrar när full data är onödig
`provider_result`	kontrollerat resultat utan hemligheter
`resulting_state`	tillstånd läst efter förändringen, eller referens till bevis
`policy_version`	regeluppsättning som gällde vid exekveringstidpunkten

Inte varje värde måste lagras som text i samma post. Vissa kan referera till separata bevis‑artefakter. Det viktiga är att kunna rekonstruera kedjan på ett koherent sätt.

Konversationsloggar och auditspår löser olika problem

En konversationslogg ger kontext

Den kan visa vad användaren frågade, vad modellen svarade och vilken information som fanns i sessionen.

Ett auditspår ger exekveringsbevis

Det bör visa:

operator
→ authorization decision
→ tool
→ parameters material to the action
→ approval if required
→ provider outcome
→ resulting state

Om en modell skriver “kampanjen har pausats” men det saknas verktygshändelse och ingen tillståndsläsning från målsystemet, har vi ett påstående. Vi har inget exekveringsbevis.

Vad som vanligtvis hamnar på raderings‑ eller exkluderingslistan

Mer loggning betyder inte automatiskt bättre auditabilitet. Det kan innebära en större yta för dataläckage.

I vårt interna Brillnet Ads MCP exkluderas kredentialer, auktoriserings‑headers och råa personidentifierare från audit‑poster. Samma princip är användbar på andra ställen.

Logga inte hemligheter

API‑nycklar;
access‑ eller refresh‑tokens;
privata nycklar;
lösenord;
sessions‑cookies;
kompletta Authorization‑headers.

Om ett auditspår måste visa vilken identitet eller vilket credential‑set som användes, lagra en säker referens‑identifierare i stället för själva hemligheten.

Kopiera inte varje request och response automatiskt

Ett rått API‑svar kan innehålla personuppgifter, konfidentiella fält eller information som är irrelevant för audit‑syftet. Välj den metadata som behövs för beslutet och det resulterande tillståndet i stället.

Gör inte hela prompten till ett obligatoriskt auditfält

Promptar kan vara användbara för diagnostik. De kan också innehålla kunddokument, personuppgifter eller en hemlighet som klistrats in av misstag. Prompt‑bevarande bör följa en separat datalagrings‑ och åtkomstpolicy, inte antagandet att “AI betyder logga allt”.

Radera innan du persisterar

Om vi först persisterar en komplett payload och sedan kör maskering, har hemligheten redan kommit in i loggsystemet.

Ett säkrare flöde är:

tool returns outcome
↓
normalisation
↓
field classification
↓
redaction / pseudonymisation
↓
audit record persistence

Känslig data kan förbli i källsystemet som redan har egna åtkomst‑ och lagringskontroller. Audit‑systemet bör behålla det minsta som behövs för att rekonstruera beslutet och effekten.

Read‑after‑write stänger gapet mellan “called” och “changed”

För skrivoperationer registrerar vi inte bara anropsresultatet utan – när leverantören tillåter det – tillståndet i målsystemet efter förändringen.

Exempel:

14:02:11 write request: campaign status → PAUSED
14:02:12 provider: success
14:02:13 read-after-write: campaign.status = PAUSED

Det låter oss särskilja:

agenten begärde en förändring;
leverantören accepterade begäran;
resursen hade det förväntade tillståndet när det verifierades.

Det bevisar inte att tillståndet aldrig ändrades en sekund senare. Det är fortfarande ett mycket starkare bevis än ett modellmeddelande som säger “klart”.

Godkännande bör vara en oberoende audit‑händelse

Mänskligt godkännande bör ha sin egen identifierare och bindas till en specifik operation.

Ett konceptuellt register kan innehålla:

approval_id: apr_...
approved_by: operator_...
approved_at: 2026-09-12T14:01:44+02:00
action_hash: sha256(...)
operation: ENABLE_CAMPAIGN
target: campaign_...
expires_at: ...

Exekveraren kan då verifiera att ett godkännande finns för just den versionen av operationen i stället för att lita på ett chattmeddelande som säger “användaren godkände”.

Read: When should an AI agent require human approval?

Integritet: append‑only‑poster och hash‑kedjor

I vårt interna Ads MCP‑verktyg är audit‑poster append‑only och hash‑kedjade. Målet är att göra tyst förändring av historiken enklare att upptäcka.

Konceptuellt:

record_1 + hash(record_1)
↓
record_2 contains hash(record_1)
↓
record_3 contains hash(record_2)

Om en äldre post ändras, matchar efterföljande länkar inte längre.

Det är ingen magisk oföränderlighet. En administratör med tillräckligt bred åtkomst kan fortfarande förstöra loggsystemet eller hela lagret. Post‑integritet bör därför kombineras med:

begränsad logg‑åtkomst;
definierad retention;
backup/export där det är motiverat;
övervakning av luckor eller kedjebrott;
kontrollerad tid och identifierare.

Användbar telemetri för MCP‑verktyg

För tools/call eller en motsvarande lokal operation är ofta följande fält användbara:

verktygsnamn;
riskkategori;
normaliserade resurs‑identifierare;
utvärderade scopes;
auktoriseringsresultat;
om en förhandsgranskning av åtgärden visades;
godkännandenummer;
start‑ och sluttid;
leverantörsstatus;
kontrollerad felkod;
om en retry inträffade;
idempotensnyckel eller ett säkert fingeravtryck av den;
resulterande tillstånd efter en skrivning;
modell/agent‑identifierare i den omfattning som behövs för diagnostik.

Det kräver inte att varje rått verktygsargument lagras.

Vad sägs om chain‑of‑thought?

Vi behöver inte modellens privata resonemangskedja för att skapa ett användbart operativt auditspår. Vi behöver observerbara fakta:

beslut‑relevant input;
vald operation;
tillämpad policy;
godkännande;
resultat;
resulterande tillstånd.

När en motivering är användbar kan en agent skriva ett kort explicit decision_reason avsett för granskning. Det skiljer sig från att försöka bevara modellens dolda resonemangsprocess.

Retention: “för alltid” är vanligtvis ett dåligt standardvärde

För varje händelseklass definiera:

behandlingssyfte;
lagringstid;
vem som kan komma åt den;
om data kan aggregeras eller pseudonymiseras;
när en post är affärsbevis kontra ingenjörs‑telemetri;
hur laglig/operativ radering fungerar där det krävs.

Behåll inte felsöknings‑telemetri och formella beslutsregister tillsammans på obestämd tid utan en tydlig anledning.

Exempel på incident‑rekonstruktion

Situation: en kampanj började spendera pengar trots att den förväntades vara pausad.

Ett användbart auditspår bör låta oss följa:

task_id — var begäran kom ifrån;
operator_id — vem som initierade den;
tool — vilket verktyg som valdes;
operation_class=operate — varför extra kontroll tillämpades;
approval_id — om någon faktiskt godkände aktiveringen;
parametrar — vilken status och budget som omfattades av godkännandet;
leverantörsresultat — vad Google Ads accepterade;
read‑after‑write — vilket tillstånd som observerades efter exekveringen;
senare händelser — om en annan aktör ändrade statusen igen.

Utan den kedjan får vi bara läsa chatt‑historik och gissa.

AI‑agent‑auditspår‑checklista

Varje materiell händelse har ett unikt ID och en tidsstämpel.
Operatörs‑identitet och agent‑identitet är separata.
Flera anrop kan förenas av ett task‑/correlation‑ID.
Auktoriseringsbeslut registreras, inte bara lyckade anrop.
Godkännande är en separat verifierbar händelse.
Parametrar som är materiella för konsekvensen lagras eller fingeravtrycks‑hashas.
Hemligheter och auktoriserings‑headers exkluderas före persistering.
Personuppgifter minimeras/redigeras.
Retries och idempotens är observerbara.
Skrivningar har leverantörsresultat och, där praktiskt, read‑after‑write‑bevis.
Policys version kan rekonstrueras.
Audit‑åtkomst är striktare än vanlig applikationsåtkomst.
Retention definieras i stället för att vara en olyckshändelse.
Integriteten i spåret övervakas.

Vem är den här guiden för

Processägare och utvecklare behöver exekveringsbevis. Exempel på åtgärder inkluderar förändring av tillverknings‑kvalitetstickets, utskick av fastighetsägarmeddelanden och hantering av IT‑behörigheter. Detta är design‑scenarier, inte påståenden om befintliga implementationer; processen bestämmer vilket bevis som krävs.

Ads MCP är ett internt designexempel för Brillnet‑ägda konton, snarare än en kundtjänst‑ eller oberoende produktionsutvärdering.

Ett okänt resultat måste förbli tydligt okänt

En timeout bevisar inte misslyckande: servern kan ha slutfört skrivningen innan svaret försvann. Skilj på requested, accepted, verified och unknown. Rapportera inte osäkerhet som framgång.

Integrationsägaren definierar rekonsiliation med leverantörens jobb‑identifierare eller resursreferens. Involvera operatören innan du upprepar olösta hög‑påverkande åtgärder. Lägg till ett länkat rekonsiliations‑event i stället för att skriva om historiken.

Fördröjd skriv‑synlighet kräver samma omsorg. Ett gammalt tillstånd kan spegla leverantörens konsistensmodell. Registrera observationstid och begränsning. Retries behöver ett ändligt tak och ett slutligt statusvärde som människor kan förstå.

Bestäm vad som händer när audit‑leverans misslyckas

Loggning kan förlora anslutning, ta slut på diskutrymme eller avvisa poster. OWASP rekommenderar att testa fel. Bestäm separat vilka konsekventa åtgärder som kan fortsätta under fördröjd leverans och vilka som kräver hållbart besluts‑bevis först.

Det betyder inte att hela företaget måste stoppas för ett saknat diagnostiskt meddelande. Separera rutin‑telemetri från bevis på en godkänd operation. En behörighetsändring kan kräva hållbart auktoriserings‑bevis innan exekvering; att läsa en offentlig manual kan tillåta begränsad metadata‑buffring. Detta är exempel på designbeslut, inte universella OWASP‑krav.

En buffert behöver kapacitetsgränser, åtkomstkontroller och fördröjnings‑övervakning. Bevara original‑identifierare och händelsetider under återställning. Spåra saknade händelser för att särskilja inaktivitet från förlorad synlighet. Skicka en varning till någon som kan återställa inspelning eller stoppa den drabbade klassens operationer.

Ett fingeravtryck tar inte automatiskt bort integritetsrisk

Hashning av en e‑postadress kan fortfarande identifiera en person genom jämförelse med en kort lista av kända adresser. Där operatörs‑identifikation är viktig, överväg ett slumpmässigt internt ID och en separat skyddad mappning. Audit‑läsare behöver inte automatiskt ha den mappningen.

Ett request_fingerprint behöver också en definierad normaliseringsmetod och schemaversion. En hash är otillräcklig om ingen kan fastställa vad den täckte. Definiera en säker bevisplats, men undvik att behålla ett helt dokument enbart för att kunna återberäkna dess hash. Processägaren specificerar evidensbehov; den ansvarige för dataskydd granskar den data som behålls.

Rekonstruera en händelse utan agenten

Använd ett fiktivt servicedesk‑ärende. En operatör godkänner att skicka ett meddelande till en specificerad leverantör. Agenten väljer verktyget, gatewayen kontrollerar scope och servern registrerar resultatet och meddelande‑identifieraren. I ett andra körning ändras mottagaren efter godkännande. Exekveringen ska avvisas med ett registrerat skäl. Använd testdata i stället för riktiga kunddokument.

Ge en opartisk granskare bevis‑paketet. De ska kunna fastställa operatör, godkänt innehåll, mottagare, tillämpad policy och faktisk effekt. Om de måste fråga agenten vad den avsåg, är paketet ofullständigt. Åtgärda den saknade relationen i stället för att automatiskt lagra hela konversationen.

Processägaren äger acceptans. Utvecklaren levererar export och kontrollerade fel. Logg‑administratören kontrollerar åtkomst och paket‑integritet. Ett litet företag kan låta flera roller falla på samma person, men ansvaret måste fortfarande vara explicit definierat.

Vad du kan göra i morgon

Välj en konsekvent åtgärd och identifiera varje system som registrerar den. Lägg till ett gemensamt korrelations‑ID. Lista behållna fält och exkluderade fält. Kör ett tillåtet och ett avvisat försök med testdata, och rekonstruera sedan båda från en export.

Mät konsekventa åtgärder med kompletta spår, olösta resultat och fördröjning mellan åtgärd och tillgängligt bevis. Sätt process‑trösklar. Loggvolym bevisar inte nytta: ett saknat steg kräver fortfarande undersökning.

Tekniska rekommendationer bestämmer inte juridisk retention

NIST SP 800‑92 behandlar logghantering. AU‑kontrollfamiljen i NIST SP 800‑53 hjälper till att organisera audit‑krav; inget av dokumenten ger någon certifiering eller fastställer en enhetlig lagringstid för alla företag. OWASP är inte lagstiftning. Identifiera juridiska och kontraktsmässiga skyldigheter separat, med deras tillämpliga räckvidd och grund. Denna guide föreskriver ingen lagstadgad lagringstid.

Gräns

Ett auditspår bevisar inte automatiskt att ett beslut var korrekt. Det bevisar vad systemet registrerade om hur åtgärden auktoriserades och exekverades. Reglerade processer kan behöva ytterligare krav på integritet, retention, integritetsskydd och bevisvärde.

Se även Least privilege for AI agents och Brillnet Security.

En syntetisk repetition av finansiell verksamhet

Använd en dedikerad demonstrationsmiljö med en fiktiv faktura. Den föreslagna agentoperationen ändrar fakturans interna granskningsstatus; det flyttar inte pengar. Ge operatören och agenten distinkta identiteter, begränsa postens omfattning och begär att lämplig person godkänner operationen. Spela in policyversionen och beslutet, utan att lagra referenser eller ett fullständigt konfidentiellt transkript.

Efter tillåten operation läser du fakturastatus och relevant ändringshistorik. Jämför dem med det efterfrågade resultatet. Ett tekniskt svar som säger accepterat är inte bevis på att den avsedda förändringen inträffade. Behåll förfrågningsidentifieraren, resultatet och referensen till det kontrollerade tillståndet så att en annan person kan rekonstruera sekvensen.

Försök sedan en operation som utesluts av demonstrationspolicyn. Inspektera avslaget och bekräfta att relevant tillstånd inte ändrades. Detta visar en specifik gräns i den fiktiva uppställningen. Det är inte ett bevis på att varje agentverktyg, ekonomisystem eller kundmiljö har samma kontroll.

Använd Pulsar för att registrera kontrollkrav, ägare, övningsåtgärder och bevis. Den 14-dagars provperioden testar arbetsflödet för efterlevnad. Det inkluderar inte en komplett revisionsplattform för agentdrift, bankförbindelse eller betalningsauktoriseringstjänst. En riktig integration eller pilot behöver en separat överenskommen omfattning. Granska testperiodens obligatoriska betalningsmetod, valda plan och avbokningsvillkor innan du börjar.

Källor

De tekniska källorna stödjer de angivna principerna. Implementationsscenarier och handlingsplanen är författarens designrekommendationer.

OWASP AI Agent Security Cheat Sheet — accessed: 2026-10-02.
OWASP MCP08:2025 — Lack of Audit and Telemetry — accessed: 2026-10-02.
Källor kontrollerade: 2026-10-10.
OWASP — Logging Cheat Sheet — Användbara händelseregister och utesluten känslig information.
NIST SP 800-92 — Log Management — Logghantering.
NIST SP 800-53 Rev. 5 — Tillträdeskontroll och revisionskontrollprinciper.
MCP — security best practices — Integrationssäkerhet och behörighetsgränser.
Pulsar GRC — actual scope — Krav, kontroller, bevis och testperiod.
Publicerad produktomfattning och testvillkor — Publicerad produktomfattning och testvillkor.

Granska villkoren och påbörja den 14-dagars provperioden

Minsta privilegium för AI-agenter i ett SaaS med flera hyresgäster

Livsmedelsproduktion CAPA: från ett resultat till effektivitetsgranskning

En farmaceutisk SOP ändrad: kontrollera utbildnings- och källversionen