De dodelijke trifecta doorbreken: hoe Asana denkt over agentische AI-beveiliging
Agentic AI introduceert een klasse van beveiligingsrisico's die de sector niet heeft opgelost. Zo denken we er bij Asana over, en dit zijn de beveiligingsinvarianten die we hanteren voor al onze AI-functies.
Het probleem
Agentic AI-systemen beantwoorden niet alleen vragen. Ze lezen documenten, ondernemen actie en coördineren tussen tools. Hoe meer ze kunnen doen, hoe groter hun kwetsbaarheid voor aanvallen.
In tegenstelling tot conventionele code hebben LLM's een eigenschap die dit fundamenteel moeilijk maakt: ze kunnen instructies niet betrouwbaar onderscheiden van gegevens. Alles wat aan een LLM wordt gegeven, komt in dezelfde stroom terecht, dus een zorgvuldig samengesteld stuk gegevens kan het model op dezelfde manier kapen als een legitieme instructie. Dit is de oorzaak van prompt-injectie, wat Simon Willison "de erfzonde" van op LLM gebaseerde applicaties noemt.
Het is niet theoretisch. Onderzoekers hebben deze aanvalsklasse gedemonstreerd tegen Microsoft 365 Copilot, de MCP-server van GitHub, Slack AI en vele andere. Bruce Schneier zei het botweg: de sector heeft nog geen robuuste verdediging tegen dit type aanval.
Dus hoe bouw je op een verantwoorde manier agentische AI als de branche de basisprincipes nog niet heeft uitgevogeld?
De dodelijke trifecta
Willison vat het kernrisico samen in drie mogelijkheden die, in combinatie, de voorwaarden scheppen voor schade:
Toegang tot gevoelige gegevens. De agent kan vertrouwelijke of privé-informatie lezen.
Blootstelling aan niet-vertrouwde inhoud. De agent verwerkt invoer die verborgen vijandige instructies kan bevatten.
De mogelijkheid om extern te communiceren. De agent kan informatie buiten het systeem verzenden.
Een nuttige verfijning van het derde onderdeel: het is eigenlijk de mogelijkheid om neveneffecten te creëren, niet alleen uitgaande communicatie. Het exfiltreren van gegevens naar de server van een aanvaller is het klassieke voorbeeld, maar een kwaadaardige instructie die stilletjes de titel van elk project in een werkruimte wijzigt, of gevoelige inhoud naar het verkeerde interne kanaal stuurt, is hetzelfde soort probleem. We gebruiken 'externe communicatie' als afkorting, maar de bredere versie is waar we ons daadwerkelijk tegen verdedigen.
Elk onderdeel van de trifecta is beheersbaar. Zelfs twee samen zijn dat meestal. Maar wanneer alle drie samenkomen, heb je een levensvatbaar aanvalspad.
Het belangrijke inzicht: het doorbreken van één onderdeel vermindert het algehele risico aanzienlijk. We hoeven prompt-injectie niet perfect op te lossen. Dat is niemand gelukt. We moeten ervoor zorgen dat alle drie de voorwaarden niet gemakkelijk naast elkaar kunnen bestaan.
Korny Sietsma bouwt hierop voort en koppelt de trifecta aan risicobeperkende maatregelen zoals sandboxing, taakdecompositie, minimale bevoegdheden en human-in-the-loop. Dit zijn de bouwstenen. De vraag is hoe ze operationeel te maken.
Context, Controlepunten en Controles
We organiseren ons denken rond drie pijlers die rechtstreeks corresponderen met de dodelijke trifecta. Elk beperkt één been.
Asana heeft verschillende AI-oppervlakken. AI-teamgenoten zijn agentische deelnemers met hun eigen lidmaatschap en toestemmingen in de werkruimte. Andere AI-functies werken als de gebruiker, waarbij de grens is wat die gebruiker al kan openen. De onderstaande invarianten richten zich op het agentische geval, waar het oppervlak het grootst is, en we zullen aangeven waar de implementatie per oppervlak verschilt.
Context: Beheer wat AI kan zien
Trifecta-poot: toegang tot gevoelige gegevens
Om nuttig te zijn, heeft agentische AI context nodig. De uitdaging is om het genoeg te geven om nuttig te zijn zonder het een loper te geven.
Onze fundamentele invariant is het beginsel van het minste privilege, waarbij de exacte uitdrukking afhankelijk is van het oppervlak. Voor AI-teamgenoten, die hun eigen lidmaatschap hebben, los van een individuele gebruiker, is de grens het snijpunt van de toestemmingen van de teamgenoot en die van de gebruiker. Voor AI-functies die als de gebruiker werken, is de grens simpelweg de eigen toegang van die gebruiker. In elk geval regelt dezelfde autorisatielaag aan de serverzijde die elke andere interactie in Asana regelt, de toegang van de AI. AI-functies krijgen geen verhoogde toestemmingen. Ze werken binnen het toegangsbeheersysteem van Asana, niet eromheen.
Het definiëren van context omvat meer dan het reguleren van interne gegevenstoegang binnen Asana; het omvat evenzeer de externe integraties waarmee een agent kan communiceren. Hoewel integraties momenteel expliciete autorisatie van de gebruiker vereisen, ontwikkelen we fijnmazige, agentspecifieke controlepaden. Hierdoor kunnen organisaties integratierechten beperken voor AI-teamgenoten die omgaan met input met een hoog risico. Onze kernarchitectuurinvariant is duidelijk: de grens van wat een AI kan zien, moet dynamisch zijn en worden bepaald door de eigenaars van de gegevens, in plaats van een vastgelegde standaardinstelling van het product te zijn.
Zelfs als een aanvaller kwaadaardige instructies in de context van de AI smokkelt, wordt wat de AI daadwerkelijk kan zien begrensd door hetzelfde toestemmingsmodel als al het andere.
Controlepunten: Filteren waar AI naar luistert
Trifecta-onderdeel: Blootstelling aan niet-vertrouwde Inhoud
Dit is het moeilijkste deel. In een werkbeheerplatform is het meeste van wat AI leest door gebruikers gegenereerde inhoud: taken, opmerkingen, bijgevoegde documenten. Een deel komt van buiten de organisatie. Je kunt niet weigeren om het te lezen.
In plaats daarvan stellen we controlepunten in: plaatsen waar we vertrouwde intentie onderscheiden van willekeurige Inhoud, en waar mensen kunnen ingrijpen als er iets niet klopt.
Afhandeling van instructies op basis van de bron. AI-functies taggen Inhoud op vertrouwen in de auteur en op bron, zodat het model instructies van geautoriseerde gebruikers zwaarder kan laten wegen dan instructies die onderweg in willekeurige inhoud worden aangetroffen. Dit verkleint de kwetsbaarheid voor aanvallen door prompt-injectie, maar sluit deze niet; het model leest nog steeds alles in zijn context en de beveiligingsgarantie is gedeeltelijk in plaats van absoluut. Hieronder bespreken we de grenzen van deze aanpak.
Registratie en forensisch onderzoek. Elke modelaanroep wordt gelogd met de inputs, outputs, actor, functiecontext en downstream-gebeurtenissen, inclusief welke work-graph-objecten een automatisering heeft aangeraakt en welke URL's in de output verschenen. We waarschuwen automatisch bij operationele signalen zoals foutpercentages en kostentoenames. Voor beveiligingsrelevante afwijkingen ondersteunen diezelfde logboeken post-hoc-onderzoek door mensen. Zoals Willison opmerkt, zou zelfs op patronen gebaseerde detectie die de meeste aanvallen onderschept, op zichzelf een onvoldoende zijn; zichtbaarheid en de mogelijkheid om te onderzoeken zijn de duurzame basis waarop we bouwen, niet de muur.
Human-in-the-loop-ontwerp. AI-functies brengen hun werk naar voren voor menselijke beoordeling in plaats van stilletjes onomkeerbare acties te ondernemen.
Taakontleding en scoped acties. Complexe workflows worden opgesplitst in kleinere fasen en de acties die beschikbaar zijn voor AI-functies zijn opzettelijk beperkt in plaats van open.
Geen van deze is afzonderlijk onfeilbaar. Samen vormen ze een diepgaande verdediging.
Besturing: beperk waar AI op kan handelen
Derde pijler: De mogelijkheid om neveneffecten te creëren
De derde poot is waar de meeste aanvallen in de echte wereld plaatsvinden. Als een aanvaller een AI overtuigt om gevoelige gegevens in een URL in te sluiten, deze via een integratie te verzenden of een record te wijzigen waarop andere mensen vertrouwen, is de aanval succesvol.
We investeren hier in verschillende categorieën van controle:
Behandel LLM-output als niet-vertrouwd. Gegenereerde Inhoud krijgt geen vertrouwensbonus omdat deze afkomstig is van Asana AI. Deze doorloopt dezelfde validatie- en renderingspaden als alle andere door gebruikers gegenereerde Inhoud.
Verplichte menselijke goedkeuringen voor acties met een grote impact. Bepaalde actiecategorieën vereisen altijd expliciete menselijke goedkeuringen, ongeacht hoe zeker de AI is of hoe routinematig het verzoek eruitziet. Voor AI-teamgenoten omvat dit acties die de toegang verhogen (machtigingen wijzigen, leden toevoegen) en acties die gegevens vernietigen (verwijderingen). De AI kan deze voorstellen; deze kan ze niet zelf uitvoeren.
Beveiligingsmaatregelen voor het omgaan met links. Externe URL's in door AI gegenereerde Inhoud worden verwerkt voordat ze een gebruiker bereiken. Nieuwe URL's die niet in de invoer verschenen, worden extra onder de loep genomen en verschijnen in hun volledige, onverhulde vorm in plaats van als hernoemde ankertekst, zodat de AI niet kan worden gebruikt om een exfiltratie-eindpunt te vermommen als een vriendelijke "klik hier voor de samenvatting".
Geen uitgaande HTTP voor algemeen gebruik. AI-functies hebben geen open primitief "doe een verzoek naar een URL". Externe integraties gaan via scoped kanalen met hun eigen autorisatie.
Actie-auditspoor. Elke schrijf-, mutatie- en uitgaande actie die een AI-functie uitvoert, wordt geregistreerd naast de modelaanroep die ertoe heeft geleid, zodat een onderzoeker kan reconstrueren wat een AI heeft gedaan, niet alleen wat er van hem is gevraagd.
Het doel is niet om externe communicatie onmogelijk te maken. AI-functies moeten naar links verwijzen, taken bijwerken en nuttige output produceren. Het doel is om ervoor te zorgen dat ze dat niet stiekem kunnen doen op een manier die de gebruiker niet van plan was.
Een patroon voor door AI uitgezonden waarden
Binnen dit kader blijft hetzelfde concrete deelprobleem terugkomen: een AI-functie produceert iets (een object-ID, een ontvanger, een URL) en downstreamcode handelt ernaar, vaak met bredere machtigingen dan de AI zelf. Hallucinaties en prompt-injecties komen op dezelfde plaats terecht: een waarde die het model uitstoot, wordt vertrouwd.
We gebruiken een vierdelig patroon als een checklist voor ontwerpbeoordeling voor deze waarden:
Beperk in de eerste plaats wat de AI mag produceren, voordat de validatie moet worden uitgevoerd.
Valideer elke door AI geproduceerde waarde server-side tegen dezelfde autorisatielaag als al het andere. Het model wordt behandeld als een niet-vertrouwde client.
Rechtvaardig de keuze door voldoende gestructureerde context te behouden om uit te leggen waarom de AI koos voor wat deze koos. Dat maakt later onderzoek, evaluaties en incidentrespons mogelijk.
Escaleer met wrijving, fallback of menselijke beoordeling wanneer een waarde een hoog risico heeft of buiten de verwachte scope valt.
De rode draad: modelgedrag mag niet de primaire beveiligingscontrole zijn. Betere prompts en "we hebben het model gezegd dat het dat niet moest doen" zijn nuttige verdedigingsmechanismen, maar de duurzame controles bevinden zich in het systeem rond het model.
Gebaseerd op principes
Deze keuzes zijn niet ad hoc. Ze vloeien voort uit de gepubliceerde AI-principes van Asana.
Mensen zijn verantwoordelijk voor beslissingen en dat is de drijvende kracht achter het op controlepunten gerichte ontwerp. AI helpt, maar mensen blijven op de hoogte en zijn verantwoordelijk.
We zetten ons in voor veiligheid, wat de investering in gelaagde controles rechtvaardigt, zelfs als ze wrijving veroorzaken. Het alternatief verhoogt het risico naarmate AI-functies complexer werk op zich nemen.
We bevorderen transparantie, en daarom schrijven we dit bericht. We hebben de beveiliging van agentische AI nog niet opgelost. Maar open zijn over hoe we over deze risico's denken en over de risicobeperkende maatregelen die we nemen, helpt de bredere gemeenschap vooruitgang te boeken bij een gedeelde uitdaging en nodigt uit tot de kritische blik die ons beter maakt.
De eerlijke limieten
Prompt-injectie is nog steeds fundamenteel onopgelost, en indirecte prompt-injectie (de vijandige instructies komen ingebed in Inhoud die de AI tijdens zijn werk ophaalt, in plaats van Inhoud die een gebruiker hem rechtstreeks geeft) is de variant waar de industrie in 2026 het hardst door is getroffen. Bronbewuste tagging helpt, maar dicht deze kloof niet volledig, omdat het model er nog steeds voor moet kiezen om de tags te respecteren. Onze Controlepunten verminderen het risico aanzienlijk; ze elimineren het niet. Zolang instructies en gegevens een contextvenster delen, zal er soms kwaadwillende input door de mazen van het net glippen die is opgehaald via zoekopdrachten, openbare formulieren of integraties. We behandelen dit als een actief, doorlopend investeringsgebied, met nauwkeuriger onderzoek van elk pad dat extern geschreven Inhoud toelaat om een agentische functie te bereiken. Het werk aan ontwerppatronen voor het beveiligen van LLM-agents wijst in veelbelovende richtingen, maar de consensus in de sector is nog in opkomst.
Het dreigingslandschap verandert snel. Er blijven nieuwe vectoren verschijnen, van onzichtbare op afbeeldingen gebaseerde prompt-injectie tot exfiltratieketens in meerdere stappen. We ontwerpen besturingselementen in lagen en zo dat ze kunnen worden samengesteld, zodat nieuwe beperkende maatregelen kunnen worden toegevoegd wanneer er nieuwe bedreigingen ontstaan. Het is een wapenwedloop, geen probleem dat je één keer oplost. De OWASP Top 10 voor LLM-applicaties is een nuttige doorlopende referentie.
We zien deze hiaten niet als redenen om het rustiger aan te doen. We zien ze als redenen om weloverwogen te zijn. De dodelijke trifecta vertelt ons wat er op het spel staat. Context, Controlepunten en Controles geven ons een raamwerk voor actie. En omdat geen enkel team dit alleen oplost, investeren we actief samen met onze onderzoeks- en klantpartners om deze oppervlakken te versterken naarmate het bedreigingslandschap evolueert.
Referenties
Simon Willison, "The lethal trifecta for AI agents", juni 2025
Korny Sietsma, "Agentic AI and Security", Martin Fowler, oktober 2025
Bruce Schneier, "We Are Still Unable to Secure LLMs from Malicious Inputs", augustus 2025
