Voor het grootste deel van de geschiedenis van het web had geautomatiseerd verkeer één taak in de beveiligingsstack: worden geïdentificeerd en gestopt. Botbeheer is rond die taak ontstaan. Het staat aan de edge van je infrastructuur, scoort requests en blokkeert of daagt de verzoeken uit die er misbruikachtig uitzien. Het doet dat heel goed, en je moet het behouden.
AI-agents hebben veranderd wat applicaties moeten weten. Een groeiend deel van de geautomatiseerde requests komt nu van agents die namens echte klanten handelen: een assistent die abonnementen vergelijkt, een agent die een supportticket indient, een client die je MCP server aanroept om een taak af te ronden. Tegelijk gebruiken veel mensen je product met een AI-assistent naast zich. Dit zijn geen aanvallen. Het zijn gebruikers, en zij verdienen de juiste ervaring in plaats van een blokpagina.
Dat is de leemte die Proof of Actor vult. Deze pagina vergelijkt de twee categorieën helder, zodat je ziet waar elk van beide hoort.
De korte versie
| Botbeheer | Proof of Actor | |
|---|---|---|
| Hoofdvraag | Moet dit request worden gestopt? | Wie of wat handelt hier, en wat is het bewijs? |
| Waar het draait | Aan de edge, vóór je applicatie | In je applicatie, API of MCP server |
| Typische uitkomst | Toestaan, blokkeren of uitdagen; vaak een score | Human, Human + AI, Agent of Unknown, plus een basis |
| Behandelt mensen die AI gebruiken als | Meestal niet te onderscheiden van andere mensen | Een aparte klasse, Human + AI |
| Behandelt onduidelijk verkeer als | Vaak uitgedaagd of geblokkeerd | Unknown, met een fallback die je per route kiest |
| Wie de reactie bepaalt | De edge-regels | De code van je applicatie |
| Standaardgedrag bij installatie | Handhaving | Observatie; niets verandert totdat je een policy toevoegt |
| Beste in | Credential stuffing, scraping misbruik en volumetrische aanvallen stoppen | Product-, analyse- en beleidsbeslissingen voor elke actor |
De rest van deze pagina licht elke rij toe.
Twee verschillende vragen
Botbeheer beantwoordt een beschermingsvraag. Het doel is om misbruik door automatisering weg te houden van je infrastructuur, je accounts en je inventaris. Elk signaal dat het verzamelt dient dat doel, en de uitkomst is een beslissing: laat het request door, blokkeer het, of zet er een challenge voor.
Proof of Actor beantwoordt een begripsvraag. Het doel is om je applicatie te vertellen wie of wat elke interactie aanstuurt, zodat je kunt beslissen hoe je die bedient. De uitkomst is geen oordeel over het request. Het is een classificatie met het bewijs erbij:
- Human: de observeerbare signalen wijzen op door mensen aangestuurde interactie.
- Human + AI: een persoon stuurde de interactie met AI-ondersteuning die werd gedeclareerd of waargenomen.
- Agent: geautomatiseerde of agent-gestuurde interactie, ondersteund door verifieerbare identiteit of een gekwalificeerde inferentie.
- Unknown: het bewijs ondersteunt geen betrouwbare vaststelling.
Elk resultaat vermeldt ook zijn evidence basis: Verified, Declared, Inferred of Unknown. Dat is de informatie die een productbeslissing nodig heeft, en het is niet de informatie die een beschermingsscore is ontworpen om te dragen.
Waar elk van beide draait
Botbeheer draait meestal aan de netwerkedge of in een reverse proxy, vóór alles wat daarachter zit. Dat is precies de juiste plek voor bescherming. Het ziet verkeer vroeg, absorbeert aanvallen voordat ze je iets kosten, en houdt je origin-servers schoon.
Proof of Actor draait waar de logica van je applicatie leeft: server middleware, Next.js, de edge-laag die je zelf beheert, een goedgekeurde browserintegratie, een generieke HTTP API, of je MCP server. Die positie geeft toegang tot wat je applicatie weet: welke route wordt aangeroepen, bij welke workflow die hoort, of je eigen assistent een actie heeft uitgevoerd, en of een client zichzelf heeft gedeclareerd. Zie de integratiepaden voor de volledige lijst.
Omdat de twee op verschillende plaatsen draaien, concurreren ze niet om dezelfde taak. Een request kan langs je botbeheer komen, je applicatie bereiken, en daarna actorcontext krijgen die de reactie vormgeeft.
Scores versus bewijs
Veel beschermingsproducten drukken hun oordeel uit als een score. Een score is efficiënt voor een blokkeerbeslissing: kies een drempel, handel erboven. Het is veel minder bruikbaar wanneer de vraag is "welke ervaring moet deze actor krijgen?"
Een score vertelt je niet of een laagrisico-request van een persoon kwam, van een persoon die met een assistent werkte, of van een netjes gedragende agent. Het vertelt je niet welke delen van de conclusie Verified waren en welke Inferred. En het kan "we weten het niet" niet uitdrukken zonder het in een getal te persen.
Proof of Actor houdt die onderscheidingen in stand. Een Verified agentresultaat betekent dat een requestsignature is gecontroleerd tegen een gepubliceerde sleutel, bijvoorbeeld via HTTP Message Signatures. Een Declared resultaat betekent dat een client of je eigen applicatie dat heeft verklaard. Een Inferred resultaat wordt als inferentie gelabeld. En Unknown is een eersteklas antwoord in plaats van een verborgen standaardwaarde. Je team kan elk resultaat lezen en precies zien waarop het rust.
Mensen die AI gebruiken zijn geen bots
De snelst groeiende groep in de meeste applicaties zijn mensen die met AI werken. Ze stellen berichten op met een assistent, vullen formulieren in met hulp en bewegen door je product met een AI-tool naast zich. Beschermingstools zijn niet gebouwd om hen van andere mensen te onderscheiden, en daar is ook geen reden voor.
Je product heeft dat vaak wel nodig. Je wilt misschien AI-opgestelde supporttickets labelen zodat het juiste team ze afhandelt, meten hoe AI-ondersteunde gebruikers door onboarding gaan, of hen een soepelere route bieden. Proof of Actor geeft die groep een eigen klasse, Human + AI, en rapporteert die alleen wanneer de ondersteuning gedeclareerd is of waarneembaar is via een ondersteunde integratie. Lees meer in het glossariumitem AI-assisted interaction.
Unknown is een antwoord, geen bedreiging
Elke classifier komt verkeer tegen dat hij niet kan verklaren. Beschermingssystemen zijn gebouwd om voorzichtig te leunen, dus onduidelijk verkeer krijgt vaak een challenge. Dat is een verstandige keuze aan de edge.
Binnen je applicatie is één voorzichtige standaard vaak de verkeerde keuze. Een unknown request naar een openbare documentatiepagina en een unknown request om een accountwachtwoord te wijzigen verdienen heel verschillende afhandeling. Proof of Actor geeft Unknown als eigen resultaat terug en laat je de fallback per route instellen: toestaan op openbare pagina's, je bestaande controles behouden bij accountwijzigingen, of doorsturen naar review bij handelingen met grote impact. De gids over afhandeling van Unknown-verkeer loopt door de patronen heen.
Wie de reactie bepaalt
Met botbeheer bepaalt de regelset aan de edge. Dat is efficiënt en houdt beslissingen consistent over je properties heen.
Met Proof of Actor bepaalt je applicatie. Het product levert de actorcontext; je code past het beleid toe. Je kunt verifieerde agents een gestructureerde API geven in plaats van pagina's die voor mensen zijn gebouwd, de standaardervaring behouden voor humansessies, AI-ondersteunde submissions labelen, en sterkere credentials vragen bij gevoelige acties wanneer je eigen voorwaarden daarom vragen. Policies worden per route, per actorclass en per basis geschreven, en leven naast de rest van je businesslogica.
Eerst observeren
Botbeheer wordt meestal geïnstalleerd om af te dwingen, omdat de hele waarde ervan in het stoppen van misbruik zit.
Proof of Actor begint in observatiemodus. Installatie verandert niets aan hoe je applicatie zich gedraagt. Je ziet je werkelijke actormix per route, beoordeelt het bewijs, bekijkt vooraf het effect van een policy op echt verkeer, en handhaaft pas wanneer je er klaar voor bent, één route tegelijk. De gids over actorbewuste policies veilig uitrollen behandelt het proces.
Hoe de twee samenwerken
De sterkste opzet gebruikt beide, elk in zijn eigen laag:
- Aan de edge stopt botbeheer credential stuffing, scraping misbruik en volumetrische aanvallen.
- In je applicatie classificeert Proof of Actor het verkeer dat erdoorheen komt als Human, Human + AI, Agent of Unknown, met de bijbehorende basis.
- In je code gebruiken policies die context om de ervaring te kiezen: de gestructureerde API voor een verifieerde agent, de normale flow voor een persoon, een label voor een AI-ondersteunde submission, een expliciete fallback voor Unknown.
- In je analytics ziet je team welke routes en workflows elke actorclass gebruikt, zodat product en security vanuit hetzelfde beeld werken.
Door de edgebeslissing naast het actorresultaat vast te leggen wordt het beeld compleet: wat bescherming deed, en wie er daadwerkelijk handelde.
Wanneer kies je welke
Kies botbeheer wanneer je hoofdprobleem misbruik is: pogingen tot accountovername, het oppotten van inventory, agressief scrapen of verkeerstoenames.
Kies Proof of Actor wanneer je hoofdvraag over je gebruikers gaat: hoeveel van je product agents al gebruiken, welke agents je API of MCP server aanroepen, waar AI-ondersteunde mensen vastlopen, en welke routes een actorbewuste policy nodig hebben.
De meeste teams die een productieapplicatie, API of MCP server beheren, hebben antwoord op beide vragen nodig, en daarom horen de twee in dezelfde stack.
Aan de slag
Proof of Actor zit in private beta. Geselecteerde founding developer-teams kunnen tot 12 maanden gratis toegang krijgen binnen afgesproken gebruikslimieten, met directe ondersteuning van het team dat het bouwt. Vraag vroege toegang aan en vertel ons over de applicatie en de interactie die je wilt begrijpen.