મુખ્ય સામગ્રી પર જાઓ
HOW IT WORKS

Proof of Actor કેવી રીતે કામ કરે છે.

આવતી 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સમર્થિત ઇન્ટિગ્રેશનમાંથી મળતા સિગ્નલોતે integration તે સંદર્ભમાં માત્ર જે observe કરી શકે તે જ.
  3. 03Evidence normalization અને classificationસિગ્નલોની તપાસ થાય છે, આધાર મુજબ લેબલ થાય છે અને જોડવામાં આવે છે.
  4. 04આધાર અને અનિશ્ચિતતા સાથેનું એક્ટર પરિણામમાનવ, માનવ + AI, Agent અથવા Unknown, અને તે કયા આધાર પર છે તે.
  5. 05Dashboard અને analyticsતમારી teamની સમીક્ષા માટે trends, routes અને evidence.
  6. 06તમારી application's પોતાની 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
પરિણામ પાછળના signals, જેથી તમારી team કારણ જોઈ શકે.

observation mode માં શરૂ કરો: પરિણામોને તમારા logsની બાજુમાં નોંધો અને તમે policy પસંદ કરો ત્યાં સુધી કંઈ બદલશો નહીં. Node.js integration guide વાંચો

Observation mode મૂળભૂત છે

Proof of Actor ઇન્સ્ટોલ કરવાથી કોઈપણ request અટકતી નથી કે બદલાતી નથી. પરિણામો નોંધવામાં આવે છે જેથી તમારી ટીમ તેમને વાસ્તવિક application પરિણામો સાથે સરખાવી શકે, ખોટા positive ની સમીક્ષા કરી શકે, અને કોઈ policy યોગ્ય છે કે નહીં તે નક્કી કરી શકે.

Evidence ના પ્રકારો

ઉપલબ્ધ evidence integration અને context પર આધાર રાખે છે. દરેક workflow માટેના checks onboarding દરમિયાન ટીમ સાથે સહમત કરવામાં આવે છે, અને signal internals private રહે છે જેથી તેમની નકલ કરવી વધુ મુશ્કેલ બને.

  • request signatures

    જે automated clients તેમની keys પ્રકાશિત કરે છે તેમના cryptographic signatures.

  • ઘોષણાઓ

    પોતાને agent તરીકે ઓળખાવતો client, અથવા તમારા app અંદર AI-assistance disclosure.

  • interaction signals

    મંજૂર browser collectorમાંથી મળતા સિગ્નલો, જ્યાં તે ચાલે છે તે પેજો પર.

  • request context

    server-side integration માટે ઉપલબ્ધ headers અને protocol વિગતો.

Agent identity authorization નથી

automated client તરફથી આવેલી signed request બતાવી શકે છે કે request published identifier, જેમ કે operatorના domain, સાથે સંકળાયેલી key વડે signed હતી. એ કયો client એ મોકલ્યો તેની બાબતમાં ઉપયોગી evidence છે.

તે agent ને કોણે સૂચના આપી, કોઈ વ્યક્તિએ તેને permission સોંપી કે નહીં, તેની પાછળની legal identity શું છે, અથવા આ ક્રિયા સુરક્ષિત છે કે નહીં તે બતાવતું નથી. આ અલગ પ્રશ્નો છે, જેમના જવાબ તમારા application પોતાની authentication, authorization અને policy વડે આપે છે.

ત્રણ અલગ પ્રશ્નો
  • કોણ call કરી રહ્યું છે?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 થાય છે કે નહીં (તમારી existing વધુ મજબૂત check લાગુ પડે છે).

  • API સમયસમાપ્તિ

    જો પરિણામ સમયસર ઉપલબ્ધ ન હોય, તો તમારી integration તે route માટે તમે પસંદ કરેલો fallback વાપરે છે. timeout ક્યારેય Human પરિણામ બનતું નથી.

  • telemetry ગુમ છે

    જો browser collector ચાલ્યો ન હોય અથવા કોઈ signal ગેરહાજર હોય, તો પરિણામ તે દર્શાવે છે. ગેરહાજર પુરાવો શું કહી શકાય તેને મર્યાદિત કરે છે; તેને શંકાસ્પદ ગણવામાં આવતું નથી.

  • અજાણ classifications

    Unknown એક સામાન્ય પરિણામ છે. તમારી policy દરેક route માટે Unknownનો અર્થ શું છે તે નક્કી કરે છે, ઉદાહરણ તરીકે: public pagesને allow કરો, account changes પર existing checks જાળવો.

  • જૂનું evidence

    Evidenceનો સમય અને scope હોય છે. sessionની શરૂઆતના resultને પછીની, વધુ સંવેદનશીલ action માટે fresh check વિના ફરી વાપરવું જોઈએ નહીં.

beta integration workflow

  1. 01અરજી કરોapp અને તમે જે interaction સમજવા માંગો છો તેના વિશે જણાવો.
  2. 02વ્યાપintegration, routes, usage limits અને data handling પર સહમતિ આપો.
  3. 03નિરીક્ષણ મોડમાં એકીકરણ કરોતમારી app કેવી રીતે respond કરે છે તેમાં કોઈ ફેરફાર નથી.
  4. 04માન્ય કરોતમને જાણીતી ground truth સાથે પરિણામોની તુલના કરો: coverage, unknown rate, false positives, latency.
  5. 05નિર્ણય લોજ્યાં evidence તેને સમર્થન આપે ત્યાં જ policy enable કરો.

Founding teams સાથે અમે શું માપીએ છીએ

દરેક supported context માં coverage, unknown rate, known outcomes સામે false positives, અને વધારેલ latency.

observation mode માં શરૂ કરો.

Founding developer program માં જોડાવા માટે અરજી કરો.

Early Access માટે અરજી કરોDetection અને Limits જુઓ

પહેલાં વાત કરવી પસંદ કરો છો? સ્થાપકો સાથે વાત કરો