Ga naar hoofdinhoud
GEVERIFIEERDE AUTOMATISERING

Herken geverifieerde geautomatiseerde verzoeken

Wanneer een geautomatiseerde client zijn verzoeken ondertekent, kan je applicatie die handtekening controleren en de aanroeper daarop behandelen. Proof of Actor maakt van die controle een duidelijk resultaat waarop je kunt routeren.

Krijg vroege toegangOntdek hoe het werkt
Toshendra Sharma

Door Toshendra SharmaOprichter & CEO, AgentCredia · Updated November 13, 2026

Niet al het geautomatiseerde verkeer is hetzelfde

Geautomatiseerde clients bereiken je applicatie elke minuut: zoekcrawlers, monitoringtools, partnerintegraties, AI-assistenten die pagina's ophalen voor een gebruiker, en autonome agents die taken uitvoeren. Jarenlang was de enige manier waarop de meeste applicaties ze uit elkaar konden houden de user-agent header, een string die elke client naar willekeur kan instellen.

Dat zet applicatieteams klem. Behandel je alle automatisering met wantrouwen, dan verslechter je de ervaring van legitieme agents waarop je klanten vertrouwen. Vertrouw je op de header, dan geef je iedereen de kans zich als een bekende crawler voor te doen.

Geverifieerde geautomatiseerde verzoeken veranderen die vergelijking. Wanneer een geautomatiseerde client zijn verzoeken ondertekent met een sleutel die het heeft gepubliceerd, kan je applicatie de handtekening controleren en cryptografisch weten welke client het verzoek heeft ondertekend. Proof of Actor maakt van die controle deel uit van één consistent actorresultaat waarop je code kan routeren. Voor een nadere blik op wat die controle wel en niet vaststelt, lees wat ondertekende verzoeken van AI-agents bewijzen.

Hoe verzoekondertekening werkt

De opkomende aanpak voor geautomatiseerd verkeer gebruikt HTTP message signatures, gestandaardiseerd in RFC 9421, dat definieert hoe je handtekeningen maakt, codeert en verifieert over onderdelen van een HTTP message. De client ondertekent geselecteerde delen van elk verzoek met een private key en neemt de handtekening en de parameters ervan op in headers. De bijbehorende public key publiceert hij op een locatie die is gekoppeld aan een identificatie die hij beheert, meestal zijn domein.

Wanneer het verzoek binnenkomt, haalt de ontvanger de gepubliceerde sleutel op of zoekt die op, reconstrueert de ondertekende inhoud en controleert de handtekening. Als die valideert, is het verzoek ondertekend door de houder van die sleutel. Werk aan het ondertekenen van geautomatiseerd verkeer loopt door in de IETF Web Bot Auth working group, waarvan het mandaat het cryptografisch authenticeren van geautomatiseerde clients omvat, zoals crawlers en AI-agents die namens eindgebruikers handelen; de woordenlijstvermelding Web Bot Auth vat dit samen. De blogpost over wat ondertekende verzoeken van AI-agents bewijzen loopt een geverifieerd verzoek van begin tot eind door, en de APIs use case laat zien waar verificatie het eerst rendement oplevert.

De gids over het verifiëren van ondertekende agentverzoeken behandelt de werking in detail, inclusief timestamps, replay windows en key caching.

Wat een geverifieerde handtekening bewijst, en wat niet

Dit onderscheid is het belangrijkste onderdeel van goed omgaan met geverifieerde geautomatiseerde verzoeken.

Een geldige handtekening bewijst dat het verzoek is ondertekend met een sleutel die gekoppeld is aan de gepubliceerde identificatie. Als de sleutel bij het domein van een operator hoort, kwam het verzoek van een client die de sleutel van die operator bezit.

Een geldige handtekening bewijst niet:

  • wie de agent opdracht gaf, of of een persoon om deze actie heeft gevraagd;
  • dat een persoon autoriteit aan de agent heeft gedelegeerd;
  • de juridische identiteit in de echte wereld achter de operator;
  • dat de gevraagde actie veilig of toegestaan is in je applicatie.

Dat zijn afzonderlijke vragen. Je applicatie beantwoordt ze met zijn eigen credentials, autorisatiemodel en beleid. Proof of Actor houdt ze bewust gescheiden, en de pagina over Detection & Limitations legt precies uit wat elk type bewijs kan vaststellen.

