Wat is er gebeurd
PromptArmor publiceerde onderzoek waaruit blijkt dat ChatGPT for Google Sheets te manipuleren was via indirecte prompt injection in een spreadsheet. Volgens het rapport kon één geïmporteerd sheet de extensie ertoe brengen om door een aanvaller gecontroleerde Apps Script-code uit te voeren, workbookdata weg te sluizen, phishing-overlays te tonen en sheets aan te passen met de rechten die de extensie al had gekregen.
Dat is belangrijk omdat dit geen klassieke chatbotfout is. Dit is een agentisch integratieprobleem: een AI-tool die gekoppeld is aan een echte bedrijfsapplicatie, met echte rechten, die onbetrouwbare content leest en acties uitvoert in dezelfde omgeving waar vaak financiële modellen, budgetten en operationele data staan.
OpenAI zegt dat het de mogelijkheid voor het model om Apps Script-code te genereren voor deze toepassing heeft verwijderd en de sandboxing opnieuw bekijkt. Dat verlaagt het directe risico, maar het bredere patroon blijft relevant voor elke organisatie die AI-assistenten koppelt aan documenten, spreadsheets, mailboxen en workflowsystemen.
Waarom dit ertoe doet
De les is niet alleen dat één spreadsheetextensie kwetsbaar was. De les is dat enterprise AI risicovol wordt wanneer lezen en handelen in hetzelfde vertrouwde pad terechtkomen. Een model dat externe content, interne data en uitvoerende tools tegelijk ziet, heeft runtime-controles nodig rond scope, approvals, logging en isolatie.
Menselijke goedkeuring is bovendien geen volledige controle op zichzelf. PromptArmor schrijft dat de aanval ook kon slagen wanneer automatische bewerkingen waren uitgeschakeld, omdat de gevaarlijke actie via scriptuitvoering liep en niet via een normale sheetbewerking. In productie moeten approvals gekoppeld zijn aan specifieke capabilities en observeerbare acties, niet alleen aan een algemene edit-instelling.
Voor documentzware organisaties is dit extra relevant. Spreadsheets, SharePoint-mappen, e-mailbijlagen en klantdocumenten zitten vol semi-vertrouwde content. Als een agent die content kan lezen en daarna API’s kan aanroepen, scripts kan schrijven of workflows kan starten, moet de runtime ervan uitgaan dat sommige input vijandig of verkeerd gevormd is.
Laava-perspectief
Dit is precies waarom Laava agents behandelt als productiesystemen, niet als slimme sidebars. Het model is maar één onderdeel van de architectuur. Het echte werk zit in de runtime eromheen: rechten, tool policies, audit trails, keuzes rond data residency, herstelpaden en integratieontwerp.
Een sovereign of managed runtime draait niet om het verkopen van een box. Het gaat om één gecontroleerde AI-omgeving voor document- en workflowoperaties. Die omgeving bepaalt welke tools een agent mag gebruiken, welke documenten hij mag lezen, welke acties expliciete review nodig hebben, waar logs worden opgeslagen en hoe incidenten achteraf te reconstrueren zijn.
Ook model-agnostisch ontwerpen is hier belangrijk. Als er risico ontstaat in één model, connector of vendoromgeving, moet een volwassen runtime daaromheen kunnen routeren, beperken of vervangen zonder het hele bedrijfsproces opnieuw te ontwerpen. Het doel is niet om AI-integraties te vermijden, maar om ze operationeel en auditable genoeg te maken voor echt werk.
Wat je kunt doen
Begin met inventariseren waar AI-tools al toegang hebben tot spreadsheets, documentopslag, e-mail en workflowsystemen. Let vooral op extensies en connectors die scripts kunnen uitvoeren, bestanden kunnen aanpassen, API’s kunnen aanroepen of nieuwe deeloppervlakken kunnen creëren. Dat zijn operationele capabilities, geen onschuldige chatfuncties.
Scheid daarna lezen van handelen. Gebruik least-privilege connectors, beperk risicovol toolgebruik, log agentbeslissingen en test met onbetrouwbare documenten voordat je naar productie gaat. Voor organisaties die agents bouwen bovenop SharePoint, Google Workspace, ERP- of CRM-data is de veiligste route een managed runtime met duidelijke integratiegrenzen vanaf dag één.