অ্যাক্টর-সচেতন নীতিমালা নিরাপদে কীভাবে চালু করবেন

অ্যাক্টর-সচেতন নীতিমালা চালু করার সময় কী ভুল হতে পারে?

একটি actor-aware policy আপনার application কীভাবে সাড়া দেবে তা বদলে দেয়, কে বা কী action নিচ্ছে তার ওপর ভিত্তি করে। সঠিকভাবে করলে এটি মানুষকে নির্বিঘ্ন অভিজ্ঞতা দেয়, legitimate agent-দের জন্য একটি structured path দেয়, এবং যেখানে সত্যিই দরকার সেখানে শুধু friction যোগ করে। ভুলভাবে করলে এটি real user-দের আটকে দেয়, আপনার customer-দের নির্ভরশীল integration ভেঙে দেয়, এবং এমন support ticket তৈরি করে যার ব্যাখ্যা কেউ দিতে পারে না।

পার্থক্যটা খুব কমই policy logic-এ হয়। পার্থক্যটা rollout-এ হয়। (policy model নিজে জানতে দেখুন humans and AI agents-এর জন্য app-level policies কীভাবে design করবেন।) এই guide একটি staged process বর্ণনা করে, যেটি team-গুলো যেকোনো route-এর জন্য অনুসরণ করতে পারে: observe, preview, enforce for a slice, তারপর expand। প্রতিটি stage-এর একটি স্পষ্ট exit criterion এবং দ্রুত ফিরে যাওয়ার পথ থাকে।

তিনটি mode

প্রতিটি policy-কে route অনুযায়ী তিনটি mode-এর একটিতে চলছে বলে ভাবুন:

• Observe. Classification record করা হয়। application ঠিক যেমন হতো তেমনই সাড়া দেয়, এগুলো ছাড়াই।
• Preview. policy evaluate করা হয় এবং তার decision record করা হয়, কিন্তু apply করা হয় না। কী হতো তা আপনি দেখতে পারেন।
• Enforce. decision বাস্তব request-এ apply করা হয়।

mode পুরো application-এর নয়, route এবং policy pair-এর। আপনার documentation page enforce করতে পারে, যখন আপনার checkout এখনও observe করছে।

Step 1: আপনার baseline জানা পর্যন্ত observe করুন

প্রতিটি route-কে observe mode-এ রেখে শুরু করুন। অন্তত এগুলো সংগ্রহ করুন:

• route এবং method,
• actor class (Human, Human + AI, Agent বা Unknown) এবং তার basis (verified, declared, inferred বা unknown), যেমন application traffic-এর জন্য আমাদের taxonomy-এ সংজ্ঞায়িত আছে,
• response status এবং route-এর জন্য একটি সহজ outcome marker, যেমন "account created" বা "search returned results"।

সাধারণ weekly cycle এবং সেই সময়ে আপনি যে release ship করেন তার যে কোনোটি cover করার মতো সময় ধরে run করুন। তারপর আপনার যত route গুরুত্বপূর্ণ, প্রতিটির জন্য baseline লিখে রাখুন: class mix, Unknown rate, এবং প্রতি class-এ outcome rate। পরবর্তী সবকিছু আপনি এই সংখ্যাগুলোর সঙ্গে তুলনা করবেন।

Exit criterion: আপনি প্রতিটি candidate route-এর জন্য বলতে পারেন, কে এটি ব্যবহার করে এবং class অনুযায়ী outcome কীভাবে আলাদা হয়।

Step 2: policy-কে data হিসেবে লিখুন

Policy review, test এবং rollback করা বেশি সহজ হয় যখন এগুলো data, ছড়ানো if statement নয়।

type ActorClass = "human" | "human_ai" | "agent" | "unknown";
type Basis = "verified" | "declared" | "inferred" | "unknown";
type Action = "allow" | "adapt" | "challenge" | "review" | "limit";
type Mode = "observe" | "preview" | "enforce";

interface Rule {
  actor: ActorClass | "*";
  basis?: Basis[];
  action: Action;
}

interface RoutePolicy {
  route: string;
  mode: Mode;
  enforcePercent: number;
  rules: Rule[];
  fallback: Action;
}

export const policies: RoutePolicy[] = [
  {
    route: "GET /api/catalog",
    mode: "preview",
    enforcePercent: 0,
    rules: [
      { actor: "agent", basis: ["verified"], action: "allow" },
      { actor: "agent", basis: ["declared", "inferred"], action: "limit" },
    ],
    fallback: "allow",
  },
];

প্রতিটি policy-র একটি স্পষ্ট fallback থাকে। এটি Unknown result, timeout এবং এমন কোনো case-এর জন্য ব্যবহৃত action, যার ওপর কোনো rule প্রযোজ্য নয়। ইচ্ছাকৃতভাবে এটি বেছে নেওয়া পুরো process-এর সবচেয়ে গুরুত্বপূর্ণ safety decision।

Step 3: একটি জায়গায় evaluate করুন

একটি single evaluation function সব mode-এর মধ্যে behavior-কে consistent রাখে।

