UITLEG

Web Bot Auth voor productteams: wat ondertekende agentverzoeken betekenen voor je roadmap

AI-agents en crawlers hebben steeds vaker een manier nodig om te bewijzen wie ze zijn, zonder te vertrouwen op een User-Agent string die iedereen kan kopiëren. Het IETF Web Bot Auth-traject is de toonaangevende inspanning om dat te standaardiseren. Hier is een heldere uitleg voor productmanagers en engineeringleads: hoe het werkt, wat het aantoont, wat de status is per november 2026 en hoe je je erop voorbereidt.

Krijg vroege toegang Ontdek hoe het werkt

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

Jarenlang kwam de enige manier waarop een geautomatiseerde client een website kon vertellen wie het was neer op een naam in de User-Agent header en, voor een paar grote operators, een gepubliceerde lijst met IP-adressen of een reverse DNS-check. Namen zijn eenvoudig te kopiëren. Netwerklijsten dekken alleen de operators die ze onderhouden. Nu AI-agents in de hele webomgeving namens echte mensen gaan handelen, is die kloof een productprobleem geworden, niet alleen een beveiligingsprobleem.

Web Bot Auth is de toonaangevende poging om die kloof te dichten. Het geeft geautomatiseerde clients een manier om hun verzoeken te ondertekenen met een sleutel die ze beheren en publiceren, zodat een site de handtekening kan controleren in plaats van op een naam te vertrouwen. Deze uitleg is voor productmanagers en engineeringleads die moeten begrijpen wat het is, wat het verandert en wat het niet doet, zonder de specificaties van begin tot eind te lezen.

De korte versie

Wat het is: een IETF working group, webbotauth, en de aanpak die zij standaardiseert voor het authenticeren van geautomatiseerde HTTP-clients.
Hoe het werkt: de client ondertekent onderdelen van elk verzoek met HTTP Message Signatures (RFC 9421) en verwijst naar een directory met zijn publieke sleutels. De site haalt de sleutel op en verifieert de handtekening.
Wat het aantoont: welke sleutel het verzoek heeft ondertekend en dat de ondertekende onderdelen tijdens transport niet zijn gewijzigd.
Wat het niet aantoont: dat de agent gemachtigd is om te doen wat hij vraagt, dat hij namens een bepaalde gebruiker handelt of dat hij zich goed zal gedragen.
Status per november 2026: RFC 9421 is een gepubliceerde Proposed Standard. Het Web Bot Auth-protocoldocument is een working group Internet-Draft en nog geen RFC.
Wat je moet doen: plan om geldige handtekeningen als sterk bewijs te behandelen, blijf unsigned traffic afhandelen en houd autorisatiebeslissingen in je eigen code.

Wat het IETF Web Bot Auth-werk is

De IETF heeft de Web Bot Auth working group gecharterd om methoden te standaardiseren voor het cryptografisch authenticeren van geautomatiseerde clients en voor het geven van meer informatie aan websites over de operators erachter. Het charter richt zich op sites die vooral mensen bedienen, en noemt een brede reeks clients binnen de scope: crawlers, webarchivers, linkcheckers, AI-trainingscrawlers en AI-agents die namens eindgebruikers handelen.

Twee uitsluitingen in het charter zijn relevant voor productteams. Authenticatie van eindgebruikers valt buiten scope, dus dit is geen manier om een persoon in te loggen. Het volgen van botreputatie valt ook buiten scope, dus de standaard vertelt je wie een verzoek heeft ondertekend, niet of die operator betrouwbaar is.

Het charter noemt drie soorten deliverables:

Standards track-documenten over technieken om geautomatiseerde clients te authenticeren voor websites die voor mensen zijn gebouwd.
Standards track-documenten over het overbrengen van meer informatie over een verzoekende bot met behulp van een bestaande identifier zoals een domeinnaam of URL.
Best current practice- of informatieve documenten over operationele onderwerpen zoals key management, lifecycle en deployment.

Waar de documenten staan, per november 2026

Per november 2026 heeft de working group één aangenomen working group-document: draft-ietf-webbotauth-httpsig-protocol, met als titel "HTTP Message Signatures for automated traffic", in revisie 01, gedateerd 29 oktober 2026. Het is een Internet-Draft, wat betekent dat het werk in uitvoering is en nog kan veranderen. Het is geen RFC.

Er zijn ook meerdere individuele drafts aan de groep gekoppeld en in bespreking, waaronder voorstellen voor een registry en agent card-formaat, anonieme bot-authenticatie, een JSON-formaat voor het publiceren van IP-ranges van geautomatiseerde clients en een header voor ondertekende agentmetadata. Individuele drafts zijn voorstellen; geen daarvan is per deze datum door de groep aangenomen.

Het charter stelde mijlpalen vast voor 2026 om specificaties ter goedkeuring naar de IESG te sturen. Per november 2026 blijft het protocoldocument een working group draft. Je kunt de actuele status volgen op de IETF datatracker-pagina voor de working group en de protocol draft.

Hoe HTTP Message Signatures werken

