De moeilijkste AI-beveiligingsproblemen bevinden zich nu buiten het model

De 2026 OWASP Top 10 voor LLM-toepassingen biedt een kritisch perspectief op de volwassenheid van productie‑AI. Het legt een cruciale verschuiving vast: de sector gaat voorbij de sandbox en worstelt met de complexiteit van integratie in de echte wereld.

Wanneer je een LLM koppelt aan bedrijfs‑tools en -werkstromen, verandert het dreigingsoppervlak fundamenteel. Risico’s die verband houden met autoriteit en middelengebruik worden aanzienlijk moeilijker te beheersen. Tegelijkertijd verdwijnen kwetsbaarheden zoals onjuiste outputafhandeling van de voorgrond, niet omdat ze zijn opgelost, maar omdat andere problemen naar de voorgrond zijn geschoven.

De OWASP Top 10‑ranking weerspiegelt deze evolutie. “Excessive Agency” is gestegen van zesde naar derde, terwijl “Unbounded Consumption” naar zesde is geklommen. Omgekeerd is “Improper Output Handling” gedaald naar tiende.

Dit vermindert het risico van outputafhandeling niet. Als een LLM‑antwoord een shell of database bereikt zonder rigoureuze validatie, blijven traditionele injectie‑fouten bestaan. Het paradigma is echter verschoven. In een agent‑systeem is de respons van het model niet de bestemming; het is een invoer die autoriteit draagt. Wanneer een model inloggegevens bezit of met een API communiceert, fungeert de output als een vector die acties kan activeren in verschillende systemen.

De beveiligingsuitdaging bestaat niet langer alleen uit het evalueren van het model; het gaat om het definiëren van de grenzen van wat er gebeurt na inferentie. Jouw architectuur bepaalt of een hallucinatie in tekst blijft of zich manifesteert als een ongeautoriseerde databasemutatie.

De ranking volgt de schade

OWASP gebruikte 7,714 incidenten, 75 % gedreven door consensus van de gemeenschap, en 25 % door empirische incidentgegevens. Deze bewijslast dwong een daadwerkelijke herschikking van prioriteiten.

“Excessive Agency” steeg omdat de realiteit van productieomgevingen de theorie inhaalde. Organisaties versnellen de inzet van autonome mogelijkheden sneller dan ze de benodigde control‑planes opzetten. De kritieke kwetsbaarheid is niet alleen het antwoord dat het model geeft, maar de autorisatie‑context waarin dat antwoord wordt uitgevoerd.

Hoewel “Improper Output Handling” een zorg blijft, hebben DevOps‑teams zich ontwikkeld in hun vermogen om downstream‑sinks te beveiligen via schemasvalidatie en geparameteriseerde queries. Dit zijn gevestigde praktijken op het gebied van applicatiebeveiliging.

Agency is echter een andere klasse van probleem. Een tool‑aanroep kan structureel geldig zijn maar contextueel illegitiem. Het model kan een goedgekeurde functie aanroepen voor een ongepaste taak of de verkeerde bron targeten. Statische sanitisatie kan de intentie niet beoordelen. Dit vereist een geavanceerde, context‑bewuste autorisatie die het model nooit in isolatie mag uitvoeren.

Behandel elk hulpmiddel als een blootgestelde mogelijkheid

Veel teams behandelen tool‑definities slechts als integratie‑infrastructuur. Dit is een nogal lachwekkende en fundamentele fout. Elke tool, connector of API‑endpoint vergroot de invloedssfeer van de AI‑applicatie.

Beschouw een agent die is ontworpen om een mailbox samen te vatten. Als de implementatie een brede connector gebruikt die schrijf‑ of verwijderfunctionaliteit omvat, introduceer je overmatige functionaliteit nog voordat de eerste prompt wordt verwerkt.

Je moet het principe van minste privilege handhaven:

• Beperk de interface: Voorzie de agent van alleen‑lezen tools in plaats van algemene connectors.
• Gescopeerde context: Voer verzoeken uit binnen de OAuth‑gescope‑identiteit van de gebruiker.
• Policy Enforcement Points (PEP): Implementeer autorisatielogica als verplichte middleware tussen het model en downstream‑systemen. Elke actie moet vóór uitvoering tegen beleid worden gevalideerd.
• Human-in-the-loop (HITL): Vereis expliciete goedkeuring voor handelingen die moeilijk ongedaan te maken zijn of een grote materiële impact hebben.

