Så byggde vi in säkerhet i skräddarsydda agenter

En avgörande del av lanseringen av skräddarsydda agenter var att se till att denna nya typ av AI-arbetsflöde var så säker som möjligt för våra kunder.

De flesta AI-agenter idag är utformade för en enskild användare med en relativt enkel uppsättning behörigheter som är kopplade till just den användaren. Agenter i en miljö med samarbete behöver dock fungera på andra sätt. Att ge dem behörighet att göra vad som helst är farligt, och när de inte har behörighet att göra någonting är de sällan till någon nytta.

När det gäller våra skräddarsydda agenter har vi varit noggranna med att försöka hitta en balans mellan båda dessa aspekter. De ska ha tillräcklig åtkomst i miljöer för samarbete för att kunna vara precis så hjälpsamma som krävs (t.ex. genom att tilldela en uppgift), men det ska som standard finnas strikta begränsningar som säkerställer att agenten inte kan utföra farliga åtgärder (t.ex. radera allt innehåll). Under årens lopp har vi utvecklat avancerade behörighets- och styrningsfunktioner som hjälper våra kunder att hantera sina arbetsytor. Vi har även utnyttjat samma strukturer för att ge våra användare detaljerad kontroll över sina agenter, så att de kan arbeta så säkert som möjligt i arbetsytorna.

Skräddarsydda agenter använder en säkerhetsmodell där man börjar från noll, vilket innebär att agenterna inledningsvis saknar åtkomst till de flesta resurser – de har alltså inga behörigheter att läsa, skriva eller interagera med någonting.

Denna strategi står i medveten kontrast till många personliga AI-hjälpmedel, som ofta börjar med omfattande åtkomst och kräver att användarna ser till att säkerhetsinstruktionerna inte hamnar i skymundan. Vi vill inte överlåta säkerheten till modellens beslutsfattande. Istället ville vi att säkerheten skulle vara inbyggd i åtkomstkontrollen och det deterministiska lagret.

På så sätt har vi kunnat ge användarna detaljerade inställningsmöjligheter så att de kan fatta rätt säkerhetsbeslut för sina specifika användningsfall, samtidigt som avancerade användare kan utnyttja möjligheten att skapa otroligt kapabla autonoma agenter.

Att ha de minst tillåtande behörigheterna som standard är utmärkt, men det är viktigt att användarna enkelt kan bygga upp och förstå vilka behörigheter de behöver för en app eller ett program.

Här är några som är värda att nämna:

• Behörigheter på sidnivå: Användarna kan bevilja åtkomst att visa eller redigera specifika sidor, inte bara allmän åtkomst till arbetsytan.

• Direktintegration med Slack: Genom att erbjuda en direktintegration med Slack kan vi tillhandahålla detaljerade behörigheter som är lätta att konfigurera, vilket inte är möjligt med MCP.

• E-post: Du kan välja om du vill bekräfta innan e-postmeddelanden skickas.

• MCP-integrationer: När du använder en MCP-integration är den inte resursbaserad, men du kan ange vilka verktyg som ska vara tillgängliga och om du vill begära tillstånd eller alltid tillåta vissa typer av åtgärder.

Vi var också tvungna att tänka på oförutsedda beteenden under körning, när agenten faktiskt utför sitt arbete. Här har vi använt en säkerhetsstrategi med flera lager, vilket innebär behörighetskontroller i kombination med åtgärder mot promptinjektioner under körning.

Skydd mot promptinjektioner: Promptinjektioner är en av de största och mest välkända utmaningarna för AI-agenter. Även om detta fortfarande är ett olöst problem utformar vi inte vårt system utifrån antagandet att alla promptinjektioner kommer att upptäckas (även om vi upptäcker många av dem). Istället har vi utformat systemet så att det innehåller flera lager av säkerhetskontroller som blockerar effekterna av promptinjektioner, samtidigt som vi lägger särskild vikt vid märkning och övervakning av externa data för att upptäcka potentiella attacker. Om något verkar misstänkt eller om agenten utför åtgärder som tyder på en potentiell attack kan vi stoppa agenten och be användaren om bekräftelse.

