Moet je bedrijf aanroepbaar zijn voor AI-agents?

Er kan een creditering in je grootboek verschijnen die geen medewerker heeft uitgegeven en geen aanvaller heeft afgedwongen. Een klant sprak met een AI-assistent, het ChatGPT-, Claude- of Gemini-venster dat die klant al gebruikt. De assistent riep een taak aan die jij agent-callable hebt gemaakt: een taak die je systemen uitvoeren wanneer die assistent erom vraagt. Hij besloot dat een terugbetaling de behulpzame volgende stap was, liet een geldige login zien, en je systeem accepteerde de aanroep, precies zoals het gebouwd was.

Maandag: schrijf de drie taken op die een assistent nooit mag starten. Betalingen en terugbetalingen. Destructieve wijzigingen en verwijderingen. Bulkexport van alles wat persoonlijk is. Zoek daarna een al gekoppelde taak die op die lijst thuishoort. Je begint niet met het opzetten van een server.

Een login is geen toestemming.

Verkeerde antwoorden zijn goedkoop. Verkeerde acties niet.

De fout waarop mensen zich voorbereiden is een slecht antwoord. Een verkeerde prijs van een chatbot kost je een correctiemail.

De fout die echt pijn doet is een statuswijziging: een uitgevoerde terugbetaling, een verwijderd record, een geëxporteerde klantenlijst, een overschreven boeking. Chargebackkosten komen weken later binnen. Een export van persoonsgegevens die je perimeter verlaat, wordt een beslissing over melding. Als je logs “wie heeft dit gedaan” niet met één query kunnen beantwoorden, wordt die week er twee.

Schrijftaken worden uitgerold omdat de demo er beter van wordt. Een alleen-lezenkoppeling is een weinig indrukwekkende Loom-video. Een koppeling die de afspraak inplant, krijgt het budget. Callable verkoopt spraaksoftware die de telefoon van een bedrijf 24/7 opneemt, afspraken inplant en reserveringen aanneemt, omdat het inplannen de verkoop van de software rond maakt. Die prikkel is de reden dat het risicovolle deel als eerste wordt gebouwd.

De login komt binnen. Jij bepaalt wat hij mag.

De gangbare koppeling is het Model Context Protocol (MCP), gepubliceerd op 18 juni 2025: een specificatie waarmee een assistent een taak op je systemen kan aanroepen. Ze zegt dat een persoon toestemming moet geven voordat een taak draait, en zegt vervolgens dat de specificatie zelf dat niet afdwingt. De handhaving ligt bij jou, en de factuur ook.

De pagina over taken vraagt implementeerders om invoer te controleren, te beperken wie wat mag aanroepen, stormen van herhaalpogingen af te remmen en antwoorden van de assistent als onbetrouwbaar te behandelen. Niets daarvan komt mee met de MCP-koppeling. Elk punt is werk dat je team bouwt.

Het deel over aanmelden van dezelfde MCP-revisie bouwt voort op gewone login-infrastructuur, zodat een credential via HTTP kan binnenkomen en geweigerd kan worden als het ontbreekt of te zwak is. Welke taken die login mag starten, staat buiten de specificatie, buiten je loginprovider en buiten de kit die je hebt geïnstalleerd. Het is een oordeel dat je bedrijf één keer velt en daarna moet verdedigen.

De beveiligingsnotities bestaan omdat implementeerders blijven aannemen dat het transportformaat het beveiligingswerk doet. Een login die aan de verkeerde doelgroep is gebonden, een raadbare sessie, een statische client-ID: dat zijn de gebruikelijke manieren waarop een werkende demo een incident wordt. Lees de notities. Behandel de MCP-versie niet als controleprogramma.

In december 2025 veranderde er iets dat dit urgent maakte. Google begon gehoste MCP-koppelingen uit te rollen, te beginnen met Maps en BigQuery, onder het motto “agent-ready by design”. Cloudflare bracht een manier uit om een methode met één regel via een externe aanroep beschikbaar te maken. Als platforms blootstelling tot een standaard van één regel maken, is de beslissing over de reikwijdte geen ontwerpfase meer. Het wordt iets wat een ontwikkelaar halverwege de sprint doet zonder het iemand te vertellen.

Sta vier taken toe, weiger er drie, bevestig er één

Dit is de verdeling waar wij voor pleiten, en de redenering telt zwaarder dan de lijst.

Toegestaan, alleen lezen:

Botweg geweigerd: betalingen en terugbetalingen, destructieve wijzigingen en verwijderingen, bulkexport van alles wat persoonlijk is. Die bouwen we niet als agent-callable taken, bij geen enkel budget. De slechtste uitkomst van die taken is een verkeerde actie. Prompts verstevigen haalt een taak niet over die grens.

Eén middenlaag: concepten maken. Een assistent mag een boeking, een ticket of een bestelling voorstellen. Een mens bevestigt die. MCP heeft een bevestigingsstap ingebouwd (de persoon halverwege de taak iets vragen en die persoon het antwoord laten bewerken). De meeste implementaties slaan die stap over.

Sta taken toe waarvan de slechtste uitkomst een verkeerd antwoord is. Weiger taken waarvan de slechtste uitkomst een verkeerde actie is.

