ମୁଖ୍ୟ ବିଷୟବସ୍ତୁକୁ ଛାଡ଼ନ୍ତୁ
ଏହା କିପରି କାମ କରେ

Proof of Actor କିପରି କାମ କରେ।

ଆସୁଥିବା interaction ରୁ application decision ପର୍ଯ୍ୟନ୍ତ evidence-first path।

policy · example-app.test
  • /api/v1/catalogenforceଏଜେଣ୍ଟଅନୁମତି ଦିଅନ୍ତୁ · structured API
  • /support/ticketsenforceମଣିଷ + AIଅନୁମତି ଦିଅନ୍ତୁ · AI-assisted label
  • /account/*previewଅଜ୍ଞାତବର୍ତ୍ତମାନର checks କୁ ରଖନ୍ତୁ
  • /api/v1/orderspreviewଏଜେଣ୍ଟଅଧିକ ଶକ୍ତିଶାଳୀ credential ଆବଶ୍ୟକ କରନ୍ତୁ

interaction ଠାରୁ ନିଷ୍ପତ୍ତି ପର୍ଯ୍ୟନ୍ତ

  1. 01ଆବେଦନ request କିମ୍ବା eventଏକ page view, ଏକ API call, ଏକ MCP tool call କିମ୍ବା ଏକ in-app କାର୍ଯ୍ୟ।
  2. 02supported integration ରୁ signalସେହି context ରେ ସେ integration observe କରିପାରୁଥିବା କେବଳ ସେତିକି।
  3. 03Evidence normalization ଏବଂ classificationsignalଗୁଡ଼ିକ ଯାଞ୍ଚ କରାଯାଏ, ଆଧାର ଅନୁସାରେ label କରାଯାଏ ଏବଂ ମିଶାଯାଏ।
  4. 04ଆଧାର ଏବଂ ଅନିଶ୍ଚିତତା ସହିତ ଅଭିନେତା ଫଳାଫଳHuman, Human + AI, Agent କିମ୍ବା Unknown, ଏବଂ ଏହା କ’ଣ ଉପରେ ଭିତ୍ତି କରିଛି।
  5. 05dashboard ଏବଂ analyticsଆପଣଙ୍କ team review କରିବା ପାଇଁ trends, routes ଏବଂ evidence।
  6. 06ଆପଣଙ୍କ application's own decisionକେବଳ observe କରନ୍ତୁ, କିମ୍ବା ଆପଣ ଚୟନ କରିଥିବା ଏକ policy apply କରନ୍ତୁ।
ବିକାଶକର୍ତ୍ତାମାନଙ୍କ ପାଇଁ

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 ପଛରେ ଥିବା signal, ଯାହାଦ୍ୱାରା ଆପଣଙ୍କ team କାହିଁକି ତାହା ଦେଖିପାରିବ।

observation mode ରେ ଆରମ୍ଭ କରନ୍ତୁ: ଆପଣଙ୍କ log ପାଖରେ result record କରନ୍ତୁ ଏବଂ ଆପଣ policy ବାଛିବା ପର୍ଯ୍ୟନ୍ତ କିଛି ମଧ୍ୟ ପରିବର୍ତ୍ତନ କରନ୍ତୁ ନାହିଁ। Node.js integration guide ପଢନ୍ତୁ

Observation mode ହେଉଛି default

Proof of Actor install କଲେ କୌଣସି request କୁ block କରେନାହିଁ ଏବଂ ବଦଳାଏ ମଧ୍ୟ ନାହିଁ। Result ଗୁଡ଼ିକ record କରାଯାଏ, ଯାହାଦ୍ୱାରା ଆପଣଙ୍କ team ସେଗୁଡ଼ିକୁ ବାସ୍ତବ application outcome ସହିତ ତୁଳନା କରିପାରିବ, false positive ଯାଞ୍ଚ କରିପାରିବ, ଏବଂ କୌଣସି policy ଉପଯୁକ୍ତ କି ନାହିଁ ନିଷ୍ପତ୍ତି ନେଇପାରିବ।

evidence ର ପ୍ରକାର

ଉପଲବ୍ଧ evidence integration ଏବଂ context ଉପରେ ନିର୍ଭର କରେ। ପ୍ରତ୍ୟେକ workflow ପାଇଁ checks onboarding ସମୟରେ ଦଳ ସହିତ ସମ୍ମତି ହୁଏ, ଏବଂ signal internals private ରହେ ଯାହାଦ୍ୱାରା ସେଗୁଡ଼ିକୁ ଅନୁକରଣ କରିବା କଠିନ ହୁଏ।

  • ଅନୁରୋଧ ସହିଗୁଡ଼ିକ

    ସେମାନଙ୍କ key ପ୍ରକାଶ କରୁଥିବା automated clientମାନଙ୍କ ଠାରୁ cryptographic signature।

  • ଘୋଷଣାଗୁଡ଼ିକ

    ନିଜକୁ Agent ଭାବରେ ନାମକରଣ କରୁଥିବା client, କିମ୍ବା ଆପଣଙ୍କ app ଭିତରେ AI ସହାୟତା ଖୋଲାସା।

  • କ୍ରିୟାକଳାପ ସଙ୍କେତ

    ଏକ approved browser collector ରୁ signal, ଯେଉଁ ପୃଷ୍ଠାଗୁଡ଼ିକରେ ଏହା ଚାଲେ ସେଠାରେ।

  • ଅନୁରୋଧ ପ୍ରସଙ୍ଗ

    server-side integration ପାଇଁ ଉପଲବ୍ଧ header ଏବଂ protocol detail।

Agent identity authorization ନୁହେଁ

ଏକ automated client ଠାରୁ ଆସିଥିବା signed request ଦେଖାଇପାରେ ଯେ request ଟି ପ୍ରକାଶିତ identifier, ଯେପରିକି operator ର domain, ସହିତ ସମ୍ବନ୍ଧିତ key ଦ୍ୱାରା signed ହୋଇଥିଲା। ଏହା କେଉଁ client ଏହା ପଠାଇଥିଲା ସେଥିପାଇଁ ଉପଯୋଗୀ ପ୍ରମାଣ।

ଏହା agent କୁ କିଏ ନିର୍ଦ୍ଦେଶ ଦେଇଥିଲେ, ଜଣେ ବ୍ୟକ୍ତି ଏହାକୁ permission ଦେଇଥିଲେ କି, ତାହାର ପଛରେ କାନୁନିକ ପରିଚୟ କିଏ, କିମ୍ବା କାର୍ଯ୍ୟଟି ସୁରକ୍ଷିତ କି ନାହିଁ, ସେଥିକୁ ଦେଖାଏ ନାହିଁ। ସେଗୁଡ଼ିକ ଅଲଗା ପ୍ରଶ୍ନ, ଯାହାକୁ ଆପଣଙ୍କ 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 ପାଏ, ଏବଂ ନିଜସ୍ୱ ruleଗୁଡ଼ିକୁ ପ୍ରୟୋଗ କରେ। ଆପଣ ପ୍ରତ୍ୟେକ route ଏବଂ ପ୍ରତ୍ୟେକ risk tier ପାଇଁ ବାଛନ୍ତି, integration କି fails open ହେବ (request Proof of Actor ନଥିଲେ ଯେପରି ଆଗକୁ ବଢ଼େ ସେପରି ବଢ଼ିବ) କିମ୍ବା fails closed ହେବ (ଆପଣଙ୍କ ଅବସ୍ଥିତ ଶକ୍ତିଶାଳୀ check ପ୍ରୟୋଗ ହେବ)।

  • API ସମୟସୀମା ଅତିକ୍ରମ

    ଯଦି କୌଣସି result ସମୟରେ ଉପଲବ୍ଧ ନୁହେଁ, ଆପଣଙ୍କ integration ସେହି route ପାଇଁ ଆପଣ ଚୟନ କରିଥିବା fallback ବ୍ୟବହାର କରେ। timeout କେବେ ମଧ୍ୟ Human result ହୁଏ ନାହିଁ।

  • telemetry ଅନୁପସ୍ଥିତ

    ଯଦି browser collector ଚାଲିଲା ନାହିଁ କିମ୍ବା କୌଣସି signal ନାହିଁ, result ଏହାକୁ ପ୍ରତିବିମ୍ବିତ କରେ। ଅନୁପସ୍ଥିତ ପ୍ରମାଣ କ’ଣ କୁହାଯାଇପାରିବ ସେଥିକୁ କମାଏ; ଏହାକୁ ସନ୍ଦେହଜନକ ଭାବରେ ଧରାଯାଏ ନାହିଁ।

  • ଅଜଣା ବର୍ଗୀକରଣ

    Unknown ଏକ ସାଧାରଣ ଫଳାଫଳ। ଆପଣଙ୍କ policy ପ୍ରତ୍ୟେକ route ପାଇଁ Unknown ର ଅର୍ଥ କଣ ହେବ ନିର୍ଦ୍ଧାରଣ କରେ, ଉଦାହରଣ ସ୍ୱରୂପ: ସାର୍ବଜନୀନ page କୁ allow କରନ୍ତୁ, account ପରିବର୍ତ୍ତନରେ ଅବସ୍ଥିତ check ଗୁଡ଼ିକ ରଖନ୍ତୁ।

  • ପୁରୁଣା evidence

    Evidence ରେ time ଏବଂ scope ଥାଏ। ଏକ session ର ପୂର୍ବରୁ ଆସିଥିବା result କୁ ଏକ later, ଅଧିକ sensitive 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 ସକ୍ରିୟ କରନ୍ତୁ।

ଆମେ founding teamମାନଙ୍କ ସହ କ'ଣ ମାପୁଛୁ

ପ୍ରତ୍ୟେକ supported contextରେ coverage, unknown rate, known outcome ବିରୋଧରେ false positive ଏବଂ ଅତିରିକ୍ତ latency।

observation mode ରେ ଆରମ୍ଭ କରନ୍ତୁ।

founding developer program ରେ ଯୋଗଦେବା ପାଇଁ ଆବେଦନ କରନ୍ତୁ।

ପ୍ରଥମେ କଥାହେବାକୁ ପସନ୍ଦ କରନ୍ତି? founderମାନଙ୍କ ସହ କଥାବାର୍ତ୍ତା କରନ୍ତୁ