APIs hadden vroeger een eenvoudig verkeersmodel. Een developer registreerde zich, kreeg een sleutel, bouwde een integratie en die integratie riep je endpoints aan volgens een schema of wanneer een gebruiker op iets klikte. Botbeheer voor APIs groeide op rond dat model: authenticeren van de sleutel, volume begrenzen, duidelijk misbruikverkeer filteren en de service beschikbaar houden voor iedereen anders.
Dat model geldt nog steeds, en de tools die daarvoor zijn gebouwd blijven belangrijk. Wat is veranderd, is wie er achter de aanroepen zit. Dezelfde API-sleutel kan nu verzoeken dragen van een persoon die de app van je klant gebruikt, een persoon die een AI-assistent heeft gevraagd het werk te doen, en een autonome agent die 's nachts een meerstaps-taak uitvoert. Je bestaande controles zien één sleutel en één verzoeksnelheid. Je product-, support- en beleidsbeslissingen moeten vaak meer weten.
Proof of Actor vult dat gat. Het vertelt je API wie of wat handelt op elk verzoek en vermeldt het bewijs, en laat de beslissing daarna over aan je code. Deze pagina vergelijkt het met de belangrijkste lagen van API-bescherming tegen bots, zodat je kunt zien waar elk onderdeel hoort.
De korte versie
| API-bescherming tegen bots | Proof of Actor | |
|---|---|---|
| Hoofdvraag | Is dit verzoek toegestaan, geauthenticeerd en binnen de limieten? | Wie of wat handelt er, en wat is het bewijs? |
| Typische lagen | API-gateway, WAF-botregels, API-sleutels, rate limits | Actorclassificatie binnen je API of MCP server |
| Identificeert | Het account of de integratie die de sleutel bezit | De actor achter elk verzoek: Human, Human + AI, Agent of Unknown |
| Output | Toestaan, afwijzen, vertragen; soms een botscore | Een klasse plus een basis: verified, declared, inferred of unknown |
| Onduidelijk verkeer | Meestal toegestaan als de sleutel geldig is, of afgewezen door een regel | Unknown, met een fallback die je per route kiest |
| Wie beslist over de reactie | Gateway- en WAF-configuratie | Je applicatiecode |
| Standaard bij installatie | Handhaving | Observatie; er verandert niets totdat je een beleid toevoegt |
| Sterkste punt | Beschikbaarheid, misbruikfiltering, quota, verantwoordelijkheid | Elke actor correct bedienen en API-gebruik begrijpen |
De onderstaande secties leggen elk onderdeel uit.
Wat API-bescherming tegen bots goed doet
Het is de moeite waard om precies te zijn over het werk dat elke laag doet, omdat Proof of Actor is ontworpen om naast al deze lagen te staan, niet om ze te vervangen.
API-gateways
Een gateway is de voordeur van je API. Hij beëindigt verbindingen, authenticert API-sleutels of tokens, routeert verzoeken naar de juiste service, dwingt quota af en registreert vaak gebruik voor facturatie en analytics. Hij beantwoordt snel en consistent over elk endpoint heen: "is deze aanroeper toegestaan, en via welke deur?"
WAF-botregels
Een web application firewall met botregels inspecteert verkeer op bekende aanvalspatronen en misbruikautomatisering. Hij kan injectiepogingen filteren, verkeer blokkeren van bronnen met een geschiedenis van misbruik, en verzoeken uitdagen of laten vallen die lijken op scraping of credential-aanvallen. Het is je beste verdediging tegen verkeer dat je code nooit zou moeten bereiken.
API-sleutels en tokens
Sleutels en tokens geven je verantwoordelijkheid. Elk verzoek wordt gekoppeld aan een account, zodat je weet welke integratie een call deed, toegang kunt intrekken en gebruik kunt toeschrijven. Scoped tokens gaan verder en beperken wat een aanroeper mag doen.
Rate limits
Rate limits beschermen beschikbaarheid. Ze voorkomen dat één integratie capaciteit opslokt die voor iedereen bedoeld is, en ze vertragen brute-force- en enumeratiepogingen. Limieten per sleutel en per route zijn een standaard en effectieve controle.
Samen beantwoorden deze lagen de vragen rond bescherming en verantwoordelijkheid heel goed. Behoud ze.
De vraag die ze niet ontworpen zijn om te beantwoorden
Geen van die lagen is ontworpen om je te vertellen wat voor actor er achter een geauthenticeerd verzoek zit. Een geldige sleutel zegt welk account de integratie bezit. Hij zegt niet:
- of deze specifieke call kwam van een persoon die op een knop tikte in de app van je klant,
- of een persoon een AI-assistent vroeg de actie uit te voeren,
- of een autonome agent de call deed als een stap in een langere taak,
- of dat niemand het kan zeggen.
Dat onderscheid wordt elke maand belangrijker. Een API die een CRM-integratie, een planningstool of een ontwikkelaarsplatform bedient, ontvangt steeds vaker agentverkeer via dezelfde sleutels die ook menselijke apps bedienen. Als je agents een gestructureerde reactie wilt geven, bevestiging wilt vragen voor writes met hoge impact die door agents worden aangestuurd, AI-ondersteunde inzendingen wilt labelen, of simpelweg wilt meten hoeveel van je API-gebruik door agents wordt aangestuurd, heb je actorcontext nodig.
Wat Proof of Actor toevoegt aan een API
Proof of Actor geeft voor elke interactie één van vier klassen terug:
- Human: de observeerbare signalen wijzen op mensgestuurde interactie.
- Human + AI: een persoon stuurde de interactie met AI-ondersteuning die gedeclareerd of waargenomen werd via een ondersteunde integratie.
- Agent: geautomatiseerde of agent-gegenereerde interactie.
- Unknown: het bewijs ondersteunt geen betrouwbare vaststelling.
Elke uitkomst vermeldt ook de evidence basis:
- Verified: bijvoorbeeld een HTTP Message Signature (RFC 9421) die is gecontroleerd tegen een gepubliceerde sleutel.
- Declared: de client of je eigen applicatie heeft het gedeclareerd.
- Inferred: gedrags- of contextsignalen, duidelijk gelabeld als inferentie.
- Unknown: geen betrouwbare basis.
Voor APIs is de verified basis bijzonder nuttig. Agents die hun verzoeken ondertekenen kunnen worden gecontroleerd tegen hun gepubliceerde sleutels, wat de aanpak is achter het IETF Web Bot Auth-werk. Lees de uitleg over Web Bot Auth voor productteams voor achtergrond, en de handleiding over ondertekende agentverzoeken verifiëren voor de implementatiekant.
Eén beperking is hier belangrijk. Een geldige handtekening bewijst welke sleutel het verzoek heeft ondertekend. Hij bewijst niet dat de agent bevoegd is om de actie uit te voeren. Autorisatie blijft waar die hoort, in de toegangscontrole van je eigen API. De invoer over agentautorisatie legt het verschil uit.
Scores en sleutels versus actorevidence
Sommige producten voor botbescherming koppelen een score aan elk verzoek. Een score is efficiënt voor een blokkeerbeslissing. Hij is minder bruikbaar voor productbeslissingen rond API's, omdat hij niet vertelt of een legitiem verzoek door een mens of door een agent werd aangestuurd, en omdat hij feit en inferentie niet scheidt.
API-sleutels hebben de omgekeerde beperking. Ze zijn precies over eigendom en stil over de actor. De sleutel van één klant kan in één uur alle vier de klassen dragen.
Proof of Actor houdt beide onderscheidingen zichtbaar. Je API ziet het account uit de sleutel, de actorclassificatie uit Proof of Actor, en de basis die die ondersteunt. Elke laag beantwoordt de vraag waar die goed in is.
Waar elk onderdeel draait
Gateways en WAF's draaien aan de rand van je netwerk of vóór je services. Die positie is juist voor bescherming en quota's.
Proof of Actor draait waar je API-logica leeft. Founding-teams kunnen integreren via Node.js-middleware, Next.js, een edge-laag die jij beheert, de generieke HTTP API of een MCP server-integratie. Zie integraties voor de volledige lijst. Omdat het binnen je applicatie draait, kan het gebruiken wat je API weet: de route, de workflow, of een client zichzelf heeft gedeclareerd, en of een handtekening is geverifieerd.
Routingbeslissingen blijven in je code
Proof of Actor blokkeert standaard niets. Het begint in observatiemodus, dus installeren verandert niets aan hoe je API reageert. Je ziet je actorverdeling per endpoint, bekijkt het bewijs voor individuele resultaten en volgt je Unknown-percentage.
Wanneer je klaar bent, schrijf je toepassingsgedefinieerde beleidsregels per route, per actorclass en per basis. Typische uitkomsten zijn:
- Allow: het verzoek normaal bedienen.
- Adapt: een gestructureerde of beperkte respons teruggeven voor een geverifieerde agent.
- Challenge: een extra bevestigingsstap vereisen, bijvoorbeeld menselijke goedkeuring op een write met hoge impact.
- Review: de actie in een wachtrij plaatsen zodat een persoon die kan controleren.
- Rate-limit: een strakkere limiet toepassen op een specifieke klasse en basis op een specifieke route.
Je kunt een beleid eerst tegen echt verkeer previewen voordat je het handhaaft, en daarna route voor route handhaven. De gids over actorbewust beleid veilig uitrollen behandelt het proces, en gevoelige acties beschermen zonder agents te blokkeren laat veelvoorkomende patronen zien.
Unknown API-aanroepers afhandelen
Elke API ontvangt verkeer dat niet met vertrouwen kan worden geclassificeerd. Bij traditionele controles betekent een geldige sleutel meestal dat het verzoek doorgaat, en een ongeldige sleutel betekent dat het niet doorgaat. Er is niets ertussenin.
Proof of Actor geeft je een expliciete Unknown-uitkomst en laat je per route de fallback kiezen. Read-only catalogus-endpoints kunnen open blijven. Accountwijzigingen kunnen je bestaande strengere controles behouden. Bulk-exports kunnen naar review gaan. Zie Unknown-verkeer afhandelen en onbekend geautomatiseerd verkeer voor de details.
Hoe ze samenwerken
De sterkste API-opzet gebruikt elke laag voor zijn eigen werk:
- Aan de rand filtert de WAF misbruik- en foutief gevormd verkeer.
- Bij de gateway worden sleutels geauthenticeerd, quota's afgedwongen en gebruik vastgelegd.
- Binnen de API classificeert Proof of Actor elk verzoek dat erdoorheen komt en vermeldt de basis.
- In je handlers gebruiken beleidsregels de klasse en basis om de reactie te kiezen: normale afhandeling voor een mensgestuurde call, een gestructureerde reactie voor een geverifieerde agent, een bevestigingsstap voor een agentgestuurde write met hoge impact, een fallback voor Unknown.
- In analytics ziet je team welke endpoints en workflows elke actorclass gebruikt, naast de accountdata van de gateway.
Niets in deze stack is dubbel. De gateway kent het account, de WAF kent de dreigingspatronen, en Proof of Actor kent de actor.
Wanneer je je waarop moet richten
Richt je eerst op API-bescherming tegen bots wanneer je belangrijkste problemen misbruik, beschikbaarheid of ongelimiteerd gebruik zijn: credential-aanvallen op authenticatie-endpoints, agressief scrapen, of één integratie die anderen verdringt.
Richt je op Proof of Actor wanneer je belangrijkste vragen over je aanroepers gaan: hoeveel van je API-verkeer door agents wordt aangestuurd, welke agents welke endpoints aanroepen, waar mens- en agentgestuurd gebruik verschillen, en welke routes een actorbewust beleid nodig hebben. De APIs use case en AI-agentidentificatie voor APIs gaan dieper in.
De meeste teams die een productie-API draaien, hebben antwoorden op beide nodig.
Aan de slag
Proof of Actor bevindt zich in private beta. Geselecteerde founding developer-teams kunnen tot 12 maanden gratis toegang krijgen binnen afgesproken gebruikslimieten, zonder automatische facturering. Vraag early access aan en vertel ons over de API en de aanroepers die je wilt begrijpen.