Varningssystem: När agenten är på väg att göra något som kan innebära en risk pausar den och frågar användaren först. Hur detta går till beror på om användaren konfigurerar eller kör agenten. När vi konfigurerar en agent som kan utföra riskfyllda åtgärder visar vi användarna en rad popup-fönster, som kan handla om allt från en enkel bekräftelse till att godkännande måste erhållas från administratören för arbetsytan. När agenten utför en riskfylld åtgärd under körning tvingar vi den att bekräfta åtgärden med en ägare för den skräddarsydda agenten. Detta arbete återspeglar vårt mångfacetterade tillvägagångssätt när det gäller behörigheter och säkerhet på hela vår plattform.

Korrigering (dvs. en knapp för att radera): Om en agent råkar göra ett misstag, till exempel genom att publicera ett felaktigt meddelande i Slack, kan agentens ägare radera det meddelandet. Det låter enkelt, men det är viktigt att ge användarna möjlighet att åtgärda eventuella skador, inte bara förhindra dem.

För att ta fram den här modellen körde vi ett omfattande alfatestprogram, både internt inom Notion och externt tillsammans med kunder. Vi ville särskilt utsätta säkerhetssystemet för ett stresstest för att se hur det fungerade i praktiken när belastningen ökade. Vid slutet av vår alfatestperiod hade Notion mer än 3 000 skräddarsydda agenter, och våra alfakunder hade skapat mer än 25 000.

Vi lärde oss några saker väldigt snabbt. Till exempel uppmuntrades användarna i tidiga interna versioner av skräddarsydda agenter att vara alltför tillåtande utan att de förstod de potentiella konsekvenserna. Användarna gav agenterna omfattande åtkomst till Slack, och vid flera tillfällen publicerade dessa agenter till och med meddelanden i #general (agenten vet ju att varje Slack-arbetsyta har en #general-kanal), den företagsomfattande kanalen med hundratals deltagare. Det var helt klart inte användarnas avsikt. Det var detta som fick oss att införa en ny anpassad behörighet för ”läs och svara” i Slack, som gör det möjligt för agenter att svara direkt i de trådar där de uttryckligen har blivit utlösta. Vi ser det som vår uppgift att införa behörigheter som dessa, som gör det möjligt för användarna att utföra sitt arbete på ett säkert sätt, istället för att tvinga dem att ”tillåta allt”.

Detta ledde också till att vi medvetet valde att utveckla egna integrationer istället för att enbart förlita oss på MCP:er. Som redan nämnts är de flesta MCP:er idag främst utformade för användningsfall med en användare, vilket innebär att de i regel inte har inbyggt stöd för resursbaserade behörigheter eller utlösare. Genom att bygga egna integrationer fick vi möjlighet att tillämpa vår behörighetsmodell utan att det medförde extra arbete för våra kunder.

En sak som vi är särskilt stolta över är att genom denna process har vårt eget säkerhetsteam blivit en av de mest aktiva interna användarna av skräddarsydda agenter. De har till exempel utvecklat en agent vid namn Scruff som ska prioritera och komplettera säkerhetsvarningar, och de använder agenter för automatisering av applikationssäkerhet, generering av kodkorrigeringar och körning av motstridiga tester. Det har varit ett verkligt samarbete mellan vårt AI-team och vårt säkerhetsteam.

Lanseringen var bara början, och vi satsar stort på förbättrade säkerhets- och skyddsåtgärder i takt med att våra produkter och hela branschen utvecklas. Betaperioden för våra skräddarsydda agenter under de kommande månaderna kommer också att hjälpa oss att fortsätta utvecklas tillsammans med våra kunder.

Under de kommande veckorna och månaderna räknar vi med att ta itu med följande:

• återinföra bredare behörighetsområden som kräver godkännande av administratören för arbetsytan för avancerade användningsfall

• utöka möjligheterna till detaljerade behörigheter till externa integrationer som bygger på Workers-plattformen

• överväga ytterligare behörighetslägen för olika användningsfall när fler säkerhetsåtgärder har införts

Vi befinner oss fortfarande i den inledande fasen av utvecklingen av denna teknik, och vi tar gärna emot feedback från gemenskapen om hur vi kan förbättra den.