Att bryta den dödliga trifectan: hur As ...

Att bryta den dödliga trifectan: hur Asana ser på säkerheten för agentbaserad AI

18 juli 2026

7 min. läsning

Agentisk AI introducerar en typ av säkerhetsrisk som branschen inte har löst. Så här ser vi på det på Asana, och de säkerhetsinvarianter vi har i alla våra AI-funktioner.

Problemet

Agentbaserade AI-system svarar inte bara på frågor. De läser dokument, vidtar åtgärder och samordnar mellan verktyg. Ju mer de kan göra, desto större är deras risk för attacker.

Till skillnad från konventionell kod har LLM:er en egenskap som gör detta grundläggande svårt: de kan inte på ett tillförlitligt sätt skilja instruktioner från data. Allt som matas in i en LLM hamnar i samma flöde, så noggrant utformade data kan ta kontroll över modellen på samma sätt som en legitim instruktion skulle göra. Det här är grundorsaken till promptinjektion, det som Simon Willison kallar ”arvsynd” för LLM-baserade applikationer.

Det är inte teoretiskt. Forskare har demonstrerat den här attackklassen mot Microsoft 365 Copilot, GitHubs MCP-server, Slack AI och många andra. Bruce Schneier uttryckte det rakt på sak: branschen har ännu inte ett robust försvar mot den här typen av angrepp.

Så hur bygger man agentisk AI på ett ansvarsfullt sätt när branschen inte har listat ut grunderna?

Den dödliga trifectan

Willison delar upp kärnrisken i tre kapaciteter som i kombination skapar förutsättningarna för skada:

Åtkomst till känsliga data. Agenten kan läsa konfidentiell eller privat information.
Exponering för opålitligt innehåll. Agenten bearbetar inmatning som kan innehålla dolda fientliga instruktioner.
Förmågan att kommunicera externt. Agenten kan skicka information utanför systemet.

En användbar precisering av det tredje benet: det handlar egentligen om möjligheten att skapa biverkningar, inte bara utgående kommunikation. Att exfiltrera data till en angripares server är det klassiska exemplet, men en skadlig instruktion som i tysthet ändrar titeln på varje projekt i en arbetsyta, eller skickar känsligt innehåll till fel intern kanal, är samma sorts problem. Vi använder ”extern kommunikation” som en förkortning, men den bredare versionen är vad vi faktiskt försvarar oss mot.

Varje enskilt ben i trifectan är hanterbart. Även två tillsammans är det oftast. Men när alla tre sammanfaller har du en livskraftig attackväg.

Den viktiga insikten: att bryta ett ben minskar den totala risken avsevärt. Vi behöver inte lösa promptinjektion perfekt. Ingen har gjort det. Vi måste se till att alla tre förutsättningarna inte enkelt kan samexistera.

Korny Sietsma bygger vidare på detta och kartlägger trifectan till begränsningar som sandboxing, uppdelnings av uppgifter, begränsad behörighet och human-in-the-loop. Det här är byggstenarna. Frågan är hur man kan operationalisera dem.

Sammanhang, kontrollpunkter och kontroller

Vi organiserar vårt tänkande kring tre pelare som direkt motsvarar den dödliga trifectan. Var och en begränsar ett ben.

Asana har flera AI-gränssnitt. AI-assistenter är agenter som deltar med eget medlemskap och egna behörigheter i arbetsytan. Andra AI-funktioner fungerar som användaren, där gränsen är vad den användaren redan har åtkomst till. Invarianterna nedan fokuserar på agentfunktionen, där ytan är som störst, och vi kommer att lyfta fram var implementeringen skiljer sig åt mellan olika ytor.

Sammanhang: Hantera vad AI kan se

Trifecta-del: Åtkomst till känsliga data

För att agentisk AI ska vara användbar behöver den sammanhang. Utmaningen är att ge den tillräckligt för att vara till hjälp utan att ge den en huvudnyckel.

Vår grundläggande invariant är principen om begränsad behörighet, där det exakta uttrycket beror på ytan. För AI-assistenter, som har sitt eget medlemskap separat från enskilda användare, är gränsen skärningspunkten mellan teamkollegans behörigheter och användarens. För AI-funktioner som fungerar som användaren är gränsen helt enkelt den användarens egen åtkomst. I varje fall styr samma auktoriseringslager på serversidan som styr alla andra interaktioner i Asana även AI:ns åtkomst. AI-funktioner får inte utökade behörigheter. De arbetar inom Asanas åtkomstkontrollsystem, inte runt det.

