AI-agenter, der kan handle autonomt i jeres systemer, er ikke længere fremtid — det er nutid. De kan læse e-mails, opdatere databaser, sende beskeder og udføre kommandoer på vegne af jeres medarbejdere.
Men med den kapacitet følger en sikkerhedsrisiko, som mange organisationer undervurderer. Sikkerhedsforskeren Simon Willison har beskrevet det, han kalder den 'dødelige trifekta' for AI-agenter: en kombination af tre egenskaber, der tilsammen skaber en fundamental sårbarhed.
I denne artikel gennemgår vi de tre risici, forklarer hvorfor de er relevante for danske virksomheder under GDPR og NIS2, og viser konkret, hvordan vi hos Vertex Solutions adresserer dem, når vi bygger AI-agenter for vores kunder.
Risiko 1: Adgang til private og følsomme data
For at en AI-agent kan være nyttig, skal den have adgang til data. En kundeservice-agent skal kunne læse henvendelser. En juridisk assistent skal kunne tilgå kontrakter. En intern videns-agent skal kunne søge i dokumenter.
Problemet er, at de fleste AI-agent-platforme kræver bred systemadgang for at fungere. Det svarer til at give en ny medarbejder nøglen til alle skabe fra dag ét — en tilgang vi advarer imod i vores artikel om AI-agenter som digitale medarbejdere.
For virksomheder under GDPR er dette ikke blot en teknisk risiko — det er en juridisk. Hvis en agent tilgår persondata uden lovhjemmel, eller hvis data sendes til en tredjeparts-API uden databehandleraftale, kan det udløse bøder og tilsynssager.
- • Vertex Solutions' tilgang: Vores agenter opererer efter princippet om mindste privilegium. Hver agent får præcist de adgangsrettigheder, den behøver — ikke flere. Dataadgang defineres eksplicit per agent og per opgave, og al tilgang logges med fuld sporbarhed.
Risiko 2: Eksponering for upålideligt indhold (prompt injection)
Den anden risiko er mere subtil: prompt injection. Når en AI-agent læser indhold fra eksterne kilder — e-mails, websider, dokumenter fra samarbejdspartnere — kan dette indhold indeholde skjulte instruktioner, der manipulerer agentens adfærd.
Et eksempel: En agent, der behandler indgående e-mails, modtager en mail med skjult tekst, der instruerer den om at videresende alle kontrakter til en ekstern adresse. Agenten kan ikke skelne mellem legitime instruktioner og ondsindet indhold — for begge dele er bare tekst.
Dette er ikke en teoretisk trussel. Sikkerhedsforskere har demonstreret prompt injection-angreb mod alle store sprogmodeller, og ingen har endnu fundet en definitiv løsning på problemet.
- • Vertex Solutions' tilgang: Vi designer agenter med streng input-validering og sandboxing. Eksternt indhold behandles i isolerede kontekster, adskilt fra agentens kerneinstruktioner. Og kritisk: vi bygger altid et 'human-in-the-loop'-trin ind for handlinger med høj konsekvens, så en agent aldrig kan udføre følsomme operationer uden menneskelig godkendelse.
Risiko 3: Evnen til at kommunikere eksternt
Den tredje komponent i trifektaen er agentens evne til at sende data ud af organisationen. Hvis en agent kan sende e-mails, kalde API'er eller uploade filer, har en angriber — via prompt injection — potentielt mulighed for at exfiltrere følsomme data, uden at nogen opdager det.
Kombinationen af de tre risici er det farlige: Agenten har adgang til data (risiko 1), den kan manipuleres via eksternt indhold (risiko 2), og den kan sende data ud (risiko 3). Tilsammen danner de en angrebsvektor, der er fundamentalt anderledes end traditionelle sikkerhedstrusler.
For danske virksomheder under NIS2-direktivet, der stiller krav om cybersikkerhed i leverandørkæden, er dette særligt relevant. En AI-agent, der opererer på tværs af systemer, er reelt en del af jeres sikkerhedsperimeter.
- • Vertex Solutions' tilgang: Vores agenter har eksplicit definerede output-tilladelser. En agent, der analyserer dokumenter, kan ikke sende e-mails. En agent, der udkaster svar, kan ikke tilgå filsystemet. Kommunikationskanaler er whitelistet, og al udgående kommunikation logges og kan auditeres.
Vores sikkerhedsarkitektur: Fire lag af beskyttelse
Hos Vertex Solutions bygger vi AI-agenter med en sikkerhedsarkitektur i fire lag, der adresserer alle tre risici systematisk:
- • Lag 1 — Isoleret dataadgang: Hver agent har sin egen, begrænsede adgangsprofil. Ingen agent har adgang til mere, end den behøver. Datakilder forbindes via read-only API'er, hvor det er muligt.
- • Lag 2 — Input-sandboxing: Eksternt indhold (e-mails, dokumenter, API-svar) behandles i isolerede kontekster med streng validering. Agentens kerneinstruktioner er beskyttet mod manipulation.
- • Lag 3 — Output-kontrol: Handlinger med konsekvens (afsendelse af data, systemændringer, ekstern kommunikation) kræver enten menneskelig godkendelse eller eksplicit whitelist-godkendelse.
- • Lag 4 — Fuld audit trail: Hver handling, beslutning og dataudveksling logges med tidsstempel, kontekst og resultat. Logs er tilgængelige for compliance-teams og kan eksporteres til jeres eksisterende SIEM-system.
GDPR og NIS2: Hvad loven kræver af jeres AI-agenter
Under GDPR skal I kunne dokumentere, at persondata behandles lovligt, at adgang er begrænset til det nødvendige, og at I har passende tekniske og organisatoriske foranstaltninger. En AI-agent, der tilgår persondata, er en databehandling — og skal behandles som sådan.
NIS2-direktivet, der trådte i kraft i oktober 2024, stiller yderligere krav til cybersikkerhed, herunder risikostyring i leverandørkæden og incident response. Hvis jeres AI-agent bruger en tredjeparts-LLM via API, er den LLM-udbyder reelt en del af jeres leverandørkæde.
Valget mellem no-code og kodebaserede agenter har direkte indflydelse på jeres compliance-muligheder — vi gennemgår den afvejning i vores artikel om no-code vs. kode for AI-agenter.
Konklusion: Sikkerhed er ikke en feature — det er fundamentet
AI-agenter giver enorm værdi. Men den værdi realiseres kun, hvis organisationen kan stole på, at agenten ikke eksponerer data, lader sig manipulere eller handler uden for sit mandat.
Hos Vertex Solutions bygger vi ikke AI-agenter og tilføjer sikkerhed bagefter. Vi designer sikkerhedsarkitekturen først og bygger agenten inden for de rammer. Det er forskellen på en prototype og en produktionsløsning.
Hvis I overvejer at implementere AI-agenter i jeres organisation, starter samtalen ikke med 'hvilken model skal vi bruge?' — den starter med 'hvilke data har agenten adgang til, og hvem kontrollerer det?'
- • Kortlæg agentens dataadgang før I bygger — ikke efter
- • Implementér mindste privilegium: agenten får kun adgang til det nødvendige
- • Sandboxér eksternt indhold for at beskytte mod prompt injection
- • Kræv menneskelig godkendelse for handlinger med høj konsekvens
- • Log alt — og gør logs tilgængelige for compliance og audit
- • Behandl jeres LLM-udbyder som en del af leverandørkæden under NIS2