Slik bygde vi sikkerhet inn i skreddersydde agenter

En kritisk komponent i lanseringen av våre skreddersydde agenter var å sikre at denne nye typen KI-arbeidsflyt var så sikker som mulig for våre kunder.

De fleste KI-agenter i dag er bygget for en enkelt bruker med et relativt enkelt sett av tilgangsrettigheter spesifikt for den brukeren. Imidlertid har agenter i et samarbeidende miljø forskjellige behov. Det å gi dem tillatelse til å gjøre alt er farlig, og å ha tillatelse til å gjøre ingenting er sjeldent nyttig.

Med våre skreddersydde agenter har vi vært nøye med å prøve å balansere begge deler: Ha nok tilgang i samarbeidende miljøer til å være akkurat passe hjelpsom (f.eks. tildele en oppgave), men som standard, bruke strenge begrensninger som sikrer at agenten ikke kan ta farlige valg (f.eks. slette alt innhold). I løpet av årene har vi bygget sofistikerte tilgangs- og styringskontroller for våre kunder til å administrere arbeidsområder, og vi har utnyttet de samme strukturene for å gi våre brukere detaljerte kontroller over sine agenter, slik at de kan være så sikre som mulig i sine arbeidsområder.

Skreddersydde agenter bruker en sikkerhetsmodell som bygger fra bunnen av, der agenter starter uten tilgang til de fleste ressurser, noe som betyr ingen tillatelser til å lese, skrive eller samhandle med noe.

Denne tilnærmingen er en bevisst kontrast til mange personlige KI-hjelpere, som ofte starter med bred tilgang og krever at brukerne sørger for at sikkerhetsinstruksjoner ikke forsvinner. Vi vil ikke overlate sikkerhet til modellens beslutningstaking. I stedet ønsket vi at sikkerhet skulle være innebygd i tilgangskontrollen og det deterministiske laget.

På denne måten har vi vært i stand til å gi brukerne detaljerte kontroller for å ta de riktige sikkerhetsbeslutningene for sine bruksområder, samtidig som vi gir avanserte brukere muligheten til å bygge utrolig dyktige autonome agenter.

Det å gi minst tilgang som standard er bra, men det er viktig at brukerne enkelt kan bygge opp og forstå tilgangene de trenger for applikasjonen.

Her er noen som er bemerkelsesverdige:

• Detaljert tilgang på side-nivå: Brukere kan gi visnings- eller redigeringstilgang til spesifikke sider, ikke bare bred tilgang til arbeidsområdet.

• Førsteparts Slack-integrasjon: Det å tilby en førsteparts integrasjon for Slack lar oss bringe lett-konfigurerbare detaljerte tilganger på en måte som MCP ikke gjør

• E-post: Du kan velge om du vil bekrefte før du sender e-poster

• MCP-integrasjoner: Når du bruker en MCP-integrasjon, er det ikke ressursbasert, men du kan spesifisere verktøyene du ønsker å gjøre tilgjengelige, og om du vil spørre eller alltid tillate visse typer handlinger

Vi måtte også tenke på uventede atferd under kjøring når agenten faktisk utfører arbeid. Her valgte vi en flerlags sikkerhetsmetode, som betyr tilgangskontroller pluss redusering av kjøretid for injeksjon av hjelpetekst.

Beskyttelse mot injeksjon av hjelpetekst: Injeksjon av hjelpetekst er en av de største og mest kjente utfordringene for KI-agenter. Selv om det fortsatt er et uløst problem, utvikler vi ikke systemet vårt med antagelsen om at alle injeksjoner av hjelpetekst vil bli fanget opp (selv om vi fanger opp mange av dem). I stedet utviklet vi det slik at vi har lagdelte kontroller for å blokkere virkningen av injeksjon av hjelpetekst, samtidig som vi gir spesiell oppmerksomhet til tagging og overvåking av ekstern data for å identifisere potensielle angrep. I tilfelle noe ser mistenkelig ut eller agenten utfører handlinger som indikerer et potensielt angrep, kan vi stoppe agenten og be en bruker om bekreftelse.

