# Sikkerhed for AI-agenter i din virksomhed Hver AI-agent, der kan læse en mailboks, slå op i en database eller kalde et API, er en ny dør ind i virksomheden, og den går op for enhver, der skriver de rigtige ord til den. De fleste virksomheder har allerede flere af den slags døre, end de ved af: assistenten, som en medarbejder har koblet til sin mailboks, chatværktøjet med en nøgle til fællesdrevet, agenten, som en leverandør har slået til. Vi kortlægger dørene, låser hver af dem til det, dens agent har brug for, registrerer, hvad der går igennem dem, og tester, at låsene holder. ## Kortlagt: hver agent, og hvad den kan nå En dør, du ikke kender, kan du ikke beskytte. Vi gennemgår alle agenter i brug — både dem, IT har godkendt, og dem, medarbejderne selv har koblet på — og noterer de adgangsoplysninger, hver af dem har, de værktøjer, den kan kalde, og de data, de giver adgang til. Kortet er et dokument, der ligger sammen med din konfiguration og bliver opdateret, når en ny agent kommer til — ikke et slide, der blev lavet én gang til et møde — og det er det første, en revisor, en stor kunde eller et forsikringsselskab vil bede om at se. ## Låst: hver agent med mindste privilegium En agent får sin egen identitet og kun den adgang, dens opgave kræver — [mindste privilegium](/da/glossary/#privilege): roller i stedet for delte konti ([RBAC](/da/glossary/#rbac)), kun læseadgang som udgangspunkt og skriveadgang kun gennem snævert afgrænsede værktøjer med loft over, hvor ofte og hvor meget. [Hemmeligheder](/da/glossary/#secret) deles op pr. agent og pr. vært, indsættes aldrig i en prompt og roteres uden en kodeændring. Tekst, en agent læser — en e-mail, en webside, et dokument — behandles som data, aldrig som instruktioner, så en besked, der siger »ignorer dine regler«, ikke låser noget op. Kontrollerne er fail-closed: kan et tjek ikke køre, bliver handlingen afvist. ## Registreret: hvad den gjorde, og for hvem Hvert værktøjskald [logges](/da/glossary/#logging) med den person, det blev foretaget på vegne af, hvad agenten blev bedt om, hvad den rørte ved, og hvad der kom tilbage, og loggen gemmes et sted, hvor agenten ikke selv kan ændre den. [Alarmer](/da/glossary/#alert) går i gang ved det usædvanlige — en pludselig strøm af opslag, et værktøj brugt klokken tre om natten, adgang til data, agenten aldrig før har haft brug for. Går noget alligevel galt, er det loggen, der gør en [sikkerhedshændelse](/da/glossary/#incident) til en tidslinje i stedet for et gæt. ## En lås skal afprøves, ikke tages for givet En kontrol, der aldrig er blevet afprøvet, er en kontrol, du håber virker. Vi har fundet tre beskyttelser mod brute force-angreb på samme server, som aldrig havde virket, selv om hver af dem meldte, at alt var i orden. Derfor bevises hver kontrol, vi installerer, ved hver kørsel: blokeringen afprøves mod en testadresse, reglen læses tilbage, og et injektionsangreb udføres med vilje. Er et læk allerede sket, begrænser vi skaden, udskifter det, der blev eksponeret, og skriver den regel ind i repositoryet, der forhindrer, at det samme læk sker igen. ## Arbejdet, der ligger bag Vi har udført dette arbejde på servere, i identitetssystemer og på platforme. Vi [skrev 1.000 RBAC-regler til Linux- og databaseservere](/da/portfolio/wrote-1000-rbac-rules-to-secure-linux-servers/), [ledede adgangsstyringen i M365 og single sign-on](/da/portfolio/led-access-management-across-m365-and-sso/) og [kørte et løbende sikkerhedsscanningsprogram med 21 skriftlige revisioner](/da/portfolio/ran-a-continuous-security-scanning-programme/). Vi [adskilte alle driftshemmeligheder pr. vært](/da/portfolio/split-every-operational-secret-per-host/), [tilføjede et preflight-tjek af hemmeligheder på ét sekund](/da/portfolio/added-a-one-second-preflight-for-secrets/), [fandt tre låse på døren, og ingen af dem var låst](/da/portfolio/three-locks-on-the-door-none-of-them-locked/), og [beviste, at indtrængningsblokeringen virker ved hver kørsel](/da/portfolio/proved-the-intrusion-ban-works-every-run/). Vi [byggede fail-closed rate limiting mod misbrug](/da/portfolio/built-fail-closed-rate-limiting-and-anti-abuse/) og [skrev en afgrænsningsregel efter et læk](/da/portfolio/wrote-a-scope-rule-after-a-credential-leak/). Hvordan vi selv holder orden i eget hus, kan du læse under [sådan arbejder vi sikkert](/da/security/). ## Sådan forløber et samarbejde Det begynder med ren læseadgang. Vi kortlægger hver agent, dens adgangsoplysninger og det, de giver adgang til, og giver dig fundene sorteret efter risiko, hvert med sin begrundelse og sin rettelse. Derefter laves rettelserne i din konfiguration og dit repository, gennem dit review og med tjek, der slår fejl, når en agents adgang vokser ud over kortet. Du beholder kortet, loggen og testene — den mappe, du rækker en revisor eller et forsikringsselskab — og de [data, dine agenter læser](/da/ai-data/), kan adgangsstyres på samme måde. Det købes som resten af vores arbejde, på vilkårene i [hvad det koster](/da/what-it-costs/). Har agenter allerede nøgler til dine systemer, så [fortæl os, hvilke](/da/contact/) *(vi svarer samme dag)*.