Agenten die met een model communiceren en daarna tools aanroepen, lijken op het eerste gezicht veilig: het model beslist, het platform voert uit. Maar bij agent-toolcall flaws gaat het mis in de schakel tussen “modelbeslissing” en “tooluitvoering”. In recente meldingen bij AWS, Google en Vercel bleek dat bepaalde instructies een agentsysteem konden bereiken zonder dat het model daadwerkelijk een autoriserende turn draaide.
Dat is belangrijk, omdat bescherming zoals system prompts, contentfilters en model-guardrails pas effect hebben als het model daadwerkelijk aan de knoppen zit. Als de uitvoeringstap “model-achtig” aangeleverde gegevens vertrouwt, kan een aanvaller routes vinden waarbij toolcalls worden afgehandeld zonder echte modelcontrole.
Wat zijn agent-toolcall flaws precies?
In een normaal agentproces stuurt de SDK de gebruikersvraag, systeeminstructies, gespreksgeschiedenis en de lijst met beschikbare tools naar het model. Het model kiest vervolgens of het een tool moet aanroepen. Daarna geeft het model een gestructureerde instructie terug met een toolnaam en argumenten. Op basis daarvan voert de runtime de tool daadwerkelijk uit.
Bij de kwetsbaarheden achter agent-toolcall flaws ontbreekt of verliest men de bewijs-keten tussen de laatste stap van het model en de volgende stap in de runtime. De execution layer accepteerde data die de vorm had van een toolcall, alsof die uit een legitieme modelturn kwam. Daardoor kon de runtime dispatchen zonder dat er een echte modelautorisatie was geweest.
Waarom dat geen “prompt injection”-probleem is
Deze tekortkomingen draaien niet om het omzeilen van gedrag in een taalmodel. Er is geen kans om een model te “misleiden”, omdat het model in de kwetsbare paden soms helemaal niet draait. In plaats daarvan gaat het om autorisatiecontrole op het moment dat tools echt gestart worden.
AWS: AgentCore InvokeHarness en de shortcut rond tool-use
De AWS-melding kreeg een CVE met score (CVE-2026-18830, CVSS v4.0: 8.6). De kern zit in onvoldoende inputvalidatie binnen de AgentCore harness rond de InvokeHarness API.
In een scenario met een geauthenticeerde remote request kon een aanvaller een “tool-use”-contentblok in het eindbericht van het verzoek plaatsen. Vervolgens kon een event loop de genoemde tool direct dispatchen, zonder eerst het model te raadplegen.
AWS geeft aan dat dit betrekking had op de managed InvokeHarness API vóór 31 juli 2026. De fix bestaat uit server-side validatie die tool-use blocks van de beller afwijst voordat ze in de event loop belanden. Die mitigatie is volgens AWS automatisch toegepast en vereist geen actie van klanten.
Maar: de onderzoekers benadrukten dat het managed-service patchen niet automatisch gelijk staat aan het afdichten van vergelijkbare logic in open-source code. In Strands Python (een codebasis waarop de harness is gebaseerd) blijft een pad aanwezig dat “modeloverslaan” mogelijk maakt.
Strands behoudt de “skip model invocation”-branch
In de repository is volgens de onderzoekers een helper aanwezig die checkt of er tool-use in het laatste bericht zit. Sluit die check aan, dan stelt de event loop de stopreden op tool_use en neemt hij direct het nieuwste bericht over, zonder modelexecutie. In commentaar staat daarbij letterlijk het idee dat je modelinvoeging overslaat als de laatste boodschap ToolUse bevat.
Daarnaast is er een nauwer pad dat eerder opgeslagen tool-use berichten herstelt na een interrupt, in plaats van het “laatste” bericht blind te gebruiken. Ook die structuur laat zien waarom agent-toolcall flaws vooral ontstaan wanneer een runtime te veel vertrouwt op gestructureerde berichten.
Niet elk Strands-gebruik is direct op afstand exploiteerbaar. De blootstelling hangt af van de vraag of een applicatie toestaat dat onbevoegde partijen gestructureerde conversatiestatus kunnen aanleveren, of hoe gespreksgeschiedenis en tool-use-posities worden opgebouwd. AWS heeft volgens de onderzoekers ook geen aparte CVE en patchbereik gepubliceerd voor zelfstandige Strands deployments, en gaf aan dat dit volgens het shared-responsibility model bij de klantkant hoort.
Google: ADK voor Python en twee autorisatiepaden
Bij Google draait het om de Agent Development Kit (ADK) voor Python. Ook hier gaat het om het niet verifiëren van het bewijs tussen wat er in de sessie staat en wat er daadwerkelijk zou moeten worden uitgevoerd.
De eerste fout kreeg CVE-2026-18236 (CVSS v4.0: 9.3) en raakt ADK Python versies vóór 2.5.0. ADK bevat een concept waarbij een “gevoelige tool” om menselijke bevestiging vraagt. Een aanvaller die gebeurtenissen in de sessiegeschiedenis kan beïnvloeden, zou die bevestiging kunnen forgeren en vervolgens een niet-toegestane tool laten uitvoeren.
De fix van Google voegt checks toe zodat de bevestiging niet alleen “aanwezig” is, maar ook klopt met:
- de tool die bij de executing agent hoort
- de vraag of die tool inderdaad bevestiging vereist
- de toolnaam en argumenten zoals die eerder zijn vastgelegd
Google leverde daarnaast in dezelfde ADK 2.5.0 release een tweede set gerelateerde correcties. Het ging om situaties in een “resumable mode” waarbij user-authored events function_call onderdelen konden bevatten die als instructies voor tooluitvoering werden geïnterpreteerd.
Volgens de onderzoekers verwerpt Google inmiddels function calls in berichten die door de gebruiker zijn geschreven. Dat voorkomt paden waarbij uitvoering wordt afgeleid van user events in plaats van een echte modelroute.
Vercel: AI SDK harness pakketten en sandbox-naar-host autorisatie
Bij Vercel lagen de issues in de relay laag van de AI SDK harness. Dit gaat dus niet om een remote request die de autorisatie bypass’t, maar om een omweg tussen code die al in een Linux sandbox draait en tools die op de host beschikbaar zijn.
De kwetsbaarheden betroffen twee pakketten:
- @ai-sdk/harness-codex (CVE-2026-64650), gepatch vanaf versie 1.0.29
- @ai-sdk/harness-opencode (CVE-2026-64651), gepatch vanaf versie 1.0.28
De CVSS-waarde voor beide gevallen werd als 6.3 vermeld. De kern: de relay vertrouwde een proces als de command line een pad bevatte naar een “goedgekeurde helper script” (zoals een helperpad in de host-tool-mcp.mjs context, of een command line shim). Kwaadwillende code binnen de sandbox kon zo de check “voldoen” en vervolgens host-exposed tools aanroepen, inclusief secret lookups, deploymentacties en cloud API-calls—zonder dat een bijbehorend modelgebeurtenis dit legitimeerde.
Vercel heeft dit opgelost door de proces-path fallback weg te halen. In plaats daarvan accepteert de relay alleen een request wanneer die precies matcht met een korte, eenmalige autorisatie die hoort bij de waargenomen model event: toolnaam, invoer en autorisatiestatus moeten samen kloppen.
Welke aanvalspaden zijn het gevaarlijkst?
De onderzoekers benadrukten dat de drie gevallen niet identiek zijn. De “aanvalslogica” verschilt per product en per runtime:
- AWS betrof een geauthenticeerde remote request die tool-use blokken in het laatste bericht kon plaatsen.
- Google vereiste manipulatie of injectie van sessiegebeurtenissen, of user-authoring van function calls in specifieke flowvarianten.
- Vercel vereiste dat er al onbevertigde code draaide in de sandbox en dat er host-provided tools aanwezig waren.
Daarmee is de impact gebonden aan wat de agent sowieso kan. Heb je een agent die geen gevoelige tools of write-privileges krijgt, dan levert een autorisatiebypass niet automatisch “iets nieuws” op. Toch is het risico relevant: ook “niet gevoelige” tools kunnen ketens opbouwen (bijvoorbeeld door informatie op te halen of configuraties te beïnvloeden).
Gelijke les, drie oplossingen: controleer autorisatie bij tooluitvoering
Ondanks verschillen in techniek komen de remedies op hetzelfde controlemechanisme neer: laat de runtime geen data-structuur zoals een toolcall-achtig object gelijkstellen aan “een legitieme modelturn”. De controle moet plaatsvinden op het moment dat de tool wordt uitgevoerd.
Concreet lopen de oplossingen uiteen, maar de richting is vergelijkbaar:
- Google koppelt bevestiging aan sessiebestanden: tool en argumenten moeten overeenkomen met wat in de sessie is vastgelegd.
- Vercel bindt toolrelay requests aan een éénmalige autorisatie die hoort bij het waargenomen model event.
- AWS verwerpt caller-aangeleverde tool-use blokken voordat ze doorstromen naar de event loop.
Het gemeenschappelijke punt: als de runtime alsnog genoegen neemt met “het uiterlijk” van een toolcall, kan een aanvaller de autorisatieketen doorbreken.
Wat je vandaag kunt doen
Niet elke organisatie gebruikt exact dezelfde stacks, maar de mitigation-checklist voor agent-toolcall flaws is breed bruikbaar.
1) Update naar de gepatchte versies
- Google ADK voor Python: 2.5.0 of later
- @ai-sdk/harness-codex: 1.0.29 of later
- @ai-sdk/harness-opencode: 1.0.28 of later
Controleer daarnaast of je afhankelijkheden en lockfiles ook echt deze versies meenemen. Versiebeheer is hier geen detail: het is direct onderdeel van je beveiligingsmaatregelen.
2) Behandel toolcalls en gespreksstatus als onbetrouwbaar
Als gespreksgeschiedenis, sessiegebeurtenissen of structured tool-use blokken over een externe grens binnenkomen (bijvoorbeeld via je eigen API), beschouw ze dan als input van een potentiële aanvaller. Laat autorisatie niet afhangen van “wat er in de berichten staat”, maar van wat je runtime echt heeft geverifieerd.
3) Authoriseer bij uitvoering: toolnaam, argumenten en event koppelen
Zorg dat een toolinvocatie alleen kan starten wanneer de runtime het exacte model event, toolnaam, argumenten en de autorisatiestatus kan koppelen aan de uitvoeringscontext. Met andere woorden: de execution step moet een bewijs hebben, niet slechts een vorm.
4) Beperk de inherited authority van je agent
Geef agenten niet méér tools en privileges dan nodig. Minimaliseer cloud-rollen, credentials en schrijfrechten. Zo verklein je de opbrengst wanneer een aanvaller tóch een autorisatiecontrole weet te omzeilen.
Is er al misbruik gezien vóór de patches?
Ten tijde van de publicatie waren de advisories en CVE-registraties volgens de onderzoekers nog niet vergezeld van een publiek record dat bevestigt of de kwetsbare paden daadwerkelijk al in productie zijn gebruikt. Er is wel aangegeven dat de onderzoekers proof-of-concept code stuurden naar de getroffen vendors, maar dat ze geen exploitdetails openbaar maakten.
Ook zonder bewijs van actieve aanvallen blijft de les overeind: wanneer tool-autoriteit niet stevig genoeg wordt gevalideerd, kan het “modelgedeelte” worden overgeslagen—en daarmee vallen de beschermingen weg die je juist verwacht.
Conclusie
Agent-toolcall flaws laten zien dat beveiliging bij AI-agenten niet stopt bij promptbescherming of modelguardrails. Zodra een runtime tools uitvoert op basis van “toolcall-achtige” data, ontstaat een nieuw aanvakwetsbaar oppervlak: autorisatie tussen model en execution moet controleerbaar zijn, en bij de uitvoering zelf gevalideerd.
Werk je met agent frameworks of harness packages van AWS, Google of Vercel? Update dan naar de gepatchte versies en herzie je manier waarop gespreksstatus, bevestigingen en toolcalls over grenzen heen worden verwerkt. Daarmee maak je de keten sterker—en voorkom je dat een agent tools kan laten lopen zonder legitieme modelautorisatie.
Gerelateerd: als je ook te maken hebt met het risico van ongeautoriseerde toegang tot systemen, kan dit artikel over een eerder incident met tool-achtige misbruikroutes interessant zijn: Backdoor in Zbtlink routers: root shell mogelijk.
Bron: https://thehackernews.com/2026/08/aws-google-and-vercel-patch-agent-flaws.html
