Ga naar hoofdinhoud
HOE HET WERKT

Hoe Proof of Actor werkt.

Een evidence-first pad van binnenkomende interactie naar toepassingsbeslissing.

Vraag Early Access aanBekijk Detectie & Limieten
policy · example-app.test
  • /api/v1/catalogenforceAgentToestaan · gestructureerde API
  • /support/ticketsenforceMens + AIToestaan · labelen als door AI ondersteund
  • /account/*previewOnbekendBehoud bestaande controles
  • /api/v1/orderspreviewAgentSterkere referentie vereisen

Van interactie naar beslissing

  1. 01Applicatie-request of eventEen paginaweergave, een API-aanroep, een MCP tool call of een actie in de app.
  2. 02Signalen van de ondersteunde integratieAlleen wat die integratie in die context kan waarnemen.
  3. 03Normalisatie en classificatie van bewijsSignalen worden gecontroleerd, gelabeld op basis en gecombineerd.
  4. 04Actorresultaat met basis en onzekerheidMens, Mens + AI, Agent of Unknown, plus waarop het berust.
  5. 05Dashboard en analyticsTrends, routes en bewijs voor uw team om te beoordelen.
  6. 06De eigen beslissing van uw applicatieAlleen observeren, of een beleid toepassen dat je hebt gekozen.
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

Observation mode is de standaard

Het installeren van Proof of Actor blokkeert of wijzigt geen enkele request. Resultaten worden vastgelegd zodat uw team ze kan vergelijken met echte uitkomsten van de application, false positives kan beoordelen en kan beslissen of een policy passend is.

Soorten bewijs

Het beschikbare bewijs hangt af van de integratie en de context. De controles voor elke workflow worden tijdens onboarding met het team afgestemd, en signaalinternals blijven privé zodat ze moeilijker te imiteren zijn.

  • Requesthandtekeningen

    Cryptografische handtekeningen van geautomatiseerde clients die hun sleutels publiceren.

  • Verklaringen

    Een client die zichzelf als agent identificeert, of een melding van AI-ondersteuning binnen uw app.

  • Interactiesignalen

    Signalen van een goedgekeurde browsercollector, op de pagina's waar deze draait.

  • Requestcontext

    Headers en protocoldetails beschikbaar voor een server-side integratie.

Agentidentiteit is geen autorisatie

Een ondertekend request van een geautomatiseerde client kan laten zien dat het request is ondertekend met een sleutel die is gekoppeld aan een gepubliceerde identificatie, zoals het domein van een operator. Dat is bruikbaar bewijs over welke client het heeft verzonden.

Het laat niet zien wie de agent heeft geïnstrueerd, of een persoon er toestemming aan heeft gedelegeerd, de juridische identiteit erachter, of de actie veilig is. Dat zijn afzonderlijke vragen die uw toepassing beantwoordt met zijn eigen authenticatie, autorisatie en beleid.

drie afzonderlijke vragen
  • Wie belt er?Proof of Actor: handtekening, declaratie of inferentie
  • Welke credential?Uw API key, OAuth token of sessie
  • Wat kan het doen?Uw autorisatie en beleid

Hoe routeringsbeslissingen hierin passen

Je applicatie roept Proof of Actor aan, ontvangt een resultaat en past zijn eigen regels toe. Je kiest per route en per risiconiveau of de integratie fail open is (de aanvraag gaat verder zoals zonder Proof of Actor) of fail closed is (je bestaande sterkere controle wordt toegepast).

  • API-time-out

    Als een resultaat niet op tijd beschikbaar is, gebruikt uw integratie de terugvaloptie die u voor die route hebt gekozen. Een time-out wordt nooit een Human-resultaat.

  • Ontbrekende telemetrie

    Als de browsercollector niet heeft gedraaid of een signaal ontbreekt, weerspiegelt het resultaat dat. Ontbrekend bewijs beperkt wat kan worden gezegd; het wordt niet als verdacht behandeld.

  • Onbekende classificaties

    Unknown is een normale uitkomst. Uw beleid bepaalt wat Unknown betekent per route, bijvoorbeeld: openbare pagina's toestaan, bestaande controles op accountwijzigingen behouden.

  • Verouderd bewijs

    Bewijs heeft een tijd en een scope. Een resultaat uit eerder in een sessie mag niet opnieuw worden gebruikt voor een latere, gevoeligere actie zonder een nieuwe controle.

De beta-integratieworkflow

  1. 01AanvragenVertel ons over de app en de interactie die je wilt begrijpen.
  2. 02AfbakenenStem de integratie, de routes, gebruikslimieten en gegevensverwerking af.
  3. 03Integreren in observatiemodusGeen verandering in hoe je app reageert.
  4. 04ValiderenVergelijk resultaten met ground truth die je kent: dekking, onbekend percentage, false positives, latentie.
  5. 05BeslisSchakel een beleid alleen in waar het bewijs dat ondersteunt.

Wat we meten met founding teams

Dekking, het onbekende percentage, false positives ten opzichte van bekende uitkomsten en extra latentie, in elke ondersteunde context.

Begin in observatiemodus.

Vraag aan om deel te nemen aan het founding developer program.

Vraag Early Access aanBekijk Detectie & Limieten

Eerst liever even praten? Spreek met de oprichters