Web Bot Auth bouwt voort op RFC 9421, HTTP Message Signatures, gepubliceerd in februari 2024 als Proposed Standard. RFC 9421 is een algemeen mechanisme: het definieert hoe geselecteerde delen van een HTTP-bericht worden ondertekend en hoe de handtekening in headers wordt opgenomen. Web Bot Auth profileert dit voor geautomatiseerde clients.

In eenvoudige termen werkt een ondertekend agentverzoek als volgt:

De operator maakt een sleutelpaar aan. De private key blijft geheim en de public key wordt gepubliceerd.
De client kiest wat wordt ondertekend. Het selecteert onderdelen van het verzoek, zoals de doelhost of URI en een aanmaaktijd. De huidige draft vereist dat de authority of de target URI wordt opgenomen, zodat een handtekening voor één site niet eenvoudig kan worden hergebruikt voor een andere site.
De client ondertekent en verstuurt. Het verzoek bevat een Signature-Input header waarin staat wat is ondertekend en met welke sleutel, en een Signature header met de handtekeningwaarde. De draft gebruikt een web-bot-auth tag en verwacht aanmaak- en vervaltijden voor elke handtekening.
De site verifieert. Die vindt de publieke sleutel, reconstrueert de ondertekende onderdelen uit het ontvangen verzoek en controleert de handtekening. Als de controle slaagt, is het verzoek ondertekend door de houder van die sleutel en zijn de gedekte delen niet gewijzigd.

De draft laat een site ook om een handtekening vragen. Een origin kan een Accept-Signature header sturen, meestal met een weigering, om aan te geven dat het ondertekende verzoeken wil.

Het idee van de key directory

Een handtekening is alleen bruikbaar als de site de juiste publieke sleutel kan vinden. Web Bot Auth lost dat op met een key directory.

In de huidige working group draft voegt de client een Signature-Agent header toe met een HTTPS URL. Die URL levert een directory met de publieke sleutels van de operator als een JSON Web Key Set. De site haalt de directory op, selecteert de sleutel die overeenkomt met de key identifier in de handtekening en verifieert. De draft definieert ook een well-known pad, /.well-known/http-message-signatures-directory, waar een operator zijn directory kan aanbieden.

Het nuttige idee voor productteams is dat de URL de identiteit wordt. Een agentoperator wordt geïdentificeerd door de plek waar hij zijn sleutels publiceert, waardoor de handtekening wordt gekoppeld aan een domein dat de operator beheert. Sleutelrotatie werkt door een nieuwe sleutel naast de oude te publiceren en daarna de oude te verwijderen.

Verifiërende sites moeten directories zorgvuldig afhandelen: cache ze volgens de normale HTTP-regels, stel limieten in voor omvang en timeouts, en vermijd ophalen vanaf private netwerkadressen. Dit zijn standaard engineeringaandachtspunten en een van de redenen waarom veel teams liever een component gebruiken dat de verificatie voor hen uitvoert.

Wat een geldige handtekening aantoont en wat niet

Dit is de belangrijkste sectie voor iedereen die productbeleid schrijft.

Een geldige handtekening toont aan:

Dat het verzoek is ondertekend door de houder van een specifieke private key.
Dat die sleutel gepubliceerd is op een directory-URL die de operator beheert.
Dat de ondertekende delen van het verzoek tijdens transport niet zijn gewijzigd en dat de handtekening binnen de geldigheidsperiode valt.

Een geldige handtekening toont niet aan:

Dat de agent gemachtigd is om de actie uit te voeren. Identificeerbaar zijn is nog geen toestemming. Zie agent authorization.
Dat de agent handelt voor een specifieke persoon, of binnen de bevoegdheid die die persoon heeft gegeven. Zie delegated authority.
Dat de operator betrouwbaar is of dat de agent zich goed zal gedragen. Reputatie valt expliciet buiten scope voor de working group.
Iets over verzoeken die niet zijn ondertekend. Voor unsigned traffic is nog steeds eigen afhandeling nodig.

Behandel een geldige handtekening als sterk bewijs van wie een verzoek heeft verzonden, en laat je eigen toegangscontrole vervolgens bepalen wat die afzender mag doen.

Wat productteams ermee zouden moeten doen

Je hoeft niet op een RFC te wachten om te plannen. Ondertekend agentverkeer is iets waar je je nu al op kunt voorbereiden, met de verwachting dat sommige details van de draft nog kunnen veranderen.

1. Meet voordat je beslist

Breng in kaart hoeveel van je verkeer geautomatiseerd is, welke routes agents gebruiken en hoeveel daarvan is ondertekend. Begin in observation mode zodat meten niets verandert voor je gebruikers.

2. Scheid bewijs van beleid

Leg vast wat het bewijs zegt, verified, declared, inferred of unknown, los van wat je besluit te doen. Dat houdt beleid leesbaar en maakt het mogelijk om het strakker of soepeler te maken zonder opnieuw te instrumenteren. De entry over evidence basis legt de vier niveaus uit.

3. Geef verified agents een beter pad

Waar het logisch is, bied verified agents gestructureerde content of een agentvriendelijke flow in plaats van pagina's die voor mensen zijn gebouwd. De handleiding over gestructureerde content aan AI-agents aanbieden behandelt de patronen.

