मुख्य सामग्री पर जाएं
APIS

समझें कि आपका API कौन call कर रहा है।

हर API request में actor context जोड़ें: कौन सा client call कर रहा है, evidence कितना मजबूत है, और आपका API इस पर क्या करे, रूट के अनुसार।

Early Access प्राप्त करेंयह कैसे काम करता है, देखें
example-app.test · actor परिणाम

POST /api/v1/orders

एजेंटbasis: inferred

प्रमाण

API-key traffic जिसमें कोई browser context नहीं है और automated request pattern है

आपकी policy: Order बनाने से पहले stronger credential मांगें

API key identity नहीं है, और identity permission नहीं है।

अधिकांश API traffic एक ऐसे credential के साथ आता है जो बताता है कि कौन सा account pay कर रहा है, यह नहीं कि कौन सा client call कर रहा है या किसने उसे निर्देश दिया। कुछ clients अपने requests sign करते हैं, कई सिर्फ एक name declare करते हैं, और कई कुछ भी नहीं कहते।

Proof of Actor उन तीन सवालों को अलग करता है जिनका जवाब हर API को देना होता है, ताकि प्रत्येक को सही evidence और सही control मिले।

तीन अलग-अलग प्रश्न
  • कौन call कर रहा है?अभिनेता पहचान: हस्ताक्षर, घोषणा या अनुमान
  • कौन सी credential?आपकी API key, OAuth token या session
  • यह क्या कर सकता है?आपका authorization और policy

Proof of Actor पहले का जवाब देता है। आपका stack बाकी दो रखता है।

API teams actor context का क्या उपयोग करते हैं

  • हस्ताक्षरित clients को पहचानें

    Request signatures को published keys के against जांचें और देखें कि request किस operator से संबंधित है।

  • declarations को declarations ही मानें

    स्व-घोषित client names दर्ज करें, और उन्हें verified identity से अलग रखें।

  • प्रति route policies

    Low-impact reads को freely allow करें और writes तथा high-impact endpoints पर अधिक जानकारी मांगें।

  • हर caller देखें

    समझें कि कौन-से clients कौन-से endpoints का उपयोग करते हैं, जिनमें unknown भी शामिल हैं।

  • credentials अलग रखें

    API keys और OAuth अभी भी access तय करते हैं। Actor context बताता है कि call कौन कर रहा है।

  • Unknown के लिए plan

    जब कोई caller usable evidence नहीं देता, तो प्रत्येक route के लिए तय करें कि क्या होगा।

01 · Detect

हर request से evidence।

सर्वर, edge और HTTP API integrations request signatures, घोषित client details और request context पढ़ते हैं, और हर एक को उसके basis के साथ label करते हैं।

  • प्रकाशित keys के विरुद्ध सत्यापित HTTP message signatures।
  • Declared client names, declarations के रूप में recorded।
  • अपने server, gateway या edge से request context प्राप्त करें।
सिग्नल · स्रोत के अनुसार अंतिम अनुरोध
  • request signaturevalid · sample-crawler.exampleverified
  • क्लाइंट घोषणा"research-assistant/2.1"declared
  • ब्राउज़र इंटरैक्शनpointer + keyboard eventsinferred
  • कोई supported signals नहींroute not instrumentedunknown

02 · समझें

जानें कौन कौन सा endpoint उपयोग करता है।

हर route पर actor mix देखें, कौन से operators आपको सबसे अधिक call करते हैं, और unknown callers कहाँ केंद्रित हैं।

  • Route और operator के अनुसार callers।
  • हर classification के पीछे का evidence।
  • प्रति endpoint Unknown rate।
route के अनुसार traffic · 7 days
  • /dashboardअज्ञात 7%
  • /api/v1/catalogअज्ञात 15%
  • /support/ticketsअज्ञात 8%
  • /signupअज्ञात 21%
इंसानइंसान + AIएजेंटअज्ञात

03 · रूट

Impact के अनुरूप controls।

route-level policies लिखें: verified agents के लिए structured responses, declared clients के लिए standard limits, और high-impact actions के लिए stronger credentials।

  • route, class और basis के अनुसार policies।
  • जब ज़रूरत हो, stronger credentials पर जाएं।
  • Observe करें, preview करें, फिर enforce करें।
