মূল বিষয়বস্তুতে যান
কীভাবে কাজ করে

Proof of Actor কীভাবে কাজ করে।

incoming interaction থেকে application decision পর্যন্ত একটি evidence-first path।

Early Access-এর জন্য আবেদন করুনDetection & Limits দেখুন
policy · example-app.test
  • /api/v1/catalogenforceএজেন্টঅনুমতি দিন · structured API
  • /support/ticketsenforceমানুষ + AIঅনুমতি দিন · Human + AI হিসেবে চিহ্নিত করুন
  • /account/*previewঅজানাবিদ্যমান checks বজায় রাখুন
  • /api/v1/orderspreviewএজেন্টআরও শক্তিশালী পরিচয়পত্র প্রয়োজন

interaction থেকে decision পর্যন্ত

  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ভিত্তি এবং অনিশ্চয়তাসহ অ্যাক্টর ফলাফলমানুষ, মানুষ + AI, Agent বা Unknown, পাশাপাশি এটি কীসের উপর নির্ভর করে।
  5. 05Dashboard এবং analyticsআপনার team-এর পর্যালোচনার জন্য trend, route এবং 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-এর পাশে record করুন এবং আপনি কোনো policy বেছে না নেওয়া পর্যন্ত কিছুই পরিবর্তন করবেন না। Node.js integration guide পড়ুন

Observation mode-ই default

Proof of Actor ইনস্টল করলে কোনো request block বা পরিবর্তন হয় না। ফলাফল record করা হয়, যাতে আপনার team সেগুলিকে বাস্তব application outcome-এর সঙ্গে তুলনা করতে পারে, false positive review করতে পারে, এবং কোনো policy উপযুক্ত কি না সিদ্ধান্ত নিতে পারে।

evidence-এর ধরন

উপলব্ধ evidence integration এবং context-এর ওপর নির্ভর করে। প্রতিটি workflow-এর checks onboarding-এর সময় টিমের সঙ্গে সম্মত হয়, এবং signal internals private থাকে যাতে সেগুলো অনুকরণ করা কঠিন হয়।

  • অনুরোধের স্বাক্ষরসমূহ

    যে automated client তাদের key প্রকাশ করে তাদের cryptographic signature।

  • Declaration

    নিজেকে agent হিসেবে পরিচয় দেওয়া একটি client, অথবা আপনার app-এর ভিতরে AI-assistance disclosure।

  • ইন্টারঅ্যাকশন সংকেত

    একটি approved browser collector থেকে signals, যে পৃষ্ঠাগুলিতে এটি চলে সেখানে।

  • অনুরোধের প্রসঙ্গ

    server-side integration-এর জন্য উপলব্ধ header এবং protocol detail।

Agent identity authorization নয়

একটি automated client থেকে আসা signed request দেখাতে পারে যে requestটি একটি published identifier-এর সঙ্গে যুক্ত key দিয়ে sign করা হয়েছিল, যেমন operator-এর domain। কোন client এটি পাঠিয়েছে সে বিষয়ে এটি উপকারী evidence।

এটি দেখায় না কে agent-কে নির্দেশ দিয়েছে, কোনও ব্যক্তি এতে অনুমতি অর্পণ করেছেন কি না, এর পেছনের আইনি পরিচয় কী, বা কাজটি নিরাপদ কি না। এগুলো আলাদা প্রশ্ন, যার উত্তর আপনার অ্যাপ্লিকেশন তার নিজের authentication, authorization এবং policy দিয়ে দেয়।

তিনটি পৃথক প্রশ্ন
  • কে call করছে?Proof of Actor: signature, declaration বা inference
  • কোন credential?আপনার API key, OAuth token বা session
  • এটি কী করতে পারে?আপনার authorization এবং policy

routing decision-গুলি কীভাবে মানিয়ে যায়

আপনার application Proof of Actor-কে call করে, একটি result পায়, এবং তার নিজস্ব নিয়ম প্রয়োগ করে। আপনি route এবং risk tier অনুযায়ী বেছে নেন, integration fail open হবে কিনা (requestটি Proof of Actor ছাড়া যেমন চলত তেমনই চলবে) বা fail closed হবে কিনা (আপনার বিদ্যমান আরও শক্তিশালী check প্রয়োগ হবে)।

  • API টাইমআউট

    সময়ে কোনো result উপলব্ধ না হলে, আপনার integration সেই route-এর জন্য আপনার বেছে নেওয়া fallback ব্যবহার করে। timeout কখনো Human result হয়ে যায় না।

  • telemetry অনুপস্থিত

    browser collector না চললে বা কোনো signal অনুপস্থিত থাকলে, result তা প্রতিফলিত করে। অনুপস্থিত evidence কী বলা যায় তা কমিয়ে দেয়; এটিকে সন্দেহজনক হিসেবে ধরা হয় না।

  • Unknown classification

    Unknown একটি স্বাভাবিক outcome। আপনার policy প্রতিটি route-এর জন্য Unknown-এর অর্থ নির্ধারণ করে, উদাহরণস্বরূপ: public page allow করুন, account পরিবর্তনে existing check বজায় রাখুন।

  • পুরোনো evidence

    Evidence-এর একটি time এবং scope আছে। session-এর আগের result কোনো later, বেশি sensitive action-এর জন্য fresh check ছাড়া পুনরায় ব্যবহার করা উচিত নয়।

বিটা integration workflow

  1. 01আবেদন করুনApp এবং আপনি যে interaction বুঝতে চান, সে সম্পর্কে বলুন।
  2. 02পরিধিintegration, route, usage limit এবং data handling-এ একমত হন।
  3. 03পর্যবেক্ষণ মোডে একীভূত করুনআপনার app কীভাবে respond করে তাতে কোনো পরিবর্তন নেই।
  4. 04যাচাই করুনআপনি যে ground truth জানেন তার সঙ্গে ফলাফল তুলনা করুন: coverage, unknown rate, false positives, latency।
  5. 05নির্ধারণ করুনশুধু যেখানে evidence তা সমর্থন করে, সেখানেই policy enable করুন।

founding teamদের সঙ্গে আমরা যা মাপি

প্রতিটি সমর্থিত context-এ coverage, unknown rate, পরিচিত outcome-এর বিপরীতে false positive, এবং অতিরিক্ত latency।

observation mode-এ শুরু করুন।

founding developer program-এ যোগ দিতে আবেদন করুন।

Early Access-এর জন্য আবেদন করুনDetection & Limits দেখুন

আগে কথা বলতে চান? Founders-এর সঙ্গে কথা বলুন