export function decide(policy: RoutePolicy, actor: ActorClass, basis: Basis): Action {
  for (const rule of policy.rules) {
    const actorMatch = rule.actor === "*" || rule.actor === actor;
    const basisMatch = !rule.basis || rule.basis.includes(basis);
    if (actorMatch && basisMatch) return rule.action;
  }
  return policy.fallback;
}

তারপর mode apply করুন:

export function applyPolicy(policy: RoutePolicy, actor: ActorClass, basis: Basis, requestKey: string) {
  const decision = decide(policy, actor, basis);
  const inSlice = bucket(requestKey) < policy.enforcePercent;
  const enforced = policy.mode === "enforce" && inSlice;
  record({ route: policy.route, mode: policy.mode, actor, basis, decision, enforced });
  return enforced ? decision : "allow";
}

function bucket(key: string): number {
  let h = 0;
  for (const c of key) h = (h * 31 + c.charCodeAt(0)) >>> 0;
  return h % 100;
}

stable bucket-এর মানে একই session বা client enforced slice-এর মধ্যে বা বাইরে একই জায়গায় থাকে, ফলে request-এর মধ্যে behavior উল্টে যায় না।

Step 4: enforce করার আগে false positive কীভাবে মাপবেন?

একটি route-কে preview-তে নিয়ে যান। এখন প্রতিটি request সেই decision record করে, যা এটি পেত। এখানেই আপনি জানেন policy ঠিক কি না।

false positive হলো এমন request, যেটিকে policy সীমিত করত, কিন্তু আসলে allow করা উচিত ছিল। শুধু classification দিয়ে এটি মাপা যায় না, কারণ যে classification আপনি test করছেন সেটাই এখানে পরীক্ষার বিষয়। independent signal-এর বিরুদ্ধে এটি মাপুন, যা legitimate use নির্দেশ করে:

• request একটি স্বাভাবিক successful flow সম্পন্ন করেছে, যেমন signed-in user কাজ save করেছে,
• client একটি known partner integration বা আপনি serve করতে সম্মত এমন verified operator,
• support ticket বা user report প্রভাবিত route-এর উল্লেখ করেছে,
• would-be restricted request-এর একটি sample-এর manual review।

একটি sample হাতে দেখে নিন। policy যে twenty real request-কে challenge করত, সেগুলো পড়াই হলো এমন একটি rule খুঁজে বের করার দ্রুততম উপায়, যা খুবই বিস্তৃত।

Exit criterion: would-be restricted set-এ প্রকৃতপক্ষে যেসব traffic আপনি সীমিত করতে চান সেগুলোর আধিক্য আছে, এবং আপনি পাওয়া প্রতিটি false positive category-এর ব্যাখ্যা দিতে পারেন।

Step 5: একটি slice-এর জন্য enforce করুন

ছোট একটি enforcePercent নিয়ে route-টিকে enforce-এ নিন। slice-টা যথেষ্ট ছোট রাখুন, যাতে একটি ভুল কম request-কে প্রভাবিত করে, এবং যথেষ্ট বড় রাখুন, যাতে এক বা দুই দিনের মধ্যে একটি measurable signal পাওয়া যায়।

আপনার baseline হিসেবে যে metrics সেট করেছিলেন, সেগুলোই দেখুন:

• route-এ প্রতি class outcome rate,
• error এবং challenge completion rate,
• route উল্লেখ করে এমন support volume,
• latency, কারণ evaluation request path-এর ওপর বসে।

enforced slice-এ Human traffic-এর outcome যদি বাকি অংশের তুলনায় কমে যায়, থামুন এবং expand করার আগে তদন্ত করুন।

Step 6: ধীরে ধীরে expand করুন

ধাপে ধাপে slice বাড়ান, যেমন ছোট অংশ থেকে quarter, তারপর half, তারপর সব traffic, এবং প্রতিটি ধাপে এমন সময় ধরে রাখুন যাতে একটি normal cycle দেখা যায়। আগের stage-গুলো ভালোভাবে করা থাকলে expansion একঘেয়ে লাগে। সেটাই লক্ষ্য।

fallback এবং failure behavior কীভাবে বেছে নেবেন

evidence missing থাকলে বা evaluation চলতে না পারলে কী হবে, তা আগে থেকেই ঠিক করুন।

• Fail open মানে request actor context ছাড়াই যেমন চলত তেমনই এগোয়। public page, documentation এবং read-only catalog endpoint-এর মতো low-risk route-এ এটি ব্যবহার করুন।
• Fail closed মানে আপনার বিদ্যমান stronger check apply হয়, যেমন re-authentication বা review queue। যেখানে এমন check ইতিমধ্যে আছে, সেসব high-impact action-এ এটি ব্যবহার করুন।

কোনো timeout বা error যেন Human result তৈরি না করে। Missing evidence হলো Unknown, এবং Unknown route-এর fallback নেয়। AI traffic classify করার সময় Unknown কেন valid result-এ আমাদের post এই rule কেন গুরুত্বপূর্ণ তা ব্যাখ্যা করে।

