Sådan indbyggede vi sikkerhed i tilpassede agenter

En afgørende del af lanceringen af vores Tilpassede agenter var at sikre, at denne nye type AI-arbejdsgang var så sikker som muligt for vores kunder.

De fleste AI-agenter er i dag udviklet til en enkelt bruger med et relativt simpelt sæt tilladelser, der er tilpasset netop denne bruger. Agenter i et samarbejdsmiljø kræver en anden tilgang. Det er farligt at give dem tilladelse til at gøre alt, og det er sjældent nyttigt at have tilladelse til ingenting.

Med vores tilpassede agenter har vi gjort os umage for at finde den rette balance mellem de to: Sørge for, at der er tilstrækkelig adgang i samarbejdsmiljøer til, at agenten kan være hjælpsom på den rette måde (f.eks. tildeling af en opgave), men indføre som standard strenge begrænsninger, der sikrer, at agenten ikke kan udføre farlige handlinger (f.eks. slette alt indhold). Gennem årene har vi udviklet avancerede kontrolfunktioner til tilladelser og styring, som vores kunder kan bruge til at administrere deres arbejdsområder, og vi har udnyttet netop disse strukturer til at give vores brugere detaljeret kontrol over deres agenter, så de kan arbejde så sikkert som muligt i deres arbejdsområder.

Tilpassede agenter anvender en sikkerhedsmodel, hvor agenterne starter uden adgang til de fleste ressourcer, hvilket betyder, at de ikke har tilladelse til at læse, skrive eller interagere med noget som helst.

Denne tilgang står i bevidst kontrast til mange personlige AI-assistenter, som ofte starter med bred adgang og kræver, at brugerne sørger for, at sikkerhedsinstruktionerne ikke bliver udeladt. Vi ønsker ikke at overlade sikkerheden til modellens beslutningstagning. I stedet ønskede vi, at sikkerheden skulle være indbygget i adgangskontrollen og det deterministiske lag.

På den måde har vi kunnet give brugerne detaljeret kontrol, så de kan træffe de rigtige sikkerhedsbeslutninger til deres specifikke anvendelsessituationer, samtidig med at vi giver avancerede brugere mulighed for at udvikle utroligt avancerede autonome agenter.

At have begrænsede tilladelser som standard er en god idé, men det er vigtigt, at brugerne nemt kan opbygge og forstå de tilladelser, de har brug for til deres anvendelse.

Her er et par af de mest nævneværdige:

• Detaljerede tilladelser på sideniveau: Brugere kan tildele adgang til visning eller redigering af bestemte sider, ikke blot generel adgang til arbejdsområdet

• Direkte integration med Slack: Ved at tilbyde en direkte integration til Slack kan vi levere detaljerede tilladelser, der er nemme at konfigurere, på en måde, som MCP ikke kan

• E-mail: Du kan vælge, om du vil bekræfte, før du sender e-mails

• MCP-integrationer: Når du bruger en MCP-integration, er den ikke ressourcebaseret, men du kan angive, hvilke værktøjer der skal have tilgængelighed, og om der skal bedes om tilladelse eller du altid vil tillade bestemte typer af handlinger

Vi skulle også tage højde for uventede hændelser under kørsel, når agenten rent faktisk udfører sine opgaver. Her har vi anvendt en sikkerhedsstrategi på flere lag, hvilket vil sige tilladelse samt foranstaltninger mod indsættelse af kommandoer under kørsel.

Beskyttelse mod prompt injection: Prompt injection er en af de største og mest kendte udfordringer for AI-agenter. Selvom det stadig er et uløst problem, udvikler vi ikke vores system ud fra den antagelse, at alle prompt injections bliver opdaget (selvom vi fanger mange af dem). I stedet har vi udformet systemet således, at vi har indført flere lag af sikkerhedskontrol for at blokere følgerne af prompt injection, samtidig med at vi lægger særlig vægt på at tagge og overvåge eksterne data for at identificere potentielle angreb. Hvis noget ser mistænkeligt ud i en hændelse, eller hvis agenten udfører handlinger, der tyder på et potentielt angreb, kan vi standse agenten og bede brugeren om bekræftelse.