4. Houd autorisatie in je eigen code

Gebruik de handtekening om te weten wie er vraagt. Gebruik je bestaande permissies, scopes en bevestigingen om te bepalen wat ze mogen doen. Acties met hoge impact kunnen nog steeds een menselijke bevestiging vereisen, ongeacht wie het verzoek heeft ondertekend. Zie gevoelige acties beschermen zonder agents te blokkeren.

5. Houd rekening met unsigned en Unknown verkeer

Ondersteuning voor ondertekenen verschilt per agent en tool, dus reken op enige tijd op een mix van ondertekende en niet-ondertekende verzoeken. Bepaal per route wat er gebeurt met declared, inferred en Unknown verkeer, in plaats van één regel voor de hele site te kiezen. De handleiding over Unknown traffic afhandelen loopt dit door.

Hoe Proof of Actor Web Bot Auth gebruikt

Proof of Actor vertelt je applicatie wie of wat er bij elke interactie handelt: Human, Human + AI, Agent of Unknown, en vermeldt de evidence basis. Web Bot Auth-handtekeningen zijn een van de sterkste bewijsbronnen.

Wanneer een agent zijn verzoek ondertekent met HTTP Message Signatures, controleert Proof of Actor de handtekening tegen de gepubliceerde sleutel van de operator. Als de controle slaagt, krijgt het resultaat een verified basis, samen met het bewijs dat je team kan beoordelen. Als een client zichzelf alleen in een header noemt, is het resultaat declared. Als de conclusie berust op gedrags- of contextsignalen, wordt het gelabeld als inferred. Als het bewijs niet genoeg is, is het resultaat Unknown.

Je applicatie bepaalt wat er met die context gebeurt. Beleid wordt per route, per actor class en per basis geschreven, met uitkomsten zoals allow, adapt, challenge, review en rate-limit. Er wordt standaard niets afgedwongen: je bekijkt een policy eerst in preview tegen echt verkeer en enforce je die vervolgens route voor route, in je eigen code.

Founding-teams kunnen bewijs verzamelen via Node.js middleware, Next.js, een edge-integratie, een browsercollector op goedgekeurde pagina's, de generieke HTTP API of een MCP server-integratie. Zie integraties, en de handleiding over ondertekende agentverzoeken verifiëren voor de praktische stappen.

Proof of Actor houdt zich aan dezelfde grens als de standaard: een geverifieerde handtekening vertelt je welke sleutel het verzoek heeft ondertekend, niet of de agent gemachtigd is. De autorisatie blijft bij jou. De pagina bewijs en beperkingen zet precies uiteen wat elk resultaat wel en niet kan ondersteunen.

Aan de slag

Proof of Actor zit 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 laat ons weten welke routes je verwacht dat ondertekende agents gebruiken en wat je ermee wilt doen.

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 Web Bot Auth?

Web Bot Auth is de naam van een IETF working group, webbotauth, en de aanpak die zij standaardiseert: geautomatiseerde clients ondertekenen HTTP-verzoeken met HTTP Message Signatures (RFC 9421) en publiceren hun publieke sleutels, zodat websites kunnen verifiëren welke operator een verzoek heeft verzonden.

Is Web Bot Auth een afgeronde standaard?

Nog niet. Per november 2026 is het belangrijkste protocoldocument, draft-ietf-webbotauth-httpsig-protocol, een working group Internet-Draft in revisie 01. RFC 9421, het handtekeningformaat waarop het voortbouwt, is een gepubliceerde Proposed Standard.

Betekent een geldige Web Bot Auth-handtekening dat de agent mag handelen?

Nee. Het bewijst welke sleutel het verzoek heeft ondertekend en dat de ondertekende onderdelen niet zijn gewijzigd. Of die agent gegevens mag lezen, een formulier mag indienen of namens een bepaalde gebruiker mag handelen, is een autorisatiebeslissing die je applicatie zelf nog steeds neemt.

Moeten productteams Web Bot Auth zelf implementeren?

Sites verifiëren handtekeningen; ze hoeven niets te ondertekenen tenzij ze zelf ook geautomatiseerde clients draaien. Verificatie betekent key directories ophalen, ze veilig cachen en handtekeningen controleren, wat een tool als Proof of Actor voor je kan doen.

Wat moeten we doen met agents die hun verzoeken niet ondertekenen?

Behandel ze op basis van het beschikbare bewijs: declared, inferred of Unknown. Reken op een mix van ondertekend en niet-ondertekend verkeer voor enige tijd, en stel per route een fallback in in plaats van een enkele regel voor de hele site.

Hoe gebruikt Proof of Actor Web Bot Auth?

Het controleert HTTP Message Signatures tegen de gepubliceerde sleutel en rapporteert, wanneer de controle slaagt, het resultaat met een verified basis. Je beleid kan verified agents vervolgens anders behandelen dan declared of Unknown verkeer.

Weet wie uw app gebruikt.

Private beta voor een kleine groep founding developers.

Krijg vroege toegang Bekijk prijzen

Eerst liever even praten? Spreek met de oprichters