Eén beleid voor iedereen is niet langer genoeg
De meeste applicaties zijn ontworpen rond één soort gebruiker: een persoon die door een interface klikt en is aangemeld bij een account. Toegangscontrole volgde die aanname. Als de sessie geldig is, gaat het request door. Als het geautomatiseerd lijkt, verschijnt er een CAPTCHA of een blokkering.
Dat model is aan het breken. Vandaag bedient dezelfde applicatie mensen, mensen die met AI-assistenten werken, en autonome agents die namens iemand handelen. Sommige agents zijn de eigen integraties van klanten. Sommige zijn AI-assistenten die documentatie ophalen. Sommige zijn crawlers. Een paar proberen je product te misbruiken. Eén ja-of-nee-regel kan hen niet allemaal goed bedienen.
Routering en toegangsbeleid voor AI-agents vervangen die ene regel door een set bewuste beslissingen: welke actors welke ervaring krijgen, op welke routes, onder welke voorwaarden. Proof of Actor geeft je applicatie het bewijs om die beslissingen te nemen, en laat de beslissingen zelf in jouw handen. Voor de ontwerpprincipes achter deze aanpak lees je app-beleid ontwerpen voor mensen en AI-agents, en bekijk je de use case voor SaaS-apps voor hoe beleid aansluit op echte productworkflows.
Hoe goed agentbeleid eruitziet
Een bruikbaar beleid is specifiek. Het benoemt een route of workflow, een actorclassificatie, de vereiste sterkte van het bewijs en de reactie. Bijvoorbeeld:
- Alleen-lezen catalogusroutes: sta geverifieerde agents toe en lever een gestructureerde response; sta gedeclareerde agents toe met de standaard rate limit.
- Acties die accounts wijzigen: behoud je bestaande herauthenticatie voor iedereen; voeg beoordeling toe wanneer de actor Unknown is en de actie grote impact heeft.
- Supportinzendingen: accepteer expliciet gemelde AI-ondersteunde inhoud en label die voor routering.
- Aanmelding: behoud bestaande controles; beslis nooit uitsluitend op basis van een afgeleid actorresultaat.
Elk van deze reacties op de actor zonder elke agent als misbruik te behandelen en zonder elke agent blind te vertrouwen. Die balans is precies het doel van agentbewuste toegang, en het blogbericht over app-beleid ontwerpen voor mensen en AI-agents werkt meer voorbeelden uit per route.
De vijf reacties
De Route-mogelijkheid van Proof of Actor is opgebouwd rond vijf reacties waaruit je beleid kan kiezen.
Toestaan
Laat het request normaal doorgaan. De meeste traffic, inclusief de meeste agent-traffic op openbare of laag-risico routes, moet gewoon worden toegestaan.
Aanpassen
Pas de ervaring aan de actor aan. Lever een gestructureerde API-response of een Markdown-versie van een pagina aan een geverifieerde agent in plaats van een interface die op een mens is gericht. De handleiding over AI-agents gestructureerde content serveren behandelt dit patroon.
Uitdagen
Vraag om iets sterkers: een nieuwe login, een extra credential, een bevestiging van de accounthouder. Gebruik uitdagingen op routes waar de kosten van een verkeerde beslissing hoog zijn.
Beoordelen
Laat de actie doorstromen naar een wachtrij in plaats van direct af te ronden, of markeer die zodat een mens het kan controleren. Beoordeling is nuttig waar blokkeren legitieme gebruikers zou schaden, maar ongecontroleerde afronding te riskant is.
Beperken
Pas een limiet op snelheid of volume toe die is afgestemd op de actor en de route, zodat geautomatiseerde callers een workflow die voor mensen is ontworpen niet kunnen overbelasten.
Waarom robots.txt geen toegangsbeleid is
Veel teams beginnen met robots.txt, en dat is een verstandige eerste aanwijzing voor crawlers. Het is geen toegangsbeleid voor agents. Beheerders van crawlers documenteren verschillend gedrag voor verschillende user agents: Anthropic geeft aan dat zijn bots robots.txt-directives respecteren (Anthropic crawler documentation), terwijl OpenAI opmerkt dat voor ChatGPT-User, die handelt wanneer een gebruiker ChatGPT een vraag stelt, robots.txt-regels mogelijk niet van toepassing zijn omdat de actie door een gebruiker is geïnitieerd (OpenAI crawler documentation). Robots.txt zegt ook niets over APIs, MCP-tools of ingelogde workflows.
Een toegangsbeleid moet worden uitgevoerd waar het request wordt afgehandeld, bewijs lezen zoals een signature die onder RFC 9421 wordt gecontroleerd, en per route een reactie kiezen. Voor MCP servers definieert de MCP authorization specification hoe clients toegangstokens verkrijgen via HTTP; actorbeleid voegt daar context bovenop toe, het vervangt dat niet.
Hoe Proof of Actor jouw beleid voedt
Elk request dat je integratie evalueert levert een actorresultaat op met vier onderdelen die je beleid kan lezen:
- Classificatie: Human, Human + AI, Agent of Unknown.
- Basis: Verified, Declared, Inferred of Unknown, zodat je beleid een gevalideerde signature anders kan behandelen dan een zelf gedeclareerde clientnaam.
- Bewijssamenvatting: een leesbare beschrijving van waarop het resultaat berust, nuttig voor logging en review.
- Context: welke integratie en welke route het resultaat heeft opgeleverd.
Omdat de basis expliciet is, kunnen je beleidsregels precies zijn. "Agents toestaan" wordt dan "geverifieerde agents toestaan op leesroutes, gedeclareerde agents rate-limiten, de Unknown-fallback toepassen op al het andere." De volledige stroom van request naar beslissing wordt beschreven op Hoe het werkt.
Fallbacks horen bij het beleid
Een beleid is alleen zo goed als het gedrag wanneer bewijs ontbreekt. Proof of Actor maakt die gevallen expliciet in plaats van ze te verbergen.
- Unknown: het bewijs ondersteunde geen vaststelling. Je beleid bepaalt wat Unknown op elke route betekent. Het wordt nooit omgezet naar Human en standaard nooit als kwaadwillig behandeld.
- Time-out: het resultaat kwam niet op tijd binnen. Je integratie past de fallback toe die je voor die route hebt gekozen.
- Ontbrekende signalen: een collector draaide niet of een header ontbrak. Het resultaat weerspiegelt dat, en je beleid behandelt het overeenkomstig.
Voor elke route bepaal je of je fail open of fail closed toepast. Fail open betekent dat het request doorgaat zoals het zonder Proof of Actor zou doen; fail closed betekent dat je bestaande sterkere controle wordt toegepast. Routes met laag risico vallen meestal open. Gevoelige acties vallen meestal closed. Je stelt dit per risiconiveau in, niet globaal.
Houd identiteit, credentials en autorisatie gescheiden
Beleidsregels voor agenttoegang liggen boven drie verschillende lagen, en ze uit elkaar houden voorkomt de meest schadelijke fouten.
- Identiteitsbewijs antwoordt wat voor soort actor er belt en wat dat aantoont. Proof of Actor levert dit.
- Credentials antwoorden welk account verantwoordelijk is. Je sessie, token of API key levert dit.
- Autorisatie antwoordt of deze caller deze actie mag uitvoeren. Je permissiemodel levert dit.
Een geverifieerde agentidentiteit betekent niet dat de agent geautoriseerd is, dat een persoon die bevoegdheid aan die agent heeft gedelegeerd, of dat de actie veilig is. Gebruik actorresultaten om te routeren en context toe te voegen. Gebruik je autorisatiemodel om toestemming te verlenen. De pagina over Detection & Limitations legt precies uit wat elk type bewijs kan vaststellen.
Uitrollen zonder iets te breken
De veiligste manier om toegangsbeleid voor agents in te voeren is gefaseerd.
- Observeren. Installeer Proof of Actor in observatiemodus. Voor je gebruikers verandert er niets; resultaten worden vastgelegd.
- Begrijpen. Bekijk welke actors welke routes gebruiken, het aandeel Unknown op elk van die routes en resultaten die afwijken van wat je al weet.
- Voorvertonen. Draai een beleid in preview en log wat het zou hebben gedaan zonder het af te dwingen.
- Beperkt handhaven. Schakel het beleid in op één route waar het bewijs het duidelijk ondersteunt. Volg de uitkomsten.
- Uitbreiden. Breid uit naar meer routes naarmate het vertrouwen groeit.
De handleiding over beleidsregels met actorbewustzijn veilig uitrollen loopt door elke fase heen, en gevoelige acties beschermen zonder agents te blokkeren behandelt de routes met hoge inzet.
Wat je team krijgt
Met Proof of Actor krijgt je team één integratie met drie mogelijkheden. Detect verzamelt actor-signalen en scheidt geverifieerde beweringen van inferenties. Understand toont actoranalytics, trends en het bewijs achter elk resultaat, waarbij Unknown zichtbaar blijft. Route laat je de beleidsregels op deze pagina schrijven en toepassen waar jij dat kiest. Tijdens de private beta worden routeringsbeleid samen met elk founding team ontworpen en draaien ze in je eigen applicatiecode, zodat je volledige controle behoudt.
Veelvoorkomende beleidsfouten om te vermijden
Teams die voor het eerst agenttoegang ontwerpen, maken vaak een handvol dezelfde fouten. Ze vermijden bespaart weken aan herwerk.
- Elke agent standaard blokkeren. Legitieme agents zoeken dan een omweg, vaak door de interface te scrapen die je voor mensen hebt gebouwd, wat lastiger te beschermen is dan een gestructureerd pad.
- Een gedeclareerde naam vertrouwen. Een client die zichzelf alleen benoemt, heeft een claim gedaan, geen bewijs geleverd. Behandel die zoals je een niet-geverifieerde caller zou behandelen.
- Eén fallback overal gebruiken. Unknown op een openbare prijspagina en Unknown bij een wachtwoordwijziging zijn verschillende situaties. Elke route heeft zijn eigen antwoord nodig.
- Over mensen beslissen op basis van een inferentie. Actorresultaten zijn context voor routing, geen oordeel over een individu. Laat ingrijpende beslissingen over aan je eigen controles en review.
- Observeren overslaan. Op dag één handhaven betekent dat je false positives ontdekt via klachten van klanten. Observeer eerst, en handhaaf daarna waar het bewijs duidelijk is.
Een korte review van het beleid met je security-, product- en supportleads vóór elke handhavingsstap vangt de meeste hiervan vroeg af.
Begin met het founding developer program
Proof of Actor bevindt zich in private beta. Geselecteerde founding development teams kunnen tot 12 maanden gratis toegang krijgen, binnen afgesproken gebruikslimieten, met directe ondersteuning van onze engineers terwijl je je eerste beleidsregels ontwerpt.
Als je bepaalt hoe je applicatie met AI-agents moet omgaan, vraag early access aan. Vertel ons welke routes het belangrijkst zijn en welke beslissingen je wilt nemen, en wij helpen je beleid bouwen dat past. Je kunt ook zien hoe dit werkt voor APIs en MCP servers.
Bronnen
- Crawlt Anthropic data van het web, en hoe kunnen site-eigenaren de crawler blokkeren?, Anthropic.
- Overzicht van OpenAI crawlers, OpenAI.
- RFC 9421: HTTP Message Signatures, IETF, februari 2024.
- MCP authorization, modelcontextprotocol.io.