Att definiera sammanhanget innebär mer än att reglera intern dataåtkomst i Asana. Det omfattar även de externa integreringar som en agent kan interagera med. Även om integreringar för närvarande kräver uttrycklig auktorisering från användaren, utvecklar vi granulära, agentspecifika kontrollvägar. Detta gör det möjligt för organisationer att begränsa integreringsbehörigheter för AI-assistenter som hanterar högriskinmatningar. Vår grundläggande arkitektoniska princip är tydlig: gränsen för vad en AI kan se måste vara dynamisk och drivas av dataägare snarare än att vara en hårdkodad produktstandard.

Även om en angripare smugglar in skadliga instruktioner i AI:ns sammanhang begränsas det som AI faktiskt kan se av samma behörighetsmodell som allt annat.

Kontrollpunkter: filtrera vad AI lyssnar på

Trifecta-del: Exponering för innehåll som inte är betrott

Det här är den svåraste etappen. I en arbetshanteringsplattform är det mesta av det som AI läser användargenererat innehåll: uppgifter, kommentarer, bifogade dokument. En del av det kommer från utanför organisationen. Du kan inte vägra att läsa det.

Vi skapar istället kontrollpunkter: platser där vi skiljer på betrodd avsikt och godtyckligt innehåll, och där människor kan ingripa om något verkar fel.

Källmedveten instruktionshantering. AI-funktioner taggar innehåll efter författarens tillförlitlighet och efter källa, så att modellen kan prioritera instruktioner från auktoriserade användare framför instruktioner som påträffas i godtyckligt innehåll längs vägen. Detta minskar risken för attacker genom promptinjektion men eliminerar den inte helt. Modellen läser fortfarande allt i sitt sammanhang, och säkerhetsgarantin är partiell snarare än absolut. Vi diskuterar begränsningarna för den här metoden nedan.
Loggning och kriminalteknisk utredning. Varje modellanrop loggas med dess underlag, resultat, aktör, funktionskontext och nedströms-händelser, inklusive vilka arbetsgrafobjekt en automatisering berörde och vilka webbadresser som dök upp i resultatet. Vi varnar automatiskt om operativa signaler som felfrekvenser och kostnadstoppar. För säkerhetsrelevanta avvikelser stöder samma loggar efterföljande utredning av människor. Som Willison konstaterar skulle även mönsterbaserad detektering som fångar upp de flesta attacker vara otillräcklig i sig. Synlighet och möjligheten att undersöka är den hållbara grunden vi bygger på, inte muren.
Human-in-the-loop-design. AI-funktioner visar sitt arbete för mänsklig granskning i stället för att i tysthet vidta oåterkalleliga åtgärder.
Uppdelnings av uppgifter och begränsade åtgärder. Komplexa arbetsflöden är indelade i mindre steg, och de åtgärder som är tillgängliga för AI-funktioner är avsiktligt begränsade snarare än öppna.

Inget av dessa är skottsäkert var för sig. Tillsammans bildar de ett djupgående försvar.

Kontroller: Begränsa vad AI kan agera på

Tredje benet: Möjligheten att skapa biverkningar

Det är i det tredje benet som de flesta verkliga attackerna sker. Om en angripare övertygar en AI om att bädda in känsliga data i en URL, skicka dem via en integrering eller ändra en post som andra människor är beroende av, lyckas attacken.

Vi investerar i flera typer av kontroller här:

Behandla LLM-output som opålitligt. Genererat innehåll får ingen förtroendehöjning bara för att det kom från Asana AI. Det går igenom samma validerings- och renderingsvägar som allt annat användargenererat innehåll.
Obligatoriska mänskliga godkännanden för åtgärder med stor inverkan. Vissa åtgärdskategorier kräver alltid uttryckliga godkännanden från en människa, oavsett hur säker AI är eller hur rutinmässig begäran verkar vara. För AI-assistenter inkluderar detta åtgärder som höjer åtkomstnivån (ändring av behörigheter, tillägg av medlemmar) och åtgärder som förstör data (raderingar). AI kan föreslå dem, men den kan inte utföra dem på egen hand.
Skyddsåtgärder för länkhantering. Externa webbadresser i AI-genererat innehåll behandlas innan de når en användare. Nya webbadresser som inte fanns med i inmatningen granskas extra noggrant och visas i sin fullständiga, oskymda form snarare än som ommärkt ankaretext, så att AI inte kan användas som ett vapen för att maskera en exfiltreringsändpunkt som en vänlig "klicka här för sammanfattningen".
Ingen utgående HTTP för allmänna ändamål. AI-funktioner har ingen öppen primitiv för att ”göra en begäran till vilken URL som helst”. Externa integreringar går via begränsade kanaler med egen auktorisering.
Granskningskedja för åtgärder. Varje skrivning, ändring och utgående åtgärd som en AI-funktion utför loggas tillsammans med modellanropet som utlöste den, så att en utredare kan rekonstruera vad en AI gjorde, inte bara vad den blev ombedd att göra.