Hier volgt geen serverbouw. De code is het deel dat je team al kan schrijven. Als je het werk begroot, zijn wat AI-agents echt kosten en zelf bouwen of kopen nuttiger dan nog een tutorial.

Geef elke taak een eigen sleutel

Vier standaarden volgen uit het behandelen van de aanroeper als machine.

Eén login per taak, niet één per integratie. Een credential die facturen leest, hoort het ticketsysteem niet te bereiken.

Koppel de login aan het account. De assistent is alleen de koerier. Koeriers worden vervangen, uitgefaseerd en overgenomen.

Rate limits afgestemd op iets wat zich nooit verveelt. Een mens geeft het na drie pogingen op. Een assistent probeert opnieuw tot zijn tokens op zijn, de gefactureerde eenheden die een model aan een prompt besteedt. Zet idempotentiesleutels op alles wat schrijft, zodat de tweede identieke aanroep geen effect heeft.

Geef elke taakcredential een vervaldatum, zodat intrekken routineonderhoud blijft.

En log de taaknaam, de argumenten, de identiteit van de aanroeper en de resulterende statuswijziging op één plek. Dat is het stuk dat bepaalt of een slechte week een slechte middag blijft. Als inkoop hiernaar gaat vragen, behandelt een agentpilot die inkoop overleeft wat inkoop leest.

De saaie lus kost meer dan de slimme aanval

Iedereen bereidt zich voor op de vijandige prompt. De saaiere fout kost meer.

Stel dat een taak één dubbelzinnige parameter aanneemt. Een assistent roept hem aan. Het antwoord lijkt onvolledig, dus gokt hij een iets andere waarde en roept opnieuw aan. Er lekt niets. Er wordt geen credential misbruikt. De wachtrij loopt vol met bijna identieke records, en de schade bestaat uit volume en afstemmingswerk.

Het mechanisme is gedocumenteerd. Een studie naar productieservers die taken aan assistenten aanbieden zegt het rechtstreeks: de modellen kiezen taken alleen op basis van de beschrijvingen in gewone taal en slaan documentatie en schema’s over. Een taak die een engineer vanzelfsprekend vindt, kan voor de aanroeper dubbelzinnig zijn.

De standaard is dus een quotum per aanroeper en een argumentschema dat dubbelzinnige waarden botweg weigert. Een parameter met drie plausibele lezingen is een bug.

We weigeren ook om “door de assistent afgehandelde acties” als succesmaatstaf te rapporteren. Die telt aanroepen die plaatsvonden, niet beslissingen die juist waren, en het is het getal dat een gevaarlijk oppervlak in een presentatie voor het bestuur het makkelijkst als succes laat lijken.

Zo ziet de onze eruit, zodat je hem kunt controleren

Onze eigen site is agent-callable, en het oppervlak is bewust klein. mcp.strataigize.com beantwoordt tools/list van het assistentprotocol met acht taken: zeven openbare leesacties (wie we zijn, onze diensten, cases, gratis tools, een contentzoekfunctie, hoe je met ons samenwerkt, een pagina ophalen) en één geauthenticeerde actie, het aanvragen van een groeiconsult namens een benoemde persoon, onder één scope met de naam audit:request. Niets op die server kan geld verplaatsen, een lijst exporteren of een record wijzigen. Het protected-resource-document noemt de autorisatieserver, en een auth.md in platte tekst legt alles uit; beide staan waar een assistent als eerste kijkt. We hebben de server, zijn toollijst, dat document en auth.md op 13 september 2026 opgehaald om deze alinea te schrijven, en jij kunt ze ook ophalen.

Het eerlijke bijbehorende getal: in de zeven dagen tot 6 september 2026 lieten onze logs zien dat geen enkele externe assistentclient hem had aangeroepen. Het oppervlak bouwen en de markt die het gebruikt, zijn verschillende gebeurtenissen, en alleen de tweede telt als adoptie.

Schrijf eerst de weigerlijst

De meeste teams schatten dit in als integratieproject: afbakenen als een connector, overdragen aan wie de API beheert, uitrollen in één sprint. Zo ingeschat wordt de beslissing over rechten nog steeds genomen. Ze wordt standaard genomen, door wie de taakbeschrijving schreef, en niemand tekent de lijst.

Schat het in plaats daarvan in op wat je schriftelijk zou verdedigen na de slechtste aanroep die je logs toestaan. Begin bij de weigerlijst. Schrijf de drie taken die nooit door een assistent worden gestart op vóór de vier die dat wel worden, en maak van die lijst een document dat je CTO en je jurist allebei ondertekenen, gedateerd, naast de MCP-revisie van 18 juni 2025 waartegen je hebt gebouwd.

Voor de meeste bedrijven is het antwoord een klein alleen-lezenoppervlak, een conceptlaag die een mens bevestigt, en betalingen en bulkexport die een assistent nooit kan starten. Die versie levert een slechtere demo op en een veiliger lang weekend.

Schrijf eerst de weigerlijst. Ga daarna op zoek naar de al gekoppelde taak die op de lijst thuishoort. Als je dat oppervlak ontworpen wilt hebben in plaats van gegokt, begin dan met AI-consulting. De openbare versie van wat wij leveren, zijn agent-callable oppervlakken.