Advarselssystem: Når agenten er i ferd med å gjøre noe potensielt risikabelt, pauser den og spør brukeren først. Hvordan dette skjer avhenger av om brukeren konfigurerer eller kjører agenten. Når vi konfigurerer en agent som kan gjøre noe risikabelt, gir vi brukerne et sett med pop-ups som kan variere fra en enkel bekreftelse til å måtte få godkjenning fra administratorene av arbeidsområdet. Når agenten gjør noe risikabelt under kjøring, tvinger vi den til å bekrefte den handlingen med en eier av den skreddersydde agenten. Dette arbeidet gjenspeiler vår flerfoldige tilnærming til tilganger og sikkerhet generelt på plattformen vår.

Reparasjon (dvs. en sletteknapp): Hvis en agent gjør en feil, som å legge ut noe feil på Slack, kan agentens eier slette den meldingen. Dette høres enkelt ut, men det er viktig å gi brukerne en måte å angre skader på hvis det skjer, ikke bare forhindre det.

For å komme frem til denne modellen kjørte vi et omfattende alpha-testprogram, både internt i Notion og eksternt med kunder. Vi ønsket spesifikt å teste hvordan sikkerhet fungerte i praksis ved økende skala. Ved slutten av alpha-testperioden, hadde Notion mer enn 3000 interne skreddersydde agenter, og alpha-kundene hadde opprettet mer enn 25 000.

Vi lærte noen leksjoner veldig raskt. For eksempel oppfordret tidlige interne versjoner av skreddersydde agenter brukerne til å være for tillatende uten å forstå de potensielle konsekvensene. Brukerne endte opp med å gi agenter bred skriveadgang til Slack, og ved flere anledninger la disse agentene ut innlegg på #general (agenten vet at hvert Slack-arbeidsområde har #general!), den bedriftsomfattende kanalen som har hundrevis av medlemmer. Dette var tydeligvis ikke brukernes hensikt! Det var det som førte oss til å introdusere en ny skreddersydd «lese og svare»-tilgang for Slack som lar agenter svare på tråder de ble utløst i eksplisitt. Vi ser det som vår oppgave å introdusere tilgang som dette som lar brukerne trygt få jobben gjort, i stedet for å tvinge brukerne til å «tillate alt».

Dette førte oss også til den bevisste beslutningen om å bygge noen førsteparts integrasjoner i stedet for å stole utelukkende på MCP-er. Som allerede diskutert, fordi de fleste MCP-er i dag er designet mer for enkeltspiller-modeller, håndterer de generelt ikke ressursbaserte tilganger eller utløsere. Det å bygge førsteparts integrasjoner ga oss kontrollen til å håndheve modellen for tilgang uten ekstra arbeid for kundene våre.

En ting er vi spesielt stolte av: gjennom denne prosessen har vårt eget sikkerhetsteam blitt en av de mest aktive interne brukerne av skreddersydde agenter. For eksempel bygde de en agent kalt Scruff for å fordele og berike sikkerhetsvarsler, og de bruker agenter for AppSec-automasjon, generering av kodefikser og kjøring av motstandertester. Det har vært et ekte samarbeid mellom KI-produktteamet og sikkerhetsteamet.

Lanseringen var bare begynnelsen, og vi investerer mye i bedre sikkerhets- og beskyttelsestiltak ettersom produktene våre og hele feltet går fremover. Vår beta-periode for Skreddersydde agenter de neste par månedene vil også hjelpe oss med å fortsette å forbedre oss sammen med kundene våre.

I de kommende ukene og månedene forventer vi å få gjort følgende:

• Gjeninnføre bredere tilgangsområder som krever godkjenning fra administratoren av arbeidsområdet for avanserte bruksområder.

• Utvide detaljerte tilgangsmuligheter til eksterne integrasjoner bygget på Workers-plattformen.

• Vurdere ytterligere tilgangsmoduser for forskjellige bruksområder når flere sikkerhetstiltak er på plass.

Vi er fortsatt i de tidlige fasene av å utvikle denne teknologien, og vi ønsker tilbakemelding fra fellesskapet om hvordan vi kan forbedre oss.