Målet är inte att göra extern kommunikation omöjlig. AI-funktioner måste referera till länkar, uppdatera uppgifter och producera användbara resultat. Målet är att se till att de inte kan göra det i smyg på ett sätt som användaren inte hade för avsikt.

Ett mönster för värden som genereras av AI

Inom denna ram dyker samma konkreta delproblem upp om och om igen: en AI-funktion producerar något (ett objekt-ID, en mottagare, en URL) och nedströms-kod agerar på det, ofta med bredare behörigheter än själva AI:n. Hallucinationer och promptinjektioner hamnar på samma ställe: ett värde som modellen genererar blir betrott.

Vi använder ett mönster i fyra delar som en checklista för designgranskning av dessa värden:

Begränsa vad AI får producera från början, innan valideringen måste köras.
Validera varje AI-producerat värde på serversidan mot samma auktoriseringslager som allt annat. Modellen behandlas som en opålitlig klient.
Motivera valet genom att behålla tillräckligt med strukturerat sammanhang för att förklara varför AI valde det den valde. Det är det som gör utredningar, utvärderingar och incidentrespons möjliga senare.
Eskalera med friktion, reservlösning eller mänsklig granskning när ett värde är högrisk eller ligger utanför den förväntade omfattningen.

Den röda tråden: modellbeteende bör inte vara den huvudsakliga säkerhetskontrollen. Bättre prompter och ”vi sa åt modellen att inte göra det” är användbara djupgående försvar, men de hållbara kontrollerna finns i systemet runt modellen.

Grundade på principer

De här valen är inte tillfälliga. De härrör från Asanas publicerade AI-principer.

Människor är ansvariga för beslut som driver den kontrollpunktsorienterade designen. AI hjälper till, men människor håller sig informerade och är ansvariga.

Vi är fast beslutna att prioritera säkerheten, vilket motiverar investeringen i kontroller i flera lager även när de skapar friktion. Alternativet ökar risken när AI-funktioner tar sig an mer komplext arbete.

Vi främjar öppenhet, och det är därför vi skriver det här inlägget. Vi har inte löst säkerheten för agentisk AI. Men att vara öppna om hur vi resonerar kring de här riskerna och de begränsningar vi genomför hjälper den bredare communityn att göra framsteg i en gemensam utmaning och inbjuder till den granskning som gör oss bättre.

De ärliga gränserna

Promptinjektion är fortfarande i grunden olöst, och indirekt promptinjektion (de fientliga instruktionerna kommer inbäddade i innehåll som AI hämtar under sitt arbete, snarare än innehåll som en användare ger den direkt) är den variant som branschen har drabbats hårdast av 2026. Källmedveten taggning hjälper men åtgärdar inte helt problemet, eftersom modellen fortfarande måste välja att respektera taggarna. Våra kontrollpunkter minskar risken avsevärt, men de eliminerar den inte. Så länge instruktioner och data delar ett kontextfönster kommer fientlig inmatning som hämtas genom sökning, öppna formulär eller integrering ibland att smita igenom. Vi behandlar detta som ett aktivt, pågående investeringsområde, med noggrannare granskning av alla vägar som gör att externt skapat innehåll kan nå en agentfunktion. Arbetet med designmönster för att säkra LLM-agenter pekar i lovande riktningar, men branschens konsensus håller fortfarande på att växa fram.

Hotlandskapet förändras snabbt. Nya vektorer dyker hela tiden upp, från osynlig bildbaserad promptinjektion till exfiltreringskedjor i flera steg. Vi utformar kontroller så att de är skiktade och kan kombineras, så att nya begränsningar kan läggas till när nya hot uppstår. Det är en kapprustning, inte ett problem som du löser en gång. OWASP:s tio största risker för LLM-applikationer är en användbar löpande referens.

Vi ser inte dessa luckor som anledningar till att sakta ner. Vi ser dem som anledningar till att vara medvetna. Den dödliga trifectan visar oss vad som står på spel. Sammanhang, kontrollpunkter och kontroller ger oss ett ramverk för handling. Och eftersom inget team löser detta på egen hand investerar vi aktivt tillsammans med våra forsknings- och kundpartner för att stärka dessa ytor i takt med att hotlandskapet utvecklas.