Deze aanpak vereist een verschuiving in de leverings‑pipeline. Jouw reviewproces moet zich uitbreiden voorbij het model om wijzigingen in tool‑schemas, service‑identiteiten en permissiescopes te omvatten. Een model‑update lijkt onschadelijk, maar een wijziging in de autorisatie‑context van een connector kan een catastrofale kwetsbaarheid veroorzaken.

Zichtbaarheid is ononderhandelbaar. Je moet de specifieke tool‑uitvoering, de autoriserende identiteit en de resulterende wijziging in het doelsysteem loggen. Deze keten van bewaring is essentieel voor incidentrespons, zodat je een actief proces kunt onderbreken en de audit‑trail na een incident kunt reconstrueren.

Elke autonome run vereist een harde stop

“Unbounded Consumption” is gestegen omdat het aantal verzoeken een ontoereikende maatstaf is voor resource‑risico. Een enkele, beknopte prompt kan een recursieve, resource‑intensieve keten van tool‑aanroepen activeren. De teller stopt pas wanneer de agent klaar is.

Eenvoudige waarschuwingen zijn onvoldoende wanneer de uitvoeringssnelheid de menselijke reactie overtreft. Je hebt deterministische, harde limieten nodig die buiten de controle van de agent blijven. Implementeer strikte plafonds voor token‑gebruik, verstreken tijd, recursiediepte en cumulatieve operationele kosten. Als een uitvoering deze parameters overschrijdt, moet het systeem de run beëindigen of afremmen.

De operationele reikwijdte vereist dezelfde strengheid. Bepaal het maximale aantal records dat een agent mag wijzigen en definieer de grenzen van taakpropagatie. Als uw architectuur geen deterministisch “stop”-mechanisme heeft, heeft u in feite autoriteit gedelegeerd zonder de perimeter ervan te definiëren.

Bouw voor het verkeerde antwoord

Systeemengineering heeft al lang vertrouwd op veerkrachtige architectuur om van nature onbetrouwbare componenten te beveiligen. We anticiperen op componentfalen en netwerkinstabiliteit; beveiliging is afgeleid van die veronderstelling, niet van de illusie van perfectie. LLM’s vereisen dezelfde architecturale discipline.

Baseer uw beveiligingsstrategie niet op de veronderstelling van perfecte modelafstemming. Ga uit van falen, of het nu gaat om een onschadelijke misinterpretatie of een kwaadwillige exploitatie. Beperk de mogelijkheden van de agent tot het absolute minimum dat nodig is en handhaaf strikte gebruikersautorisatiecontexten voor alle downstream‑aanroepen. Cruciaal is dat beleidsafdwinging buiten het model moet bestaan om te voorkomen dat prompt‑injectie of redeneerfouten uw controles omzeilen.

We beschouwen Prompt Injection nu minder als een kwetsbaarheid en meer als een natuurwet. Het zal altijd aanwezig zijn. Het feit is dat de modellen zelf geen effectieve beslissers kunnen zijn voor beveiligingskritieke vragen. In een echt agentisch project dat ik bouw, hebben we ongeveer 100 geautomatiseerde “red team”‑tests. We zorgen ervoor dat we ze allemaal doorstaan. Maar we doen dit door harde controles buiten het model te bouwen. We kunnen dit uitschakelen en de slaag‑/faalpercentages voor alleen het model bekijken. Het oudste, zwakste model dat we testen, faalt 17 % van de tijd. Het nieuwste, grootste model faalt 2 % van de tijd. Grote vooruitgang, toch? Maar is 98 % goed genoeg wanneer elke fout leidt tot lekken van gevoelige gegevens? Bijna zeker niet.

Operaties met hoge impact moeten waarneembaar, geaudit en idealiter omkeerbaar zijn. Elke autonome uitvoering vereist onveranderlijke waarborgen die buiten het bereik van het model blijven.

De ranglijsten van 2026 werpen echt licht op waar AI‑fouten overgaan in materiële consequenties. Het model kan de fout initiëren, maar de architectuur bepaalt de straal van de explosie. Voor productie‑AI vindt het meest kritieke beveiligingswerk plaats in de post‑inference‑pipeline.