Wat er is gebeurd
The Verge meldt dat Vercel, het cloudplatform voor het deployen en hosten van webapplicaties, te maken heeft gehad met een security-incident en dat gestolen data online te koop wordt aangeboden. Volgens het bedrijf was de impact beperkt tot een deel van de klanten, maar het incident was wel serieus genoeg voor een publiek bulletin en een oproep aan beheerders om hun omgeving direct te controleren.
Wat deze zaak opvallend maakt, is het initiële toegangspad. Volgens Vercel begon het incident bij een gecompromitteerde third-party AI-tool waarvan de Google Workspace OAuth-app onderdeel was van een bredere aanval die meerdere organisaties raakte. Het punt is dus niet dat een model zelf ontspoorde. Het punt is dat een AI-tool met voldoende vertrouwen en voldoende bereik binnen de werkomgeving een volwaardig aanvalspad werd.
Vercel adviseerde klanten om activity logs te controleren en environment variables uit voorzorg te roteren. Dat is logisch, want zodra een platform dat dicht op deploymentworkflows zit wordt geraakt, worden secrets, tokens en operationele metadata meteen onderdeel van het risico. Juist daar moeten zakelijke beslissers op letten. Productierisico rond AI komt zelden binnen als sciencefiction. Het komt binnen via OAuth-scopes, adminpanelen, gedeelde workspaces en tools die onschuldig leken toen ze werden geïnstalleerd.
Waarom dit ertoe doet
Dit is relevant omdat enterprise AI snel een integratievraagstuk wordt, niet alleen een modelvraagstuk. Teams koppelen copilots en AI-assistenten aan mail, documenten, ticketsystemen, cloudconsoles, broncode en interne kennisbanken zodat ze echt werk kunnen doen. Maar elke nuttige koppeling is ook een vertrouwensbeslissing. Hoe meer bevoegdheid zo'n tool krijgt, hoe sneller een incident bij een leverancier verandert in een incident binnen je eigen operatie.
Het Vercel-verhaal herinnert eraan dat de blast radius van een AI-tool veel minder wordt bepaald door de marketingtekst dan door de permissies. Een ogenschijnlijk lichte assistent die gebruikersdirectories kan lezen, activiteit kan inspecteren of deploymentcontext kan benaderen, zit vaak veel dichter op de kroonjuwelen dan teams doorhebben. Dat is extra riskant bij OAuth-tools, omdat toegang vaak stilletjes opstapelt. Eén goedgekeurde app kan eindigen met brede leestoegang, persistente tokens en een geprivilegieerd pad naar systemen die nooit zijn ontworpen voor AI-sprawl.
Het is ook relevant omdat veel AI-roll-outs nog steeds worden beoordeeld op adoptiesnelheid in plaats van op kwaliteit van controle. Organisaties vragen of een nieuwe assistent tijd bespaart, maar veel minder vaak wat er gebeurt als de leverancier wordt gecompromitteerd, welke scopes precies zijn verleend, welke logging beschikbaar is en hoe snel toegang kan worden ingetrokken. Zodra AI van experiment naar operatie schuift, zijn dat geen randvragen meer voor security. Het worden kernvragen voor engineering en governance.
Laava-perspectief
Bij Laava zien we dit als opnieuw bewijs dat productie-AI als gelaagd systeem moet worden ontworpen. Context, reasoning en actie horen niet automatisch binnen dezelfde vertrouwensgrens te vallen. Een tool die informatie helpt ophalen, heeft niet vanzelf ook recht nodig om records te wijzigen. Een drafting-assistent heeft niet vanzelf workspace-brede adminzichtbaarheid nodig. En een workflow-agent die wel actie mag nemen, moet standaard werken met strak afgebakende credentials, expliciete regels en volledige auditability.
Dat wordt nog belangrijker zodra AI is gekoppeld aan systemen van record zoals ERP, CRM, e-mail of interne documentomgevingen. De echte vraag is niet alleen of het model een goed antwoord geeft. De echte vraag is of de integratiearchitectuur de schade beperkt als er upstream iets misgaat. Als een third-party AI-leverancier wordt gecompromitteerd, kun je dan snel toegang intrekken, de getroffen workflow isoleren en de rest van het bedrijf laten doorlopen? Als het antwoord nee is, dan zit de architectuur nog op demoniveau, ook als de UX er netjes uitziet.
Er zit ook een soevereiniteitslaag in dit verhaal. Veel bedrijven denken dat soevereiniteit begint en eindigt bij modelhosting, bijvoorbeeld door te kiezen voor een open model of een EU-cloud. Dat helpt, maar het is niet genoeg. Als brede toegang nog steeds via externe SaaS-tools met ondoorzichtige permissies loopt, is je controle zwakker dan je denkt. Echte soevereiniteit gaat dus niet alleen over modelkeuze, maar ook over identity boundaries, vendor inventory, intrekprocedures, approvalgates en een schone scheiding tussen experiment en productie.
Wat je nu kunt doen
Begin met een inventarisatie. Maak een lijst van alle AI-gekoppelde applicaties die op dit moment toegang hebben tot Google Workspace, Microsoft 365, Slack, GitHub, je CRM en je deploymentstack. Classificeer ze daarna op toegangsniveau: alleen lezen, operationele metadata, schrijfacties of admincapaciteit. De meeste organisaties ontdekken dan dat ze veel meer bereik hebben verleend dan de bedoeling was, vaak omdat een pilottool snel is goedgekeurd en daarna nooit meer opnieuw is beoordeeld.
Verstevig daarna het controlevlak. Verwijder ongebruikte apps, beperk scopes, roteer blootgestelde secrets en zorg dat workflows met hoge impact dedicated service accounts gebruiken in plaats van brede menselijke OAuth-grants. Voor AI-agents die echte systemen raken, is read first een goede standaard. Vraag waar mogelijk expliciete goedkeuring voor writes en log elke relevante actie. Het Vercel-incident is geen reden om AI in productie te vermijden. Het is wel een reden om AI-integraties met dezelfde engineeringdiscipline te behandelen die je ook verwacht van betalingen, identity en infrastructuurtooling.