policy · example-app.test
  • /api/v1/catalogenforceएजेंटअनुमति दें · संरचित API
  • /support/ticketsenforceइंसान + AIAllow · AI-assisted label करें
  • /account/*previewअज्ञातमौजूदा checks बनाए रखें
  • /api/v1/orderspreviewएजेंटअधिक मजबूत credential आवश्यक करें

उदाहरण निर्णय

request से result, फिर आपके decision तक।

  • एक Verified agent आपका catalog पढ़ता है

    अनुरोध

    GET /api/v1/catalog

    परिणाम

    एजेंटbasis: verified

    आपका निर्णय

    Agent rate limit और structured response के साथ allow करें।

  • एक automated client order देता है

    अनुरोध

    POST /api/v1/orders

    परिणाम

    एजेंटbasis: inferred

    आपका निर्णय

    Order बनाने से पहले app का stronger credential मांगें।

  • बिना evidence वाला client

    अनुरोध

    GET /api/v1/catalog

    परिणाम

    अज्ञातbasis: unknown

    आपका निर्णय

    Read-only route: default rate limit के साथ allow करें।

जोखिम के बिना rollout करें

टीमें observation mode में शुरू करती हैं और route दर route आगे बढ़ती हैं।

  1. 01

    हर route observe करें

    अपने API के सामने middleware या HTTP API जोड़ें। Signatures, declarations और Unknown callers हर route के लिए दर्ज किए जाते हैं।

  2. 02

    route policies preview करें

    देखें कि real traffic पर लागू होने से पहले agent rate limits या step-up credentials क्या करते।

  3. 03

    प्रभाव के आधार पर लागू करें

    reads को खुला रखें, writes को सख्त करें, और access की जिम्मेदारी API keys और OAuth के पास रहने दें।

आपके stack के साथ काम करता है

  • संस्थापक टीमें

    वेब सर्वर मिडलवेयर (Node.js)

    Server-side

    server-rendered apps और APIs के लिए request-level signals।

  • संस्थापक टीमें

    Next.js

    server-side और edge

    page और API routes के लिए middleware।

  • संस्थापक टीमें

    ब्राउज़र स्क्रिप्ट

    केवल browser signals

    browser sessions से interaction signals, server-side integration के साथ।

  • संस्थापक टीमें

    Cloudflare और edge runtimes

    Edge

    Requests आपके origin तक पहुंचने से पहले edge पर signals।

  • संस्थापक टीमें

    सामान्य HTTP API

    कोई भी stack

    request context को API पर भेजें और basis सहित result प्राप्त करें।

  • संस्थापक टीमें

    MCP सर्वर

    MCP

    MCP tool calls के लिए Actor context.

  • रोडमैप

    WordPress

    plugin

    WordPress sites के लिए plugin।

  • रोडमैप

    नेेटिव मोबाइल

    iOS और Android

    Native iOS और Android SDKs।

Integrations हर founding team के साथ onboarding के दौरान hands-on तरीके से दी जाती हैं। अलग stack इस्तेमाल कर रहे हैं? आवेदन करते समय बताइए।

और जानें

Detection & Limitations पढ़ें

अक्सर पूछे जाने वाले प्रश्न

क्या clients को अपनी requests sign करनी होंगी?

नहीं। signed requests सबसे मजबूत evidence देते हैं, लेकिन Proof of Actor declarations और inferences भी रिकॉर्ड करता है, हर एक को उसके basis के साथ label करता है, और जब पर्याप्त न हो तो Unknown report करता है।

क्या valid signature का मतलब है कि client को act करने की अनुमति है?

नहीं। यह दिखाता है कि request एक ऐसे key से signed थी जो एक published identifier से जुड़ा है। वह operator क्या कर सकता है, यह आपके authorization और policy से तय होता है।

क्या यह API keys या OAuth को replace करता है?

नहीं। Credentials अब भी access नियंत्रित करते हैं। Proof of Actor यह जोड़ता है कि कौन या क्या call कर रहा है, ताकि आप उसके ऊपर बेहतर policies लागू कर सकें।

क्या हम हर endpoint के लिए अलग rules set कर सकते हैं?

हाँ। Policies per route लिखी जाती हैं, इसलिए read-only endpoints और high-impact writes को अलग तरह से treat किया जा सकता है।

इसकी लागत क्या है?

चुनी गई founding developer teams को agreed usage limits के भीतर up to 12 months free मिल सकते हैं।

जानें कि आपकी API कौन call कर रहा है।

Proof of Actor founding developer program में शामिल हों।

Early Access प्राप्त करेंडेवलपर हब

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