মুখ্য সামগ্ৰীৰ পৰা এৰাই চাওক
HOW IT WORKS

Proof of Actor কেনেকৈ কাম কৰে।

incoming 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-ৰ পৰা signalসেই contextত সেই integrationে observe কৰিব পৰা কথাহে।
  3. 03Evidence normalization আৰু classificationSignal পৰীক্ষা কৰা হয়, ভিত্তি অনুসৰি লেবেল কৰা হয়, আৰু একেলগে সংযুক্ত কৰা হয়।
  4. 04ভিত্তি আৰু অনিশ্চয়তাৰ সৈতে এক্টৰৰ ফলাফলHuman, Human + AI, Agent বা Unknown, লগতে ইয়াৰ ভিত্তি কি।
  5. 05Dashboard আৰু analyticsআপোনাৰ team-এ পৰ্যালোচনা কৰিবলৈ trends, route আৰু evidence।
  6. 06আপোনাৰ application's own 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
ফলাফলৰ পিছৰ signal, যাতে আপোনাৰ দলক কাৰণ দেখা যায়।

observation mode-ত আৰম্ভ কৰক: আপোনাৰ log-ৰ কাষে ফলাফল record কৰক আৰু আপুনি policy বাছি নলৈকে একো সলনি নকৰিব। Node.js integration guide পঢ়ক

Observation mode হৈছে default

Proof of Actor ইনষ্টল কৰিলেও কোনো request block বা সলনি নহয়। ফলাফল record কৰা হয় যাতে আপোনাৰ দলেই সেয়া বাস্তৱ application outcome-ৰ সৈতে তুলনা কৰিব পাৰে, false positive পৰ্যালোচনা কৰিব পাৰে, আৰু কোনো policy উপযুক্ত নে নহয় ঠিক কৰিব পাৰে।

evidence-ৰ ধৰণ

উপলব্ধ evidence integration আৰু context-ৰ ওপৰত নিৰ্ভৰ কৰে। প্ৰতিটো workflow-ৰ check onboarding-ৰ সময়ত দলৰ সৈতে সম্মত হয়, আৰু signal internals private হৈ থাকে যাতে সিহঁত অনুকৰণ কৰা কঠিন হয়।

  • request signatures

    নিজৰ key প্ৰকাশ কৰা automated client ৰ পৰা cryptographic signature।

  • ঘোষণা

    নিজকে এটা agent হিচাপে নাম দিয়া client, বা আপোনাৰ app ৰ ভিতৰত AI-assistance প্ৰকাশ।

  • interaction signals

    অনুমোদিত browser collector-ৰ পৰা signal, য'ত ই চলে সেই pages-ত।

  • request context

    server-side integrationৰ বাবে উপলব্ধ header আৰু protocol detailসমূহ।

Agent identity authorization নহয়

এটা automated client ৰ signed request এ দেখুৱাব পাৰে যে request টো প্ৰকাশিত identifier, যেনে operator ৰ domain, ৰ সৈতে সংযুক্ত key দ্বাৰা sign কৰা হৈছিল। কোন client এ ইয়াক পঠিয়ালে সেই বিষয়ে এইটো উপযোগী evidence।

ই agent কাকে নিৰ্দেশ দিলে, কোনো ব্যক্তিয়ে ইয়ালৈ permission delegate কৰিছিল নে, ইয়াৰ পিছৰ 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 হ'ব নে (আপোনাৰ বৰ্তমান শক্তিশালী check প্ৰযোজ্য হয়)।

  • API সময়সীমা অতিক্ৰম

    যদি সময়মতে ফলাফল উপলব্ধ নহয়, আপোনাৰ integrationএ সেই routeৰ বাবে আপুনি বাছনি কৰা fallback ব্যৱহাৰ কৰে। timeout কেতিয়াও Human result হৈ নাযায়।

  • telemetry নাই

    যদি browser collector চলা নাছিল বা কোনো signal অনুপস্থিত হয়, ফলাফলত সেইটো প্ৰতিফলিত হয়। অনুপস্থিত evidenceএ ক'ব পৰা কথাৰ সীমা কমায়; ইয়াক সন্দেহজনক বুলি গণ্য কৰা নহয়।

  • অজ্ঞাত বৰ্গীকৰণসমূহ

    Unknown এটা স্বাভাৱিক ফলাফল। আপোনাৰ policy-এ প্ৰতিটো route-ৰ বাবে Unknown-ৰ অৰ্থ কি সেয়া নিৰ্ধাৰণ কৰে, উদাহৰণস্বৰূপে: public page allow কৰক, account পৰিবৰ্তনৰ ক্ষেত্ৰত বিদ্যমান check বজাই ৰাখক।

  • পুৰণি evidence

    evidence-ৰ এটা সময় আৰু এটা scope থাকে। session-ৰ আগৰ এটা ফলাফলক নতুন পৰীক্ষা নকৰাকৈ পিছৰ, অধিক সংবেদনশীল action-ৰ বাবে পুনৰ ব্যৱহাৰ কৰা উচিত নহয়।

beta integration workflow

  1. 01প্ৰয়োগ কৰকapp আৰু আপুনি বুজিব বিচৰা interaction-ৰ বিষয়ে কওক।
  2. 02scopeintegration, route, usage limit আৰু data handling-ত সম্মতি দিয়ক।
  3. 03observation mode ত একত্ৰিত কৰকআপোনাৰ app কেনেকৈ respond কৰে তাত কোনো পৰিৱৰ্তন নাই।
  4. 04যাচাই কৰকআপুনি জনা ground truth ৰ সৈতে ফলাফল তুলনা কৰক: coverage, unknown rate, false positives, latency।
  5. 05নিৰ্ণয় কৰকevidence-এ সমৰ্থন কৰা ক্ষেত্ৰতেই policy সক্ৰিয় কৰক।

founding team-ৰ সৈতে আমি কি measure কৰোঁ

প্ৰতিটো সমৰ্থিত context ত coverage, unknown rate, known outcome ৰ বিপৰীতে false positive, আৰু যোগ হোৱা latency।

observation mode-ত আৰম্ভ কৰক।

founding developer program ত যোগদান কৰিবলৈ apply কৰক।

Early Access-ৰ বাবে আবেদন কৰকDetection & Limits চাওক

আগতে কথা পাতিবলৈ পচন্দ কৰেনে? Founding team-ৰ সৈতে কথা পাতক