मुख्य सामग्रीकडे जा
ते कसे कार्य करते

Proof of Actor कसे कार्य करते.

incoming interaction पासून application decision पर्यंतचा evidence-first मार्ग.

Early Access साठी अर्ज कराDetection आणि Limits पहा
policy · example-app.test
  • /api/v1/catalogenforceएजंटपरवानगी द्या · structured API
  • /support/ticketsenforceमाणूस + AIपरवानगी द्या · AI-assisted म्हणून label करा
  • /account/*previewअज्ञातअस्तित्वातील checks ठेवा
  • /api/v1/orderspreviewएजंटअधिक मजबूत credential आवश्यक ठेवा

interaction पासून निर्णयापर्यंत

  1. 01Application request किंवा eventएक page view, एक API call, एक MCP tool call किंवा in-app action.
  2. 02समर्थित एकत्रीकरणातून signalsत्या context मध्ये ते integration जेवढे observe करू शकते तेवढेच.
  3. 03पुरावा सामान्यीकरण आणि वर्गीकरणSignals तपासले जातात, आधारानुसार लेबल केले जातात आणि एकत्र केले जातात.
  4. 04basis आणि uncertainty सह अॅक्टर निकालHuman, Human + AI, Agent किंवा Unknown, तसेच ते कशावर आधारलेले आहे.
  5. 05dashboard आणि analyticsतुमच्या टीमने review करण्यासाठी trends, routes आणि evidence.
  6. 06तुमच्या application चा स्वतःचा निर्णयफक्त निरीक्षण करा, किंवा तुम्ही निवडलेली policy लागू करा.
विकसकांसाठी

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 किंवा Unknown.
basis
पुरावा किती मजबूत आहे: Verified, Declared, Inferred किंवा Unknown.
evidence
result मागचे signals, जेणेकरून तुमची team कारण पाहू शकेल.

observation mode मध्ये सुरुवात करा: results तुमच्या logs च्या शेजारी नोंदवा आणि तुम्ही policy निवडेपर्यंत काहीही बदलू नका. Node.js integration guide वाचा

Observation mode हे default आहे

Proof of Actor स्थापित केल्याने कोणतीही request block होत नाही किंवा बदलत नाही. परिणाम नोंदवले जातात, जेणेकरून तुमची team त्यांची वास्तविक application outcomes सोबत तुलना करू शकेल, false positives चे पुनरावलोकन करू शकेल, आणि कोणतीही policy योग्य आहे का ते ठरवू शकेल.

evidence चे प्रकार

उपलब्ध evidence integration आणि context वर अवलंबून असते. प्रत्येक workflow साठीची checks onboarding दरम्यान टीमसोबत मान्य केली जातात, आणि signal internals private राहतात त्यामुळे त्यांची नक्कल करणे कठीण होते.

  • request signatures

    आपली keys प्रकाशित करणाऱ्या automated clients कडून cryptographic signatures.

  • घोषणा

    स्वतःला agent म्हणून नाव देणारा client, किंवा तुमच्या app मधील AI-assistance उघडकरण.

  • परस्परसंवाद संकेत

    मान्यताप्राप्त browser collector कडून signals, ज्या pages वर तो चालतो तिथे.

  • request context

    सर्व्हर-साइड एकत्रीकरणासाठी उपलब्ध हेडर्स आणि प्रोटोकॉल तपशील.

Agent identity हे authorization नाही

automated client कडून आलेला signed request दर्शवू शकतो की request एका published identifier शी संबंधित key ने signed होती, जसे operator's domain. कोणत्या client ने ती पाठवली याबद्दल तो उपयुक्त evidence आहे.

यातून agent ला कोणी निर्देश दिले, एखाद्या व्यक्तीने त्याला परवानगी सोपवली का, त्यामागील कायदेशीर ओळख काय आहे, किंवा कृती सुरक्षित आहे का, हे दिसत नाही. हे वेगळे प्रश्न आहेत ज्यांची उत्तरे तुमचे application स्वतःच्या authentication, authorization आणि policy द्वारे देते.

तीन वेगळे प्रश्न
  • कोण कॉल करत आहे?Proof of Actor: signature, declaration किंवा inference
  • कोणते credential?तुमचा API key, OAuth token किंवा session
  • ते काय करू शकते?तुमचे authorization आणि policy

routing निर्णय कसे बसतात

तुमचे application Proof of Actor ला call करते, result प्राप्त करते, आणि स्वतःचे नियम लागू करते. तुम्ही प्रत्येक route आणि प्रत्येक risk tier साठी integration fails open (request Proof of Actor नसल्याप्रमाणे पुढे जाते) की fails closed (तुमची विद्यमान अधिक मजबूत check लागू होते) हे निवडता.

  • API वेळ संपणे

    जर परिणाम वेळेत उपलब्ध नसेल, तर तुमचे एकत्रीकरण त्या रूटसाठी तुम्ही निवडलेला फॉलबॅक वापरते. टाइमआउट कधीही Human परिणाम बनत नाही.

  • telemetry गायब आहे

    ब्राउझर कलेक्टर चालू झाला नाही किंवा एखादा सिग्नल अनुपस्थित असेल, तर परिणाम तेच दर्शवतो. अनुपस्थित पुरावा काय म्हणता येईल ते कमी करतो; त्याला संशयास्पद मानले जात नाही.

  • अज्ञात वर्गीकरणे

    Unknown हा एक सामान्य outcome आहे. तुमची policy प्रत्येक route साठी Unknown चा अर्थ काय ते ठरवते, उदाहरणार्थ: public pages allow करा, account changes वर existing checks ठेवा.

  • जुना पुरावा

    पुराव्याला वेळ आणि scope असतो. session च्या सुरुवातीला मिळालेला result नंतरच्या, अधिक संवेदनशील कृतीसाठी fresh check शिवाय पुन्हा वापरू नये.

beta integration workflow

  1. 01अर्ज कराapp आणि तुम्हाला समजून घ्यायचा interaction याबद्दल सांगा.
  2. 02व्याप्तीintegration, routes, usage limits आणि data handling यावर सहमती द्या.
  3. 03निरीक्षण मोडमध्ये एकत्रित करातुमचा app कसा प्रतिसाद देतो यात बदल नाही.
  4. 04पडताळातुम्हाला माहीत असलेल्या ground truth सोबत निकालांची तुलना करा: coverage, unknown rate, false positives, latency.
  5. 05निर्णय घ्यापुरावा जिथे त्याला पाठिंबा देतो तिथेच policy सक्षम करा.

founding teams सोबत आम्ही काय मोजतो

प्रत्येक समर्थित context मध्ये coverage, unknown rate, ज्ञात निकालांच्या तुलनेत false positives, आणि अतिरिक्त latency.

observation mode मध्ये प्रारंभ करा.

founding developer program मध्ये सामील होण्यासाठी अर्ज करा.

Early Access साठी अर्ज कराDetection आणि Limits पहा

आधी बोलणे पसंत आहे? founders शी बोला