মূল বিষয়বস্তুতে যান
APIS

আপনার API-এ কে call করছে তা বোঝুন।

প্রতি API request-এ অ্যাক্টর প্রসঙ্গ যোগ করুন: কোন ক্লায়েন্ট কল করছে, evidence কতটা শক্তিশালী, এবং route অনুযায়ী আপনার API-এর কী করা উচিত।

প্রাথমিক access পানকীভাবে কাজ করে তা অন্বেষণ করুন
example-app.test · actor result

POST /api/v1/orders

এজেন্টbasis: inferred

প্রমাণ

browser context ছাড়া API-key traffic এবং একটি automated request pattern

আপনার policy: order তৈরি করার আগে আরও শক্তিশালী credential চাইুন

একটি API key পরিচয় নয়, এবং পরিচয় permission নয়।

বেশিরভাগ API traffic এমন একটি credential নিয়ে আসে যা বলে কোন account অর্থ দিচ্ছে, কিন্তু কোন client কল করছে বা কাকে সেটি নির্দেশ দিয়েছে তা নয়। কিছু client তাদের request sign করে, অনেকেই শুধু একটি নাম ঘোষণা করে, আর অনেকেই একেবারেই কিছু বলে না।

Proof of Actor প্রতিটি API-কে উত্তর দিতে হয় এমন তিনটি প্রশ্নকে আলাদা করে, যাতে প্রতিটিকে সঠিক evidence এবং সঠিক control দেওয়া যায়।

তিনটি পৃথক প্রশ্ন
  • কে call করছে?অ্যাক্টর পরিচয়: স্বাক্ষর, ঘোষণা বা অনুমান
  • কোন credential?আপনার API key, OAuth token বা session
  • এটি কী করতে পারে?আপনার authorization এবং policy

Proof of Actor প্রথমটির উত্তর দেয়। আপনার stack বাকি দুটিকে রাখে।

API team actor context দিয়ে কী করে

  • স্বাক্ষরিত ক্লায়েন্ট শনাক্ত করুন

    প্রকাশিত key-এর বিপরীতে request signature পরীক্ষা করুন এবং কোন operator-এর অন্তর্ভুক্ত request তা দেখুন।

  • declaration-কে declaration হিসেবেই বিবেচনা করুন

    স্ব-ঘোষিত client name নথিভুক্ত করুন, এবং সেগুলোকে verified identity থেকে আলাদা রাখুন।

  • route অনুযায়ী policy

    low-impact read-এ অবাধে অনুমতি দিন এবং write ও high-impact endpoint-এ আরও অনুরোধ করুন।

  • প্রতিটি caller দেখুন

    কোন client কোন endpoint ব্যবহার করে, unknown endpoint-সহ, তা বোঝুন।

  • credentials আলাদা রাখুন

    API key এবং OAuth এখনও access নির্ধারণ করে। Actor context যোগ করে কে call করছে।

  • Unknown-এর জন্য পরিকল্পনা

    প্রতি route-এ caller usable evidence না দিলে কী হবে তা নির্ধারণ করুন।

01 · সনাক্ত করুন

প্রতিটি request-এর evidence।

সার্ভার, এজ এবং HTTP API ইন্টিগ্রেশনগুলি request signatures, ঘোষিত ক্লায়েন্ট বিবরণ এবং request context পড়ে, এবং প্রতিটিকে তার ভিত্তি অনুযায়ী লেবেল করে।

  • প্রকাশিত key-এর বিপরীতে HTTP message signature যাচাই করা হয়েছে।
  • Declared client name declaration হিসেবে record করা হয়েছে।
  • আপনার server, gateway বা edge থেকে অনুরোধের প্রসঙ্গ।
সিগন্যাল · প্রতি উৎসের সর্বশেষ অনুরোধ
  • অনুরোধের স্বাক্ষরvalid · sample-crawler.exampleverified
  • client ঘোষণা"research-assistant/2.1"declared
  • ব্রাউজার ইন্টারঅ্যাকশনpointer + keyboard eventsinferred
  • কোনো supported signal নেইroute not instrumentedunknown

02 · বুঝুন

কে কোন endpoint ব্যবহার করে, তা জানুন।

প্রতিটি route-এ actor-এর মিশ্রণ দেখুন, কোন operator আপনাকে সবচেয়ে বেশি কল করে, এবং unknown caller কোথায় কেন্দ্রীভূত হয় তা দেখুন।

  • route এবং operator অনুযায়ী caller।
  • প্রতিটি classification-এর পেছনের evidence।
  • প্রতি endpoint-এ Unknown rate।
route অনুযায়ী traffic · 7 days
  • /dashboardঅজানা 7%
  • /api/v1/catalogঅজানা 15%
  • /support/ticketsঅজানা 8%
  • /signupঅজানা 21%
মানুষমানুষ + AIএজেন্টঅজানা

03 · রুট করুন

প্রভাবের সঙ্গে সামঞ্জস্যপূর্ণ control।

route-level policy লিখুন: verified agent-এর জন্য structured response, declared client-এর জন্য standard limit, এবং high-impact action-এর জন্য stronger credential।

  • route, class এবং basis অনুযায়ী policy।
  • যখন প্রয়োজন, আরও শক্তিশালী credential-এ এগিয়ে যান।
  • পর্যবেক্ষণ করুন, preview করুন, তারপর enforce করুন।
