मुख्य सामग्री पर जाएं
यह कैसे काम करता है

Proof of Actor कैसे काम करता है।

incoming interaction से application decision तक evidence-first path।

Early Access के लिए Apply करेंDetection & Limits देखें
policy · example-app.test
  • /api/v1/catalogenforceएजेंटअनुमति दें · संरचित API
  • /support/ticketsenforceइंसान + AIAllow · AI-assisted label करें
  • /account/*previewअज्ञातमौजूदा checks बनाए रखें
  • /api/v1/orderspreviewएजेंटअधिक मजबूत credential आवश्यक करें

interaction से decision तक

  1. 01Application request या eventएक page view, एक API call, एक MCP tool call या एक in-app action।
  2. 02supported integration से signalsसिर्फ वही जो वह integration उस context में observe कर सकता है।
  3. 03Evidence normalization और classificationSignals को check किया जाता है, basis के अनुसार label किया जाता है, और जोड़ा जाता है।
  4. 04basis और uncertainty के साथ Actor resultHuman, Human + AI, Agent या Unknown, साथ में यह किस आधार पर है।
  5. 05Dashboard और analyticsआपकी team के review के लिए trends, routes और evidence।
  6. 06आपके application का अपना decisionसिर्फ observe करें, या अपनी चुनी हुई 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 के पास record करें और जब तक आप कोई policy न चुनें, कुछ न बदलें। Node.js integration guide पढ़ें

Observation mode डिफ़ॉल्ट है

Proof of Actor install करने से कोई request block या बदलती नहीं है। Results record किए जाते हैं ताकि आपकी team उन्हें real application outcomes से compare कर सके, false positives की समीक्षा कर सके, और तय कर सके कि कोई policy उपयुक्त है या नहीं।

evidence के प्रकार

उपलब्ध evidence integration और context पर निर्भर करता है। प्रत्येक workflow के checks onboarding के दौरान टीम के साथ तय किए जाते हैं, और signal internals private रहते हैं ताकि उनकी नकल करना कठिन हो।

  • request signatures

    उन automated clients से cryptographic signatures जो अपनी keys publish करते हैं।

  • घोषणाएँ

    कोई client खुद को agent बताता है, या आपके app के भीतर AI-assistance disclosure होता है।

  • इंटरैक्शन संकेत

    एक approved browser collector से signals, उन pages पर जहां यह चलता है।

  • request context

    server-side integration के लिए उपलब्ध headers और protocol details।

Agent identity authorization नहीं है

एक automated client से आया signed request दिखा सकता है कि request को एक published identifier, जैसे operator's domain, से जुड़े key के साथ sign किया गया था। यह इस बारे में उपयोगी evidence है कि किस client ने इसे भेजा।

यह नहीं दिखाता कि agent को किसने निर्देश दिया, क्या किसी व्यक्ति ने उसे permission delegate की, उसके पीछे की कानूनी पहचान क्या है, या action सुरक्षित है या नहीं। ये अलग प्रश्न हैं, जिनका उत्तर आपका application अपनी authentication, authorization और policy से देता है।

तीन अलग-अलग प्रश्न
  • कौन call कर रहा है?Proof of Actor: signature, declaration या inference
  • कौन सी credential?आपकी API key, OAuth token या session
  • यह क्या कर सकता है?आपका authorization और policy

routing decisions कैसे fit होते हैं

आपकी application Proof of Actor को call करती है, एक result प्राप्त करती है, और अपने नियम लागू करती है। आप प्रत्येक route और risk tier के लिए चुनते हैं कि integration fails open हो (request वैसे ही आगे बढ़े जैसे वह Proof of Actor के बिना बढ़ती) या fails closed हो (आपका मौजूदा अधिक मजबूत check लागू हो)।

  • API समय-सीमा समाप्त

    अगर कोई result समय पर उपलब्ध नहीं होता, तो आपकी integration उस route के लिए आपके चुने हुए fallback का उपयोग करती है। timeout कभी भी Human result नहीं बनता।

  • Telemetry missing

    अगर browser collector नहीं चला या कोई signal अनुपस्थित है, तो result उसी को दर्शाता है। missing evidence यह सीमित करता है कि क्या कहा जा सकता है; इसे suspicious नहीं माना जाता।

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

    Unknown एक सामान्य outcome है। आपकी policy तय करती है कि हर route के लिए Unknown का क्या मतलब है, उदाहरण के लिए: public pages को allow करें, account changes पर existing checks बनाए रखें।

  • पुराना evidence

    Evidence का एक समय और एक scope होता है। session के पहले के result को बाद की, अधिक sensitive action के लिए fresh check के बिना reuse नहीं करना चाहिए।

beta integration workflow

  1. 01Apply करेंहमें app और उस interaction के बारे में बताएं जिसे आप समझना चाहते हैं।
  2. 02दायराintegration, routes, usage limits और data handling पर सहमति बनाएं।
  3. 03Observation mode में इंटीग्रेट करेंआपके app के response में कोई बदलाव नहीं।
  4. 04मान्य करेंआपके ज्ञात ground truth के साथ results की तुलना करें: coverage, unknown rate, false positives, latency।
  5. 05निर्णय लेंकेवल वहीं policy enable करें जहाँ evidence उसका समर्थन करता है।

हम founding teams के साथ क्या मापते हैं

प्रत्येक supported context में coverage, unknown rate, known outcomes के मुकाबले false positives, और अतिरिक्त latency।

observation mode में शुरू करें।

founding developer program में शामिल होने के लिए आवेदन करें।

Early Access के लिए Apply करेंDetection & Limits देखें

क्या पहले बात करना पसंद करेंगे? founders से बात करें