CISA (USA), NSA (USA), ASD (Australia), CCCS (Canada), GCSB (New Zealand) og NCSC (Storbritannia) publiserte fredag en felles veiledning for sikker utrulling av agentic KI. Bakgrunnen er at autonome agenter allerede er i drift i kritisk infrastruktur og forsvarssektor uten det myndighetene mener er tilstrekkelige sikkerhetsbarrierer. Veiledningen retter seg mot utviklere, integratorer og driftsoperatører.
Hovedbudskapet er pragmatisk: agentic KI krever ikke en helt ny sikkerhetsdisiplin. Organisasjoner skal innlemme agenter i eksisterende rammeverk og styringsstrukturer, og anvende etablerte prinsipper som zero trust, defense-in-depth og least-privilege. Det er en annen tone enn EU AI Acts dokumentkrav, og fokuserer på driftsmessige kontroller fremfor compliance-papirer.
«Inntil sikkerhetspraksis, evalueringsmetoder og standarder modnes, bør organisasjoner anta at agentic KI-systemer kan oppføre seg uventet og planlegge utrulling deretter. Prioriter motstandsdyktighet, reversibilitet og risikobegrensning fremfor effektivitetsgevinster» — Five Eyes-veiledningen
Dokumentet identifiserer fem risikokategorier. Privilegium-risiko handler om at agenter med for bred tilgang gjør én kompromittering mye verre enn en typisk programvaresårbarhet. Design- og konfigurasjonsfeil skaper hull før systemet i det hele tatt går live. Adferdsrisiko dekker tilfeller der en agent forfølger målet sitt på måter utviklerne aldri forutså. Strukturell risiko gjelder agent-til-agent-nettverk der feil kan kaskadere. Ansvarsrisiko handler om at agenters beslutninger er vanskelige å inspisere, og at logger er vriene å parse, slik at incident response blir tregere.
Identitetsforvaltning får mest plass. Hver agent bør ha en verifisert, kryptografisk sikret identitet, bruke kortlevde tilganger, og kryptere all kommunikasjon med andre agenter og tjenester. For handlinger med høy konsekvens skal et menneske signere av. Veiledningen er eksplisitt på at det er systemdesigneren, ikke agenten selv, som avgjør hvilke handlinger som krever godkjenning. Konsekvensene når noe går galt er konkrete: endrede filer, modifiserte tilgangskontroller og slettede revisjonsspor.
For norske utviklere som bygger med Claude Agent SDK, LangChain eller egne MCP-løsninger er dette en bekreftelse på en arkitektur du sannsynligvis allerede tenker på, men sjelden implementerer fullt. Veiledningen er ikke bindende for norske organisasjoner, men Norge er medlem av NATO Cooperative Cyber Defence Centre of Excellence og samarbeider tett med flere av de fem partene. Forvent at krav om agent-identitet og godkjenningsterskler dukker opp i neste runde med sikkerhetsleveranser fra leverandørene dine.
Hva bør du gjøre?
- Gi hver agent egen identitet i stedet for å la dem dele en service account. OAuth client credentials med kort levetid er minimum.
- Definer hvilke handlinger som krever menneskelig godkjenning før du deployer. Send penger, slett data, endre tilganger, deploy til produksjon. Ikke etterpå.
- Logg agentens beslutningssteg, ikke bare API-kall. Når noe går galt vil du forstå hvorfor agenten valgte den filen, ikke bare at den ble slettet.
- Behandle prompt injection som en gjenværende risiko. Veiledningen erkjenner at problemet kanskje aldri blir løst. Plan deretter.