ప్రధాన కంటెంట్‌కు దాటవేయండి
ఇది ఎలా పనిచేస్తుంది

Proof of Actor ఎలా పనిచేస్తుంది.

incoming interaction నుంచి application నిర్ణయం వరకు evidence-first path.

Early Access కోసం Apply చేయండిDetection & Limits చూడండి
policy · example-app.test
  • /api/v1/catalogenforceఏజెంట్అనుమతించు · structured API
  • /support/ticketsenforceమనిషి + AIఅనుమతించు · AI-assisted గా label చేయండి
  • /account/*previewతెలియదుప్రస్తుత checks ను అలాగే ఉంచండి
  • /api/v1/orderspreviewఏజెంట్మరింత బలమైన credential ను require చేయండి

interaction నుండి నిర్ణయం వరకు

  1. 01Application request లేదా eventఒక page view, ఒక API call, ఒక MCP tool call లేదా ఒక in-app action.
  2. 02మద్దతు ఉన్న integration నుండి వచ్చిన signalsఆ integration ఆ context లో observe చేయగలిగినదే.
  3. 03Evidence normalization మరియు classificationSignalsను తనిఖీ చేసి, ఆధారం ప్రకారం లేబుల్ చేసి, కలుపుతారు.
  4. 04ఆధారం మరియు అనిశ్చితితో Actor ఫలితంHuman, Human + AI, Agent లేదా Unknown, అలాగే అది ఏమి ఆధారంగా ఉందో.
  5. 05Dashboard మరియు analyticsమీ team review చేయడానికి trends, routes మరియు evidence.
  6. 06మీ application's own decisionకేవలం పరిశీలించండి, లేదా మీరు ఎంచుకున్న 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
evidence ఎంత బలంగా ఉందో: verified, declared, inferred లేదా unknown.
evidence
result వెనుక ఉన్న signals, అందువల్ల మీ team ఎందుకు అని చూడగలదు.

observation mode లో ప్రారంభించండి: results ను మీ logs పక్కనే నమోదు చేయండి మరియు మీరు ఒక policy ఎంచుకునే వరకు ఏమీ మార్చవద్దు. Node.js integration guide ను చదవండి

Observation mode default

Proof of Actor ను install చేయడం ఏ request ను కూడా block చేయదు లేదా మార్చదు. ఫలితాలు record చేయబడతాయి, అందువల్ల మీ team వాటిని నిజమైన application outcomes తో compare చేయగలదు, false positives ను review చేయగలదు, మరియు ఏ policy అయినా సరైనదా కాదా నిర్ణయించగలదు.

ఆధార రకాల

అందుబాటులో ఉన్న ఆధారం integration మరియు context‌పై ఆధారపడి ఉంటుంది. ప్రతి workflow‌కు సంబంధించిన checks onboarding సమయంలో బృందంతో అంగీకరించబడతాయి, మరియు signal internals private‌గా ఉంటాయి, అందువల్ల వాటిని అనుకరించడం కష్టమవుతుంది.

  • request signatures

    తమ కీలను ప్రచురించే automated clients నుండి cryptographic signatures.

  • ప్రకటనలు

    తనను agent గా పేర్కొనే client, లేదా మీ app లోని AI-assistance disclosure.

  • పరస్పర చర్య సంకేతాలు

    ఆమోదించబడిన browser collector నుండి వచ్చిన signals, అది నడిచే పేజీలపై.

  • request context

    server-side integration‌కు అందుబాటులో ఉన్న headers మరియు protocol details.

Agent identity అనేది authorization కాదు

Automated client నుండి వచ్చిన signed request, request ఒక published identifier కు సంబంధించిన key తో sign చేయబడిందని చూపించగలదు, ఉదాహరణకు operator యొక్క 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 ను పిలుస్తుంది, ఒక result ను స్వీకరిస్తుంది, మరియు తన స్వంత rules ను అమలు చేస్తుంది. integration fails open అవ్వాలా (request Proof of Actor లేనట్లే కొనసాగుతుంది) లేదా fails closed అవ్వాలా (మీ existing stronger check వర్తిస్తుంది) అనేది మీరు ప్రతి route మరియు ప్రతి risk tier కోసం ఎంచుకుంటారు.

  • API టైమ్‌అవుట్

    ఒక ఫలితం సమయానికి అందుబాటులో లేకపోతే, మీ integration మీరు ఆ route కోసం ఎంచుకున్న fallbackను ఉపయోగిస్తుంది. timeout ఎప్పటికీ Human resultగా మారదు.

  • telemetry లేదు

    browser collector నడవకపోతే లేదా ఒక signal లేకపోతే, ఫలితం దానినే ప్రతిబింబిస్తుంది. missing evidence వల్ల చెప్పగలదాని పరిమితి తగ్గుతుంది; దాన్ని suspicious‌గా పరిగణించరు.

  • తెలియని వర్గీకరణలు

    Unknown ఒక సాధారణ ఫలితం. ప్రతి route కోసం Unknown అంటే ఏమిటో మీ policy నిర్ణయిస్తుంది, ఉదాహరణకు: public pages ను allow చేయండి, account changes పై existing checks ను కొనసాగించండి.

  • పాత evidence

    Evidence కు ఒక time మరియు ఒక scope ఉంటాయి. session లో ముందుగా వచ్చిన result ను, తాజా check లేకుండా, తరువాతి మరింత sensitive action కోసం మళ్లీ ఉపయోగించకూడదు.

బేటా 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నిర్ణయించండిevidence మద్దతిచ్చే చోట మాత్రమే policy ను enable చేయండి.

founding teams తో మేము కొలిచేది

ప్రతి supported సందర్భంలో coverage, unknown rate, known outcomes కు వ్యతిరేకంగా false positives, మరియు అదనపు latency.

observation mode‌లో ప్రారంభించండి.

founding developer program‌లో చేరడానికి దరఖాస్తు చేయండి.

Early Access కోసం Apply చేయండిDetection & Limits చూడండి

ముందుగా మాట్లాడాలనుకుంటున్నారా? foundersతో మాట్లాడండి