Hoe Proof of Actor geverifieerde geautomatiseerde verzoeken verwerkt

Detect

Je integratie geeft de verzoekcontext, inclusief eventuele signature headers, door aan Proof of Actor. Handtekeningen worden gecontroleerd tegen gepubliceerde sleutels. Verzoeken die valideren worden vastgelegd met een verified basis. Clients die alleen zichzelf noemen worden vastgelegd als declared. Gedragsmatige patronen worden vastgelegd als inferred. Als er niet genoeg is om op verder te gaan, is het resultaat Unknown. Niets wordt tot verified verheven tenzij een cryptografische controle is geslaagd.

Understand

Zie welke geverifieerde operators je applicatie aanroepen, welke routes ze gebruiken, hoe vaak, en hoe dat zich verhoudt tot declared en Unknown automatisering. De bewijs-samenvatting bij elk resultaat vertelt je welke sleutel en identificatie betrokken waren, zodat je team elk verzoek snel kan onderzoeken.

Route

Gebruik de basis in je policies. Veelvoorkomende patronen zijn:

  • Geef geverifieerde agents een gestructureerd antwoord op read-only routes, zoals een API of een Markdown-versie van een pagina.
  • Verhoog de rate limits voor geverifieerde operators die je herkent, terwijl je standaardlimieten behoudt voor declared clients.
  • Behoud je bestaande autorisatie op elke write route, ongeacht wat de handtekening zegt.
  • Definieer een expliciete fallback voor unsigned en Unknown aanroepen op elke route.

Je policies beslissen; Proof of Actor levert het bewijs.

Waarom de user-agent header niet genoeg is

User-agent strings zijn verklaringen. Elke client kan elke waarde sturen, en user-agent spoofing vraagt geen enkele vaardigheid. Daarom publiceren crawleroperators hun eigen controles: Google documenteert reverse en forward DNS-lookups en gepubliceerde IP-ranges voor het verifiëren van Googlebot, Bing documenteert een DNS-controle voor het verifiëren van Bingbot, en OpenAI publiceert IP-rangebestanden voor elk van zijn crawlers en user agents. Proof of Actor behandelt een user-agent claim als declared evidence, nooit als verificatie. Dat betekent dat een client die beweert een bekende crawler te zijn zonder geldige handtekening wordt gerapporteerd met een declared of inferred basis, en dat je beleid die anders kan behandelen dan een client die zijn identiteit heeft bewezen.

Dat is wat geverifieerde geautomatiseerde verzoeken waardevol maakt: ze geven je een betrouwbare manier om vertrouwen uit te breiden naar de clients die het verdienen, zonder dat uit te breiden naar iedereen die hun header kopieert.

Identiteitsbewijs, credentials en autorisatie

Drie lagen werken samen in elke applicatie die geautomatiseerde clients bedient:

  1. Identiteitsbewijs: welke client heeft dit verzoek ondertekend? Een geverifieerde handtekening beantwoordt dat.
  2. Credentials: welk account is verantwoordelijk? Je API key, token of sessie beantwoordt dat.
  3. Autorisatie: mag deze aanroeper dit doen? Je permissiemodel beantwoordt dat.

Proof of Actor versterkt de eerste laag en maakt die zichtbaar. Het geeft geen identity- of delegatiecredentials uit, en het vervangt je autorisatie niet. Door de lagen gescheiden te houden, kun je royaal zijn met geverifieerde agents op routes met laag risico en zorgvuldig op routes met grote impact.

Waar het past

Proof of Actor zit naast je gateway, authenticatie en rate limiting. Integraties draaien als server-side middleware, aan de edge, in je MCP server of via een generieke HTTP-integratie, hands-on geleverd met elk founding team. Als je verkeer vooral uit APIs en tools bestaat, laten de use cases voor APIs en MCP Servers de patronen zien die het belangrijkst zijn.

Begin in observatiemodus

Elke integratie begint in observatiemodus. Resultaten worden vastgelegd zonder te veranderen hoe je applicatie reageert, zodat je kunt zien hoeveel van je geautomatiseerde verkeer geverifieerd is, welke operators ondertekenen en waar het Unknown-percentage het hoogst is. Policies komen later, route voor route, wanneer het bewijs ze ondersteunt. How It Works loopt door de volledige flow.

