Runtime enforcement för AI-agenter

Dokumentation och register styr vad som borde hända; runtime enforcement styr vad som faktiskt kan hända. Byggstenarna är en identitet per agent (så att handlingar kan tillskrivas), policygrindar mellan agenten och dess verktyg (så att regler prövas per anrop), beloppsgränser eller känslighetsgränser som kräver mänskligt godkännande, och ett nödstopp som omedelbart drar in en agents åtkomst.

Behovet styrs av handlingsutrymmet. En chattassistent som svarar på frågor behöver inte enforcement; en agent som lägger ordrar, ändrar kunddata eller anropar betalsystem behöver det. För svenska organisationer under cybersäkerhetslagen är det behörighetshantering i ny form: samma minimiåtgärd (behörigheter och tillgång) tillämpad på icke-mänskliga identiteter.

Ärlig statusbild: runtime enforcement är en ung kategori där de flesta plattformar, CyberKlar inräknad, inte upprätthåller policyer i kundens körningsmiljö idag. Det som går att göra nu, och som all enforcement förutsätter, är grunden: fullständig inventering av agenter och deras behörigheter, dokumenterade godkännandegränser, och löpande tekniska kontroller av att behörigheterna i katalogen ser ut som beslutat. Plattformen tar också emot tekniska utvärderingsresultat från externa verktyg (robusthet, bias, prompt injection, drift) och bevisför dem per system, och kraven kan definieras som namngivna, versionerade utvärderingssviter med numeriska trösklar per agent, ett maskinellt prövbart release-kriterium. Plattformen tar även emot en passiv körningslogg per agent (körningar och händelser via API) och upptäcker när ett verktyg utanför den dokumenterade listan använts, vilket blir en driftavvikelse och ett omprövningsärende.

Sedan senaste steget finns dessutom release-gating före driftsättning som befintlig förmåga: en utvärderingsgrind (release gate) som kundens CI/CD frågar via API och får ett maskinläsbart svar från, godkänd eller blockerad med skäl. Godkänd kräver en godkänd körning av aktuell svitversion, ingen öppen driftavvikelse, att agentens modell- och promptversion matchar senast certifierad version, och att de roller som konfigurerats på agentprofilen, till exempel ägare och compliance-ansvarig, attesterat aktuell svit- och agentversion. Varje fråga skrivs som ett beslut som inte kan ändras i efterhand, med låst beslutsunderlag, och grindbeslut och attester följer automatiskt med i granskningsexporterna som driftgenererat bevis. Distinktionen är viktig: CyberKlar svarar, kundens pipeline fattar beslutet. Det är gating före driftsättning och journal som blir bevis, inte upprätthållande i körningsögonblicket: att stoppa eller blockera en agent i realtid är fortfarande färdplan.