Tilladelser til AI-agentværktøjer: hvorfor en standardafvisning vinder

Hvorfor en standardforbud virker bedre end at forsøge at blokere hver enkelt dårlig anmodning

Når du starter med en standardforbud-holdning, behøver du kun at tænke på, hvad agenten virkelig har brug for. Alle andre anmodninger stoppes automatisk, uden at du behøver at forudsige hver enkelt mulig misbrug. Dette reducerer den mentale belastning på gennemgåeren og mindsker chancen for, at en glemt farlig fejl slipper igennem.

Overvej en agent, der skriver rapporter. Den skal læse en skabelonfil, trække data fra en database og sende den færdige PDF til en intern postkasse. Hvis du kun nævner disse tre anmodninger, bliver ethvert forsøg på at køre en shell-kommando, forespørge en ekstern API eller slette en tabel, nægtet med det samme. Du behøver aldrig at skrive en regel, der siger „bloker rm -rf“, „bloker curl til ond.dk“ eller „bloker SLET TABEL“. Standardforbudsreglen dækker dem alle.

I praksis har jeg set hold bruge uger på at opbygge lange blokeringslister, der alligevel ikke dækker en ny angrebsvektor, mens en kort tilladeliste på fem punkter stoppede de samme angreb allerede på første dag. Den sparede indsats på vedligeholdelse er reel: du gennemgår tilladelisten, når et værktøj ændres, ikke når en ny trussel opstår.

Hvordan opbygger jeg en tilladeliste til en ny agent

Jeg følger en gentagen liste med kontrollpunkter, der holder listen stram og gennemgåelig.

- Skriv ned de præcise opgaver, agenten skal udføre i dag. Ignorer ideer om "kunne være nyttigt senere".

- Til hver opgave, find det enkelte værktøj, der udfører jobbet med de smalleste mulige parametre. Hvis et værktøj tilbyder en flag, der udvider omfanget, skal du ikke aktivere det, medmindre opgaven eksplicit kræver det.

- Optegn værktøjets navn, den præcise kommando eller API-endpoint og de tilladte parameter-værdier i en simpel YAML-fil. Denne fil ligger ved siden af agentkoden, så anmeldere kan se den på et øjeblik.

- Kør agenten i en sandbox og verificér, at hver listede opkald lykkes, og at ethvert opkald, der ikke er i filen, returnerer en fejl.

- Bed en kollega om at gennemgå listen. Anmelderens job er at bekræfte, at hver post svarer til en reel opgave, og at der ikke er skjulte ekstra funktioner bag standardindstillingerne.

- Gem filen i versionskontrol. Tag hver commit med agentversionen, så du kan spore, hvilken tilladeliste der blev sendt med hvilken udgave.

- Konfigurer en CI-trin, der fejler bygningen, hvis YAML-filen mangler eller hvis den indeholder et værktøj, der ikke er godkendt i projektets værktøjsregister.

Denne proces tager mig omkring en time for en simpel agent og producerer et dokument, som enhver kan gennemgå.

Klassificering af værktøjer efter hvad de kan ændre

Ikke alle værktøjer medfører samme risiko. Jeg opdeler tilladte værktøjer i tre påvirkningsklasser, så jeg ved, hvor jeg skal tilføje ekstra kontroller.

Påvirkningsklasse | Hvad det betyder | Eksempelværktøj | Typisk sikkerhedsforanstaltning Kun læs | Kan hente data, men kan ikke ændre tilstand | Fil læs, database SELECT, offentlig API GET | Log kaldet, ingen ekstra godkendelse nødvendig Skriv eller muterbart | Kan oprette, opdatere eller slette data | Fil skriv, database INSERT/UPDATE/DELETE, intern besked offentliggørelse | Kræver en anden-godkender for første brug, log med bruger-ID Uomstødelig ekstern effekt | Kan påvirke systemer uden for tillidsgrænsen | Send e-mail, offentliggør på sociale medier, initier betaling, ring til ekstern webhook | Obligatorisk manuel godkendelse, detaljeret revisionsspor, tidsgrænse for kaldet

Når jeg gennemgår et nyt værktøj, spørger jeg: „Hvis dette kald køres, hvad er det værste, der kunne ske?“ Svaret fortæller mig, hvilken række i tabellen der gælder. For kun-læsværktøjer tilføjer jeg kun en loglinje. For skrivværktøjer tilføjer jeg en let godkendelsesworkflow. For uomstødelige effekter gennemtvinger jeg en manuel port og holder kaldvinduet kort.

Parering af tilladelselister med inddata- og uddatafiltre

En tilladelseliste fjerner unødvendig funktionalitet. Filtre fanger dårlige data, der slipper igennem de tilladte opkald. Jeg behandler dem som komplementære lag, ikke erstatninger.

På inddatasiden kører jeg en prompt-injektionschecker, der søger efter kendte jailbreak-mønstre. Jeg bruger OWASP LLM Prompt Injection Prevention Cheat Sheet (link) som reference for de regler, jeg aktiverer. Hvis checkeren markerer en prompt, afviser jeg den eller renser den forbrydende sektion, før agenten ser den.

På udgangssiden scannar jeg agentens genererede tekst for hemmeligheder, SQL-injektionsforsøg eller ikke-tilladte URL'er. Secrets Management Cheat Sheet (link) hjælper mig med at opbygge regex-mønstre for API-nøgler, adgangskoder og tokens. SQL Injection Prevention Cheat Sheet (link) vejleder de mønstre, jeg bruger til at fange farlige forespørgselssætninger, der måske bliver echoet tilbage i et svar.