Praktische details die verificatie betrouwbaar maken

Handtekeningcontrole is maar zo goed als de details eromheen. Een paar werkwijzen maken geverifieerde geautomatiseerde verzoeken betrouwbaar in productie.

Controleer versheid

RFC 9421 definieert created en expires signature parameters, en ondertekende verzoeken dragen die meestal. Weiger handtekeningen buiten een korte window, zodat een onderschept verzoek later niet opnieuw kan worden afgespeeld.

Cache sleutels verstandig

Het ophalen van de gepubliceerde sleutels van een operator bij elk verzoek voegt latency toe. Cache ze gedurende een redelijke periode en ververs wanneer een handtekening faalt met een onbekende key identifier, zodat key rotation geen valse fouten veroorzaakt.

Onderteken de juiste delen van het verzoek

Een handtekening die alleen een timestamp dekt, bewijst heel weinig. Controleer of de ondertekende componenten de method, het path en de host bevatten, zodat de handtekening koppelt aan het verzoek dat je applicatie daadwerkelijk heeft ontvangen.

Leg het bewijs vast

Bewaar de key identifier, de gepubliceerde identificatie en het resultaat bij elk geverifieerd verzoek. Wanneer er iets ongewoons gebeurt, kan je team precies zien welke client wat heeft ondertekend en wanneer.

Proof of Actor verwerkt deze controles als onderdeel van de Detect-stap en rapporteert de uitkomst als een basis die je policies kunnen lezen, zodat je applicatiecode eenvoudig blijft.

Sluit je aan bij het founding developer program

Proof of Actor zit in private beta. Geselecteerde founding development teams kunnen tot 12 maanden gratis toegang krijgen, binnen overeengekomen gebruikslimieten, met directe integratieondersteuning van onze engineers.

Als geautomatiseerde clients je applicatie bereiken en je de geverifieerde anders wilt behandelen, vraag vroege toegang aan. Vertel ons over je applicatie en de geautomatiseerde aanroepen die je ziet, en we laten je zien hoe Proof of Actor past.

Bronnen

VOOR ONTWIKKELAARS

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human, Human + AI, Agent of Unknown.
basis
Hoe sterk het bewijs is: verified, declared, inferred of unknown.
evidence
De signalen achter het resultaat, zodat je team kan zien waarom.

Begin in observatiemodus: leg resultaten vast naast je logs en wijzig niets totdat je een beleid kiest. Lees de Node.js-integratiegids

Veelgestelde vragen

Wat is een geverifieerd geautomatiseerd verzoek?

Het is een verzoek van een geautomatiseerde client waarvan de cryptografische handtekening valideert tegen een sleutel die is gepubliceerd voor een bekende identificatie, zoals het domein van de operator. Het laat zien welke client het verzoek heeft ondertekend.

Betekent een geverifieerde handtekening dat de agent geautoriseerd is?

Nee. Een handtekening koppelt een verzoek aan een sleutel en de gepubliceerde identificatie daarvan. Of die client een actie mag uitvoeren, is een aparte autorisatiebeslissing van je applicatie.

Wat met geautomatiseerde clients die hun verzoeken niet ondertekenen?

Proof of Actor classificeert ze nog steeds, met gebruik van declaratieve en afgeleide bewijzen waar beschikbaar, en rapporteert Unknown wanneer het bewijs niet sterk genoeg is. Elk resultaat vermeldt zijn basis.

Kan een user-agent string een client verifiëren?

Nee. User-agent strings zijn eenvoudig na te bootsen, dus ze gelden als een verklaring, niet als een verificatie. Cryptografische handtekeningen maken een verzoek verifieerbaar.

Hoe begin ik?

Vraag vroege toegang aan. Founding teams beginnen in observatiemodus en geselecteerde teams kunnen tot 12 maanden gratis krijgen binnen overeengekomen gebruikslimieten.

Weet wie uw app gebruikt.

Private beta voor een kleine groep founding developers.

Krijg vroege toegangBekijk prijzen

Eerst liever even praten? Spreek met de oprichters