অভ্যন্তরীণ actor-aware নীতি কীভাবে নিরাপদে rollout করবেন

actor-aware নীতি rollout করার সময় কী কী ভুল হতে পারে?

actor-aware নীতি বদলে দেয় আপনার application কিভাবে প্রতিক্রিয়া জানাবে, তা কে বা কী acting করছে তার উপর ভিত্তি করে। সঠিকভাবে করলে, এটি মানুষের জন্য মসৃণ experience দেয়, legitimate agent-দের জন্য একটি কাঠামোবদ্ধ পথ দেয়, এবং যেখানে সত্যিই দরকার শুধু সেখানেই friction যোগ করে। ভুলভাবে করলে, এটি real user-দের lock out করে, আপনার customer-দের নির্ভরশীল integration ভেঙে দেয়, এবং এমন support ticket তৈরি করে যা কেউ ব্যাখ্যা করতে পারে না।

পার্থক্যটা সাধারণত policy logic-এ নয়। এটা rollout-এ। (policy model নিজে জানতে দেখুন মানুষ ও AI agent-দের জন্য app-level নীতি কীভাবে design করবেন।) এই guide একটি staged process বর্ণনা করে, যা team যেকোনো route-এ অনুসরণ করতে পারে: observe করুন, preview করুন, একটি slice-এ enforce করুন, তারপর প্রসারিত করুন। প্রতিটি stage-এর একটি স্পষ্ট exit criterion এবং দ্রুত ফিরে যাওয়ার উপায় আছে।

তিনটি mode

প্রতিটি policy-কে প্রতি route-এ তিনটি mode-এর একটিতে চলমান হিসেবে ভাবুন:

• Observe. Classification record হয়। Application ঠিক যেমন হত, তেমনই প্রতিক্রিয়া জানায়।
• Preview. Policy evaluate হয় এবং তার সিদ্ধান্ত record হয়, কিন্তু apply হয় না। কী হত তা আপনি দেখতে পারেন।
• Enforce. সিদ্ধান্ত real request-এ apply হয়।

mode-টি route এবং policy pair-এর অন্তর্গত, পুরো application-এর নয়। আপনার documentation page enforce করতে পারে, while আপনার checkout এখনো observe করতেই পারে।

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

প্রতিটি route-কে observe mode-এ শুরু করুন। অন্তত এইগুলো collect করুন:

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

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

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

Step 2: নীতিটিকে data হিসেবে লিখুন

নীতিগুলো review, test এবং roll back করা সহজ হয় যখন সেগুলো ছড়ানো if statement-এর বদলে data হয়।

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, এবং কোনো rule না-মেলা case-এর জন্য ব্যবহৃত action। এটিকে ইচ্ছাকৃতভাবে বেছে নেওয়া পুরো 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 থেকে request-এ behavior flip হতে দেখে না।

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

একটি route-কে preview-তে move করুন। এখন প্রতিটি request record করবে যে decision সে পেত। এখানেই আপনি বুঝতে পারবেন policy ঠিক কিনা।

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

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

একটি sample হাতে review করুন। বিশটি real request পড়া, যেগুলো policy challenge করত, খুব দ্রুত বোঝায় rule খুব broad কি না।

Exit criterion: would-be restricted set-এ এমন traffic প্রাধান্য পায় যেটিকে আপনি সত্যিই restrict করতে চান, এবং পাওয়া প্রতিটি false positive category-এর ব্যাখ্যা আপনার আছে।

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

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

আপনার baseline হিসেবে নির্ধারিত একই metric-গুলো দেখুন:

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

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

Step 6: ধীরে ধীরে প্রসারিত করুন

slice-টি ধাপে ধাপে বাড়ান, উদাহরণস্বরূপ একটি ছোট share থেকে quarter, তারপর half, তারপর all traffic, প্রতিটি ধাপে যথেষ্ট সময় ধরে রাখুন যাতে একটি normal cycle দেখা যায়। আগের stage-গুলো ঠিকভাবে হয়ে থাকলে expansion boring হওয়ার কথা। সেটাই লক্ষ্য।

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

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

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

কখনও 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-তে set করুন, যা measurement বজায় রেখে enforcement বন্ধ করে।
2. enforcePercent-কে zero-তে set করুন।
3. অন্য rule-গুলো না ছুঁয়ে একটি single rule disable করুন।

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

মানুষের বিষয়ে consequential সিদ্ধান্ত এড়ান

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

enforce করার আগে যোগাযোগ করুন

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

1. Automated access-এর জন্য আপনার rule প্রকাশ করুন। কোন route খোলা, কী limit প্রযোজ্য, এবং client কীভাবে signed request ব্যবহার করে HTTP Message Signatures (RFC 9421) এবং IETF Web Bot Auth protocol draft-এর মাধ্যমে নিজেদের পরিচয় দিতে পারে তা জানান।
2. Partner এবং integrator-দের আগেই জানান। কোনো known integration যদি preview চলাকালে restricted slice-এ পড়ে, enforcement-এর আগে তার owner-কে contact করুন।
3. উপকারী response ফিরিয়ে দিন। কোনো policy request limit বা challenge করলে, 429 Too Many Requests সহ Retry-After-এর মতো clear status code এবং আপনার documentation-এর একটি link দিয়ে respond করুন। 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 খুঁজে পেতে পারে।

যে team পরিবর্তন announce করে এবং ব্যাখ্যা করে, তারা quietly rule বদলানো team-এর তুলনায় অনেক কম surprise পায়, এবং যে client-রা adapt করে তারা সময়ের সাথে সহজে চেনা যায়।

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

• class mix, Unknown rate এবং outcome-এর জন্য baseline record করা হয়েছে।
• Explicit fallback সহ policy data হিসেবে লেখা হয়েছে।
• Preview চালানো হয়েছে, sample review করা হয়েছে, false positive category ব্যাখ্যা করা হয়েছে।
• ছোট slice-এ enforcement শুরু হয়েছে, metric দেখা হয়েছে।
• 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 করুন। Decision flow end to end জানতে How Proof of Actor works পড়ুন।

Sources

• RFC 6585: Additional HTTP Status Codes, Section 4: the 429 Too Many Requests status code
• RFC 9110: HTTP Semantics, Retry-After: telling clients when to retry
• RFC 9457: Problem Details for HTTP APIs: machine-readable error bodies
• RFC 9421: HTTP Message Signatures: how automated clients sign requests
• draft-ietf-webbotauth-httpsig-protocol: IETF Web Bot Auth draft for signed automated traffic (work in progress as of November 2026)