Uw API kent de key. Het kent de actor niet.
Elke API-request arriveert met enig bewijs van wie ervoor betaalt: een API key, een OAuth token, een sessie. Dat bewijs beantwoordt één vraag goed. Het vertelt u welk account verantwoordelijk is voor de call. Het vertelt u niet wat op dit moment daadwerkelijk de call uitvoert.
Een enkele API key kan worden gebruikt door een developer die in een terminal test, door een backendtaak die op schema draait, door een persoon die met hulp van een AI-assistent werkt, en door een autonome agent die de key kreeg en de opdracht heeft gekregen een taak af te ronden. Dat zijn heel verschillende actors. Ze hebben verschillende ritmes, verschillende faalmodi en verschillende risicoprofielen. Als u ze allemaal hetzelfde behandelt, beperkt u óf de legitieme automatisering waarop uw klanten vertrouwen, óf beschermt u de delen van uw API onvoldoende die nooit door een onbeheerde agent mogen worden aangestuurd.
AI-agentidentificatie voor APIs dicht dat gat. In plaats van alles af te leiden uit de key, krijgt u een classificatie van de actor achter elke request, samen met het bewijs dat die classificatie ondersteunt. Dat is wat Proof of Actor is gebouwd om te leveren, en de use case voor APIs laat zien hoe API-teams dit route voor route toepassen.
Waarom API-teams nu actorcontext nodig hebben
Geautomatiseerd verkeer naar APIs is niet nieuw. Scripts, integraties en crawlers maken al langer deel uit van het geheel. Wat is veranderd, is het type automatisering. AI-agents kunnen documentatie lezen, calls aan elkaar koppelen, creatief opnieuw proberen en handelen namens mensen die niet elke stap volgen. Veel daarvan is nuttig en welkom. Sommige zijn slecht gebouwd. Een paar zijn vijandig.
Zonder actorcontext grijpen API-teams vaak terug op botte middelen:
- Rate limits per key, die goede agents en slechte agents even hard afremmen.
- User-agentregels, die breken zodra een client een header wijzigt.
- Generieke blokkades, die legitieme automatisering ertoe aanzetten om in plaats daarvan uw webapp te scrapen.
Actorcontext laat u precies reageren. Een gesigneerde agent van een operator die u herkent kan een hogere limiet krijgen op read routes. Een onbekende aanroeper op een write route kan worden gevraagd om een sterker credential. Een mens die een AI-assistent gebruikt, kan een normale ervaring behouden. Het doel is niet om agents te stoppen. Het doel is om elk type aanroeper het juiste pad te geven. Voor wat een gesigneerd request u wel en niet kan vertellen, lees wat gesigneerde AI-agentrequests bewijzen.
Hoe AI-agentidentificatie werkt in Proof of Actor
Proof of Actor volgt voor elk request dezelfde evidence-first flow. U kunt de volledige uitleg lezen op How It Works; hier is de korte versie voor API-teams.
1. Signalen uit uw integratie
Uw integratie geeft Proof of Actor de signalen door die in die context beschikbaar zijn. Voor een API betekent dat doorgaans requestcontext zoals headers en protocolgegevens, eventuele cryptografische requestsignatures die de client aanlevert, en eventuele verklaringen die de client over zichzelf doet. Elk signaal krijgt een label met de herkomst.
2. Classificatie met basis
De signalen worden gecontroleerd en samengevoegd tot een van vier publieke classes:
- Human: de waarneembare signalen wijzen op een door een mens aangestuurde interactie.
- Human + AI: AI-ondersteuning is gedeclareerd of gedetecteerd door een integratie die dit kan waarnemen.
- Agent: geautomatiseerd of agent-afkomstig verkeer, ondersteund door verifieerbare identiteit of een zorgvuldig gekwalificeerde afleiding.
- Unknown: het bewijs ondersteunt geen betrouwbare vaststelling.
Elk resultaat heeft ook zijn basis: Verified, Declared, Inferred of Unknown. Dit is het deel dat API-teams het meest waarderen. Een request waarvan de HTTP message signature, zoals gedefinieerd in RFC 9421, valideert tegen een publiek gemaakte key, wordt gerapporteerd als Verified. Een client die zichzelf eenvoudigweg als agent noemt, wordt gerapporteerd als Declared. Een patroon dat geautomatiseerd lijkt, wordt gerapporteerd als Inferred. U hoeft nooit te raden of een resultaat op cryptografie of op een heuristiek berust. De evidence basis maakt deel uit van het antwoord.
3. Een resultaat waarop uw code kan handelen
Het resultaat komt terug naar uw applicatie met de class, de basis en een leesbare evidence-samenvatting. Uw code beslist wat ermee te doen. In observatiemodus slaat u het simpelweg op. Wanneer u er klaar voor bent, routeert u erop.
Wat uw team krijgt: Detect, Understand, Route
Proof of Actor is één product met drie mogelijkheden.
Detect
Verzamel de actorsignalen die uw API kan zien en scheid geverifieerde verklaringen van gedragsmatige afleidingen. Gesigneerde agentrequests, gedeclareerde clients, automatiseringssignalen en Unknown-resultaten blijven allemaal gescheiden, zodat niets stilzwijgend wordt samengevoegd tot één score.
Understand
Zie welke actors welke routes aanroepen, hoe dat in de loop van de tijd verandert en welk bewijs achter elke classificatie zit. Het onbekende tempo blijft zichtbaar, zodat u precies ziet waar uw dekking ophoudt en waar een sterker signaal zou helpen.
Route
Schrijf beleid per route en per risiconiveau: allow, adapt, challenge, review of rate-limit. Houd een gestructureerd, ruim pad aan voor Verified agents op read-only endpoints. Vraag om sterkere credentials bij operaties met hoge impact. Definieer een expliciete fallback voor Unknown en voor timeouts, zodat uw API voorspelbaar blijft ongeacht wat er gebeurt. U bepaalt hoe elk beleid faalt, open of closed, op basis van de kosten van een fout op die route.
Identiteitsbewijs, credentials en autorisatie zijn drie verschillende dingen
De meest voorkomende fout in API-ontwerp met actorbewustzijn is drie aparte vragen samenvoegen tot één. Proof of Actor houdt ze gescheiden, en uw ontwerp zou dat ook moeten doen.
- Identiteitsbewijs: wat voor soort actor roept aan, en wat bewijst dat? Dat is wat AI-agentidentificatie levert. Een geverifieerde signature koppelt een request aan een key en de gepubliceerde operatoridentifier ervan. De IETF Web Bot Auth working group heeft als mandaat om dit soort cryptografische authenticatie voor geautomatiseerde clients te standaardiseren, en haar scope omvat het authenticeren van de agent in plaats van de eindgebruiker.
- Credentials: welk account is verantwoordelijk voor deze call? Dat is uw API key, token of sessie, uitgegeven en beheerd door u.
- Autorisatie: mag deze aanroeper dit specifieke doen? Dat is uw permissiemodel.
Een Verified agent is niet automatisch een geautoriseerde agent. Een geldige signature bewijst niet dat een persoon autoriteit aan de agent heeft gedelegeerd, en maakt de gevraagde actie ook niet veilig. Proof of Actor geeft u betrouwbaar context voor de eerste vraag en laat de tweede en derde precies waar ze horen: in uw applicatie. Lees meer over agentautorisatie en over wat het bewijs wel en niet kan vaststellen op Detection & Limitations.
Unknown is een functie, geen fout
Request signing is optioneel, en een ongesigneerde client kan zichzelf beschrijven zoals die wil. Een systeem dat elk request dwingt in Human of Agent zal op sommige momenten zelfverzekerd ongelijk hebben, en u zult niet weten wanneer.
Proof of Actor rapporteert Unknown wanneer het bewijs geen vaststelling ondersteunt. Unknown wordt nooit omgezet naar Human en wordt nooit standaard als kwaadaardig behandeld. Uw beleid bepaalt wat Unknown betekent voor elke route: toestaan op publieke reads, uw bestaande checks behouden op accountwijzigingen, het ter review in wachtrij zetten waar de inzet hoog is. Unknown zichtbaar houden is wat uw andere classificaties betrouwbaar maakt. De gids over unknown traffic afhandelen laat zien hoe u daarop ontwerpt.
Waar AI-agentidentificatie in uw stack past
Proof of Actor staat naast uw bestaande gateway, authenticatie en rate limiting. Het vervangt geen van deze. Typische plaatsingen zijn:
- Server-side middleware vóór uw routehandlers, zodat elk request wordt geëvalueerd voordat uw business logic draait.
- Aan de edge, zodat signalen worden geëvalueerd voordat requests uw origin bereiken.
- Een generieke HTTP-integratie, zodat elke stack requestcontext kan verzenden en een resultaat met de basis kan ontvangen.
Integraties worden samen met elk founding team tijdens onboarding hands-on geleverd, zodat het pad bij uw architectuur past en niet andersom. De developer hub toont de integratiepaden die vandaag beschikbaar zijn. Als u tools voor agents runt, behandelt de use case voor MCP Servers de specifieke patronen voor tool calls.
Begin in observatiemodus
Het installeren van Proof of Actor verandert niet hoe uw API reageert. Resultaten worden vastgelegd zodat uw team ze kan vergelijken met de uitkomsten die u al kent, kan zien waar agents daadwerkelijk heen gaan, de onbekende ratio per route kan meten en elke classificatie kan bekijken die fout lijkt. Pas daarna schakelt u een beleid in, route voor route, waar het bewijs dat ondersteunt.
Zo voert u AI-agentidentificatie uit zonder uw klanten te verrassen of de integraties te breken waarop zij vertrouwen. De gids over actorbewust beleid veilig uitrollen doorloopt de volgorde stap voor stap.
Sluit u aan bij het founding developer program
Proof of Actor zit in private beta met een kleine groep founding development teams. Geselecteerde teams kunnen tot 12 maanden gratis toegang ontvangen, binnen de gebruikslimieten die tijdens onboarding zijn overeengekomen, samen met directe integratieondersteuning van onze engineers en echte invloed op wat we hierna bouwen.
Als u een API beheert en wilt weten wie die echt aanroept, vraag early access aan. Vertel ons over uw API, de routes die voor u het belangrijkst zijn en de beslissingen die u anders zou nemen met actorcontext. Wij vertellen u hoe Proof of Actor past.
Bronnen
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- Web Bot Auth (webbotauth) working group charter, IETF.