Hoe geef je een AI agent toegang tot je API? Wij gingen ernaar kijken op Spring I/O 2026

AI agents zijn geen hype meer. Ze duiken steeds vaker op in software en interne tools. Iedere developer met een REST API stelt zich vroeg of laat de vraag: hoe geef ik een agent op een veilige manier toegang? En hoe doe je dat met de tools die we al hebben?

Op Spring I/O in Barcelona kregen we daar interessante inzichten over, in een talk van Adib Saikali. Zijn boodschap: de gangbare aanpak (MCP-wrappers) is een logische eerste stap, maar botst op grenzen. Het alternatief (HATEOAS) ligt eigenlijk al jaren op de plank.

Wat is een AI agent?

Stel je een lichaam met een brein voor. Het brein is het Large Language Model (LLM), dat redeneert, plant en beslist. Het lichaam zijn de tools waarmee het brein de buitenwereld beïnvloedt: APIs aanroepen, bestanden lezen, queries uitvoeren.

Een LLM op zich is dus geen agent. Pas wanneer een LLM tools kan aanroepen, beslissingen kan nemen op basis van hun output en autonoom een meerstapsdoel kan nastreven, spreken we van een agent. Claude in een chatvenster zonder tools is een LLM. Claude met tools (via function calling, MCP servers of de Agent SDK) is een agent.

Wat is HATEOAS?

Een goed ontworpen interface toont enkel de acties die op dat moment relevant zijn. Op een productpagina verschijnt “Voeg toe aan winkelmandje”. Pas na een betaling verschijnt “Volg je bestelling”. De gebruiker hoeft de URL-structuur niet uit het hoofd te kennen.

HATEOAS (Hypermedia as the Engine of Application State) past dat principe toe op APIs. Een respons bevat niet alleen data, maar ook links naar de volgende mogelijke acties. Een client moet niet weten dat hij een bestelling kan annuleren of laten verzenden: de response vertelt het zelf. Is de bestelling al verzonden? Dan ziet de client een “retour aanvragen”-link in de plaats. In de Spring-wereld werk je hiervoor met HATEOAS, dat naadloos samenwerkt met je Controllers en met Spring Security.

Wat heb je daaraan in een traditionele REST API?

Zelfs zonder agents biedt HATEOAS voordelen. De client hoeft de URL-structuur niet te kennen, dus interne wijzigingen breken de flow niet. Business rules blijven op de server (of een bestelling annuleerbaar is, hoeft de client niet te weten). De respons dient als state machine: welke acties geldig zijn, blijkt uit de aanwezige links. En Spring Security kan per response filteren welke links zichtbaar zijn, dus een supportmedewerker ziet andere acties dan een klant.

In de praktijk is HATEOAS lang gebleven bij "leuk in theorie, veel werk en te weinig voordelen". De meeste clients waren frontends die de URL-structuur toch al kenden. Maar dat plaatje verandert wanneer de client geen mens in een browser is, maar een AI agent.

De huidige aanpak: MCP-wrappers

Vandaag verloopt agent-naar-API-communicatie meestal via Model Context Protocol (MCP). De server biedt een lijst tools aan met hun parameters, en de agent roept ze aan wanneer nodig. Voor elke nuttige operatie in je REST API koppel je een MCP-tool.

Elke moderne agent ondersteunt MCP. Je kan tools per agent toelaten of weigeren, en het is een natuurlijke eerste stap zonder herontwerp van je API.

Maar er zijn nadelen. Elke tool moet bij elke vraag opnieuw aan het LLM worden voorgesteld. Een API met 100 endpoints? Dan stuur je 100 tools mee. Dat verzadigt de context, kost meer tokens (geld én latency) en verlaagt de tool-selectie-accuraatheid. Ook permissies zijn lastig: in zo'n vlakke lijst zie je alles tegelijk, ook tools die voor de huidige gebruiker irrelevant of verboden zouden moeten zijn.

HATEOAS voor agents

Het alternatief: maak je API zelf navigeerbaar, in plaats van er een MCP-laag overheen te plakken. De agent krijgt geen vaste lijst van tachtig tools, maar één instappunt. Elke respons bevat de links die op dat moment, voor deze gebruiker, in deze toestand relevant zijn. Tijdens de demo kreeg de agent de prompt "this is my localhost, use curl, tell me what it does", en bouwde van daaruit zelf een mentaal model van de API.

Authenticatie blijft eenvoudig: de gebruiker logt in via een gewone browser-flow, krijgt een JWT, en de agent gebruikt dat token. Credentials gaan nooit door het LLM.

De voordelen voor agents: context-efficiëntie (enkel relevante volgende stappen), security ingebakken (mag de gebruiker iets niet, dan ziet de agent de link gewoon niet), geen wrapper-laag om te onderhouden, en stateful workflows komen er vanzelf.

Maar er is ook een keerzijde: het werkt alleen voor APIs die je zelf beheert. Niet elke agent volgt links spontaan (Claude en GPT wel, kleinere modellen mogelijk niet). En het agent-ecosysteem is vandaag op MCP gebouwd: een MCP-server installeren is een kwestie van twee klikken.

MCP of HATEOAS, wanneer welke?

Het hangt af van de relatie tussen gebruiker, API en agent. Voor identity-bound toegang (een agent die handelt namens een specifieke gebruiker, op data die aan diens account hangt zoals financiële apps, healthcare, interne tools) voelt HATEOAS natuurlijker. Voor algemene toegang zoals zoekmachines en generieke utilities wint MCP op gebruiksgemak. In de praktijk wordt het wellicht een combinatie.

Veel stof tot nadenken dus

Geen radicaal nieuw inzicht, maar wel iets om bij stil te staan. HATEOAS heeft jaren in de hoek van "leuk in theorie" gezeten, maar in onze event-driven projecten zagen we er wél waarde in: één plek om te zien wat er gebeurd is en wat er nog kan. Agents lijken een nieuwe doelgroep waar dat principe goed op past.

Of HATEOAS de manier wordt om APIs aan agents aan te bieden, durven we niet voorspellen, daarvoor staan we nog te vroeg in de evolutie. Maar voor wie vandaag voor de keuze staat hoe een AI agent op een Spring/REST stack te ontsluiten, is het een denkrichting die het waard is om mee te nemen naast de mainstream MCP-route.