policy · example-app.test
  • /api/v1/catalogenforceএজেন্টঅনুমতি দিন · structured API
  • /support/ticketsenforceমানুষ + AIঅনুমতি দিন · Human + AI হিসেবে চিহ্নিত করুন
  • /account/*previewঅজানাবিদ্যমান checks বজায় রাখুন
  • /api/v1/orderspreviewএজেন্টআরও শক্তিশালী পরিচয়পত্র প্রয়োজন

উদাহরণস্বরূপ সিদ্ধান্ত

request থেকে result হয়ে আপনার decision পর্যন্ত।

  • একটি Verified agent আপনার catalog পড়ে

    অনুরোধ

    GET /api/v1/catalog

    ফলাফল

    এজেন্টbasis: verified

    আপনার সিদ্ধান্ত

    agent rate limit এবং structured response দিয়ে অনুমতি দিন।

  • একটি automated client order দেয়

    অনুরোধ

    POST /api/v1/orders

    ফলাফল

    এজেন্টbasis: inferred

    আপনার সিদ্ধান্ত

    order তৈরি করার আগে app-এর আরও শক্তিশালী credential চাইুন।

  • কোনো evidence নেই এমন client

    অনুরোধ

    GET /api/v1/catalog

    ফলাফল

    অজানাbasis: unknown

    আপনার সিদ্ধান্ত

    read-only route: default rate limit সহ allow করুন।

ঝুঁকি ছাড়াই চালু করুন

টিমগুলো observation mode-এ শুরু করে এবং route অনুযায়ী এগোয়।

  1. 01

    প্রতিটি route observe করুন

    আপনার API-এর সামনে middleware বা HTTP API যোগ করুন। signatures, declarations এবং Unknown callers প্রতিটি route অনুযায়ী রেকর্ড করা হয়।

  2. 02

    route policies preview করুন

    প্রয়োগের আগে real traffic-এ agent rate limits বা step-up credentials কী করত তা পরীক্ষা করুন।

  3. 03

    প্রভাব অনুযায়ী enforce করুন

    reads খোলা রাখুন, writes কঠোর করুন, এবং access-এর দায়িত্ব API keys ও OAuth-এর হাতে রাখুন।

আপনার stack-এর সঙ্গে কাজ করে

  • প্রতিষ্ঠাতা দলসমূহ

    ওয়েব সার্ভার middleware (Node.js)

    সার্ভার-সাইড

    server-rendered app এবং API-এর জন্য অনুরোধ-স্তরের সিগন্যাল।

  • প্রতিষ্ঠাতা দলসমূহ

    Next.js

    সার্ভার-সাইড এবং এজ

    page এবং API route-এর জন্য middleware।

  • প্রতিষ্ঠাতা দলসমূহ

    ব্রাউজার স্ক্রিপ্ট

    শুধু browser signals

    server-side integration-এর পাশাপাশি browser sessions থেকে interaction signals।

  • প্রতিষ্ঠাতা দলসমূহ

    Cloudflare এবং edge runtime

    Edge

    আপনার origin-এ request পৌঁছানোর আগে edge-এ signals।

  • প্রতিষ্ঠাতা দলসমূহ

    সাধারণ HTTP API

    যেকোনো stack

    একটি API-তে request context পাঠান এবং তার basis-সহ একটি result পান।

  • প্রতিষ্ঠাতা দলসমূহ

    MCP সার্ভার

    MCP

    MCP টুল কলের জন্য অ্যাক্টর প্রসঙ্গ।

  • রোডম্যাপ

    WordPress

    Plugin

    WordPress site-এর জন্য plugin।

  • রোডম্যাপ

    native mobile

    iOS এবং Android

    Native iOS এবং Android SDK।

অনবোর্ডিংয়ের সময় প্রতিটি founding team-এর সঙ্গে একীভূতকরণ হাতে-কলমে দেওয়া হয়। ভিন্ন stack ব্যবহার করছেন? আবেদন করার সময় জানান।

আরও জানুন

Detection & Limitations পড়ুন

প্রায়শই জিজ্ঞাসিত প্রশ্ন

Client-দের কি তাদের request sign করতে হবে?

না। signed request সবচেয়ে শক্তিশালী evidence দেয়, কিন্তু Proof of Actor declaration এবং inference-ও record করে, প্রতিটিকে তার basis অনুযায়ী label করে, এবং যথেষ্ট না হলে Unknown report করে।

Valid signature মানে কি client-কে act করার অনুমতি আছে?

না। এটি দেখায় request-টি একটি published identifier-এর সঙ্গে যুক্ত key দিয়ে sign করা হয়েছে। সেই operator কী করতে পারে তা নির্ধারণ করে আপনার authorization এবং policy।

এটা কি API key বা OAuth-এর বিকল্প?

না। credential এখনও access নিয়ন্ত্রণ করে। Proof of Actor যোগ করে কে বা কী কল করছে, যাতে আপনি তার ওপর আরও ভালো policy প্রয়োগ করতে পারেন।

আমরা কি প্রতিটি endpoint-এর জন্য আলাদা নিয়ম সেট করতে পারি?

হ্যাঁ। Policy প্রতি route অনুযায়ী লেখা হয়, তাই read-only endpoint এবং high-impact write আলাদা ভাবে扱া যেতে পারে।

এতে কত খরচ হয়?

নির্বাচিত founding developer team সম্মত ব্যবহারের সীমার মধ্যে সর্বোচ্চ 12 months free পেতে পারে।

আপনার API-তে কে কল করছে, তা জানুন।

Proof of Actor founding developer program-এ যোগ দিন।

প্রাথমিক access পানডেভেলপার হাব

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