Begge filtermængder kører som letvægts-middleware. De tilføjer få millisekunders forsinkelse, men stopper mange lav-anstrengelses-angreb, før de når værktøjslaget. Fordi tilladelselisten allerede har fjernet hele klasser af opkald, har filterne en mindre overflade at inspicere, hvilket holder falske positive værdier lavt.

Hvad dette ikke er

Jeg vil gerne gøre det klart, hvilke begrænsninger en tilladelsesliste har, så du ikke forventer, at den løser problemer, den aldrig var meant til at adresse.

- Det er ikke en garanti for, at agenten aldrig vil opføre sig dårligt. En fastbesluttet angriber, der finder en måde at kalde en tilladt værktøj med skadelige parametre, kan stadig forårsage skade. - Det er ikke en erstatning for sikker kodning. Hvis agentens egen kode indeholder en sårbarhed, kan tilladelseslisten ikke forhindre udnyttelse af denne svaghed. - Det er ikke en erstatning for ordentlig håndtering af hemmeligheder. Selv hvis agenten ikke kan kalde et værktøj til hemmelighedsudtrækning, hemmeligheder, der lækes i logfiler eller output, udgør stadig en risiko. - Det stopper ikke indirekte promptinjektion, der manipulerer agenten med at bruge et tilladt værktøj på en uventet måde. Du har stadig brug for inputvalidering og outputfiltrering. - Det er ikke en enkeltstående opgave. Når et værktøj tilføjes, ændres dets parametre, eller agentens formål skifter, skal du genbesøge listen. - Det er ikke en mirakelkur for overholdelse. Regler såsom EU AI Act kræver dokumentation, risikovurderinger og menneskelig overvågning, der går ud over en simpel tilladelsesliste.

Almindelige faldgruber, jeg har set, og hvordan jeg undgår dem

Selv med en klar proces kan teams af og til glide ind i vaner, der svækker tilladelisten. Herunder er mønstrene, jeg holder øje med, og de konkrete skridt, jeg tager for at holde listen ærlig.

- For brede parametre – Nogen tilføjer et værktøj med en flag som "--rekursiv" eller "--alle" fordi det synes praktisk. Jeg modvirker dette ved at spørge: "Hvad er det mindste sæt af muligheder, der tilfredsstiller opgaven?" Hvis svaret er en undermængde, låser jeg flaget til denne undermængde i YAML-filen. - Glemte værktøjopdateringer – En bibliotek opdaterer og tilføjer en ny kommando, der automatisk bliver eksponeret. Jeg mildner dette ved at låse den eksakte version af værktøjet i agentens afhængighedsfil og tilføje en CI-skridt, der fejler, hvis en ny version introducerer ukendte kommandoer. - Blanding af politik med prompt – En udvikler forsøger at påtvinge begrænsninger ved at tilføje instruktioner som "ring ikke slet" inde i prompten. Jeg minder holdet om, at prompt-niveau kontroller kan omgås gennem klog omskrivning; den virkelige vagt må sidde på værktøjsregistret eller eksekveringslaget. - Manglende logging – Tilladelisten blokerer et opkald, men ingen ved, det skete. Jeg sikrer, at hver blokeret forsøg skriver en struktureret logindgang med tidsstempel, agent-ID og det afviste værktøjsnavn. Denne log føder vores alarmsystem, så vi kan spotte afprøvning af...

Ved at behandle hver af disse punkter som en konkrete check i min arbejdsproces holder jeg tilladelisten stram og agentens skadesradius lille.

Referencer

- OWASP LLM Prompt Injection Forebyggelse Cheat Sheet - OWASP SQL Injection Forebyggelse Cheat Sheet - OWASP Hemmelighedskontrol Cheat Sheet - AgentGuard - Konfigurationsfiler Guide

Ofte stillede spørgsmål

Er en instruktion i en prompt nok til at begrænse værktøjer?

Nej. Begrænsninger på prompt-niveau kan omgås. Gennemfør tilladelseslisten på værktøjsregistret eller eksekveringslaget.

Hvad tæller som en uafvendelig ekstern effekt?

At sende email eller beskeder, overføre penge, slette optegnelser, offentliggøre indhold - alt det, du ikke kan gøre om.

Hvor mange værktøjer er for mange?

Der er ingen bestemt antal. Testen er, om du kan forklare, for hvert værktøj på listen, hvilken opgave kræver det og hvad det kan ødelægge.

Er filtre en erstatning for en tilladelsesliste?

Nej. Filtre fanger dårligt indhold, tilladelseslister fjerner unødvendig funktionalitet. Brug begge.

Dækker dette over indirekte prompt-injektion?

Det begrænser skaden, man kan gøre. At opdage og blokere injektionen selv er en separat inddata-sides kontrol.

Er gennemgangen en sikkerhedsrevision?

Nej. Det er beslutningsstøtte, der vurderer opkald og foreslår filtre. En fuld vurdering af installationen har stadig brug for en sikkerhedsrevision.

Referencer

- OWASP — Top 10 for store sprogmodelapplikationer - NIST — Ramme for AI-risikostyring

Prøv produktet: AgentGuard

2026-09-20 · kun primærkilder · ingen fabrikerede trafikmålinger · beslutningsstøtte kun

Relaterede artikler

er andre vigtige begreber.