Advarselssystem: Når agenten er ved at gøre noget, der kan være risikabelt, holder den en pause og spørger først brugeren. Hvordan dette foregår, afhænger af, om brugeren er i gang med at konfigurere eller køre agenten. Når vi konfigurerer en agent, der kan udføre risikable handlinger, viser vi brugerne en række pop op-vinduer, der kan variere fra en simpel bekræftelse til krav om godkendelse fra arbejdsområdets administrator. Når agenten udfører en risikabel handling under kørsel, tvinger vi den til at få handlingen godkendt af ejeren af den tilpassede agent. Dette arbejde afspejler vores flerstrengede tilgang til tilladelser og sikkerhed på tværs af hele vores platform.

Udbedring (dvs. en sletteknap): Hvis en agent begår en fejl, f.eks. ved at sende en ukorrekt besked på Slack, kan agentens ejer slette den pågældende besked. Det lyder simpelt, men det er vigtigt at give brugerne mulighed for at rette op på eventuelle fejl, hvis de opstår, og ikke blot forhindre dem.

For at nå til denne model kørte vi et omfattende alfatestprogram, både internt i Notion og eksternt med kunderne. Vi ønskede specifikt at gennemføre en stresstest for at se, hvordan sikkerheden fungerede i praksis, når omfanget blev større. Ved afslutningen af vores alfatestperiode havde Notion mere end 3.000 interne tilpassede agenter, og vores alfakunder havde oprettet mere end 25.000.

Vi lærte hurtigt nogle ting. For eksempel opfordrede de tidlige interne versioner af tilpassede agenter brugerne til at give for mange tilladelse uden at forstå de mulige konsekvenser. Brugerne endte med at give agenterne omfattende skriveadgang til Slack, og ved flere lejligheder skrev disse agenter endda indlæg i #general (agenten ved, at alle Slack-arbejdsområder har en #general-kanal!), hele virksomhedens kanal med hundredvis af medlemmer. Det var helt klart ikke brugernes hensigt! Det var netop dette, der fik os til at indføre en ny, tilpasset tilladelse til Slack kaldet »Læs og svar«, som giver agenten mulighed for at svare direkte i de tråde, de specifikt blev udløst i. Vi ser det som vores opgave at indføre tilladelser som denne, der giver brugerne mulighed for at udføre deres arbejde på en sikker måde, i stedet for at tvinge dem til at »tillade alt«.

Dette førte også til, at vi bevidst valgte at udvikle nogle af vores egne integrationer i stedet for udelukkende at stole på MCP'er. Som allerede nævnt er de fleste MCP'er i dag primært udviklet til brug i scenarier med én bruger, og de understøtter derfor som regel ikke ressourcebaserede tilladelser eller udløsere som standard. Ved at udvikle egne integrationer fik vi mulighed for at håndhæve vores model for tilladelse uden at påføre vores kunder ekstra arbejde.

En ting, vi er særligt stolte af: Gennem denne proces er vores eget sikkerhedsteam blevet en af de mest aktive interne brugere af tilpassede agenter. De har for eksempel udviklet en agent ved navn Scruff til at sortere og uddybe sikkerhedsadvarsler, og de bruger agenter til automatisering af app-sikkerhed, generering af koderettelser og kørsel af adversariale tests. Det har været et rigtigt godt samarbejde mellem vores AI-team og vores sikkerhedsteam.

Lanceringen var kun begyndelsen, og vi investerer massivt i bedre sikkerhedsforanstaltninger i takt med, at vores produkter og hele branchen udvikler sig. Betafasen for vores tilpassede agenter i de kommende måneder vil også hjælpe os med fortsat at forbedre os i samarbejde med vores kunder.

I de kommende uger og måneder forventer vi at tage fat på at:

• Genindføre bredere tilladelsesområder, der kræver godkendelse fra arbejdsområdeadministratoren til avancerede anvendelsesscenarier

• Udvide de detaljerede tilladelsesfunktioner til eksterne integrationer, der er bygget på Workers-platformen

• Overveje yderligere tilladelsesmodeller til forskellige anvendelsessituationer, når der er indført flere sikkerhedsforanstaltninger

Vi er stadig i de indledende faser af udviklingen af denne teknologi, og vi hører gerne fra brugerne om, hvordan vi kan forbedre den.