async function actorWithTimeout(evaluate: () => Promise<{ actor: ActorClass; basis: Basis }>) {
  const timeout = new Promise<{ actor: ActorClass; basis: Basis }>((resolve) =>
    setTimeout(() => resolve({ actor: "unknown", basis: "unknown" }), 150),
  );
  return Promise.race([evaluate(), timeout]);
}

policy দ্রুত rollback করবেন কীভাবে?

Rollback deploy নয়, configuration change হওয়া উচিত। policy-গুলো এমন store-এ রাখুন, যেটি আপনার team দ্রুত edit করতে পারে, এবং এই action-গুলো instant করুন:

1. একটি route-কে আবার preview-তে সেট করুন, যা measurement রেখে enforcement বন্ধ করে।
2. enforcePercent শূন্যে সেট করুন।
3. অন্য rule-গুলো না ছুঁয়ে একটি single rule disable করুন।

প্রতিটি policy change কে রেকর্ড করুন, কে করেছে এবং কখন করেছে তা সহ। outcome বদলালে প্রথম প্রশ্ন সবসময় হয় কী বদলেছে।

মানুষের বিষয়ে consequential decision এড়িয়ে চলুন

Actor classification একটি interaction সম্পর্কে evidence বর্ণনা করে। এটি কোনো ব্যক্তিকে নিয়ে judgment নয়। inferred class-কে এমন সিদ্ধান্তের একমাত্র ভিত্তি হিসেবে ব্যবহার করবেন না, যা কারও employment, credit, education, housing বা essential service-এ access প্রভাবিত করে। এসব flow-এর জন্য outcome নির্ধারণ না করে actor context ব্যবহার করে একটি process বেছে নিন, যেমন human review-এ route করা।

enforce করার আগে communicate করুন

যে policy automated client-কে প্রভাবিত করে, তা সেই মানুষ এবং company-গুলোকেও প্রভাবিত করে যারা এগুলো চালায়। সামান্য যোগাযোগ অনেক support কাজ বাঁচায়:

1. Automated access-এর জন্য আপনার rule প্রকাশ করুন। কোন route খোলা, কী limit প্রযোজ্য, এবং signed request ব্যবহার করে client কীভাবে নিজেদের identify করবে তা বলুন, HTTP Message Signatures (RFC 9421) এবং IETF Web Bot Auth protocol draft ব্যবহার করে।
2. Partner এবং integrator-দের আগে থেকে জানান। যদি কোনো known integration preview-এর সময় restricted slice-এ পড়ে, আপনি enforce করার আগে তার owner-এর সঙ্গে যোগাযোগ করুন।
3. উপকারী response দিন। policy কোনো request সীমিত করলে বা challenge করলে, একটি clear status code দিয়ে respond করুন, যেমন 429 Too Many Requests সঙ্গে Retry-After, এবং আপনার documentation-এর একটি link দিন। Problem Details format-এ একটি machine-readable body automated client-কে structured reason দেয়। ভালোভাবে তৈরি agent-রা কেন এমন হলো বুঝলে adapt করে।
4. আপনার support team-কে evidence দিন। blocked request নিয়ে ticket এলে, engineering-কে না ডেকে support route, class, basis এবং policy decision lookup করতে পারবে।

যে team-গুলো পরিবর্তন ঘোষণা করে এবং ব্যাখ্যা করে, তারা নীরবে rule বদলানো team-গুলোর তুলনায় অনেক কম surprise দেখে, এবং adapt করা client-দের সময়ের সঙ্গে চেনা আরও সহজ হয়।

প্রতিটি route-এর জন্য একটি checklist

• class mix, Unknown rate এবং outcome-এর baseline record করা হয়েছে।
• স্পষ্ট fallback সহ policy data হিসেবে লেখা হয়েছে।
• preview run হয়েছে, sample review করা হয়েছে, false positive category ব্যাখ্যা করা হয়েছে।
• metrics পর্যবেক্ষণ করে ছোট slice-এ enforcement শুরু হয়েছে।
• failure behavior বেছে নেওয়া হয়েছে: fail open বা fail closed।
• expansion-এর আগে rollback test করা হয়েছে।

Proof of Actor কোথায় fit করে

Proof of Actor এই process-এর চারপাশে design করা হয়েছে। Observation হলো default, প্রতিটি result তার basis বহন করে, এবং Route policy-গুলো আপনার নিজের code-এ, route by route, define এবং enforce করার দায়িত্ব আপনার। Detect, Understand, Route: এই ক্রমে।

আপনার নিজের application-এ আমাদের team-এর সঙ্গে rollout করতে, early access-এর জন্য apply করুন। end-to-end decision flow-এর জন্য, How Proof of Actor works পড়ুন।

Sources

• RFC 6585: Additional HTTP Status Codes, Section 4: 429 Too Many Requests status code
• RFC 9110: HTTP Semantics, Retry-After: clients-কে কখন retry করতে হবে তা জানানো
• RFC 9457: Problem Details for HTTP APIs: machine-readable error body
• RFC 9421: HTTP Message Signatures: automated client কীভাবে request sign করে
• draft-ietf-webbotauth-httpsig-protocol: signed automated traffic-এর জন্য IETF Web Bot Auth draft (November 2026 অনুযায়ী কাজ চলমান)