সংবেদনশীল ক্রিয়াগুলো কীভাবে ব্লক না করে সুরক্ষিত রাখবেন

কেন শুধু agent-দের সংবেদনশীল ক্রিয়া থেকে block করে দিই না?

আপনার application-এর কিছু action অন্যগুলোর চেয়ে বেশি গুরুত্বপূর্ণ। password বদলানো, team member যোগ করা, data export করা, project মুছে ফেলা, order approve করা: এগুলোর যেকোনোটি সঠিক authority ছাড়া হলে ক্ষতি বাস্তব হয়।

একই সঙ্গে, আপনার app-এ বৈধ কাজের বড় একটি অংশ automation দিয়ে হয়। একজন user একটি assistant-কে তার settings update করতে বলে। একটি partner integration schedule অনুযায়ী record তৈরি করে। একটি internal agent support ticket file করে। সংবেদনশীল route থেকে প্রতিটি automated client-কে block করলে সেই কাজ ভেঙে যায় এবং মানুষকে manual effort-এ বা এমন workaround-এ ঠেলে দেয় যা সুরক্ষিত করা আরও কঠিন।

উত্তরটি "agent-দের block করুন" বা "agent-দের বিশ্বাস করুন" নয়। এটি এমন একটি model যেখানে action-এর risk, request-এর পেছনের authority এবং actor সম্পর্কে evidence - প্রত্যেকটির আলাদা ভূমিকা থাকে। এই guide সেই model তৈরি করে। এর পেছনের বিস্তৃত চিন্তার জন্য দেখুন মানুষ এবং AI agent-দের জন্য app-level policy কীভাবে ডিজাইন করবেন।

Step 1: আপনার route-গুলোকে risk অনুযায়ী tier করুন

client নয়, action শ্রেণিবদ্ধ করা দিয়ে শুরু করুন। বেশিরভাগ application-এর জন্য একটি সহজ তিন-tier scheme কাজ করে:

route configuration-এ tier লিখে রাখুন, যাতে code review-এ সেটি দেখা যায়:

type Tier = "low" | "medium" | "high";

export const routeTier: Record<string, Tier> = {
  "GET /projects": "low",
  "POST /projects": "medium",
  "POST /projects/:id/members": "medium",
  "POST /account/password": "high",
  "POST /exports": "high",
  "DELETE /projects/:id": "high",
};

Tier ধীরে বদলায় এবং তা নিয়ে reasoning করা সহজ। এই guide-এর বাকি সবকিছু সেখান থেকেই ঝুলে থাকে।

Step 2: identity, credential এবং authorization কীভাবে আলাদা?

তিনটি প্রশ্ন প্রায়ই একসাথে গুলিয়ে যায়:

1. কেউ বা কী action নিচ্ছে? এটি actor evidence: একজন interactive person, AI সহায়তাসহ একজন person, একটি agent, বা Unknown, verified বা declared-এর মতো basis-সহ।
2. কোন credential উপস্থাপন করা হয়েছে? একটি session cookie, একটি API key, একটি OAuth access token।
3. এই credential-টি কি এই resource-এ এই action করার অনুমতি পেয়েছে? এটি authorization।

একটি verified agent signature (RFC 9421) প্রথম প্রশ্নের ভালো উত্তর দেয়। এটি তৃতীয় প্রশ্ন সম্পর্কে কিছু বলে না, আর সেটি বিস্তারিতভাবে আলোচিত হয়েছে signed AI agent request কী প্রমাণ করে, এবং কী করে না-তে। সঠিক scope-সহ একটি OAuth token তৃতীয় প্রশ্নের উত্তর দেয়। এটি প্রথম প্রশ্ন সম্পর্কে সামান্যই বলে। একটি high-tier action-এর জন্য আপনার decision-এ সর্বদা তৃতীয় প্রশ্নের ভালো উত্তর দরকার, এবং প্রথম প্রশ্ন ব্যবহার করা হয় অতিরিক্ত assurance কতটা চাইতে হবে তা বেছে নিতে।

interface Context {
  actor: { actor: "human" | "human_ai" | "agent" | "unknown"; basis: "verified" | "declared" | "inferred" | "unknown" };
  credential: { type: "session" | "oauth" | "api_key"; scopes: string[]; subject: string };
}

function authorized(ctx: Context, action: string, resourceOwner: string): boolean {
  return ctx.credential.subject === resourceOwner && ctx.credential.scopes.includes(action);
}

অনুকূল actor result-এর কারণে authorization কখনো শিথিল করা হয় না। actor context কেবল অতিরিক্ত প্রয়োজন যোগ করে বা সমানভাবে নিরাপদ path-গুলোর মধ্যে বেছে নেয়।

Step 3: মানুষের হয়ে কাজ করা agent-দের জন্য delegated authority ব্যবহার করুন

যখন একটি agent একজন user-এর হয়ে কাজ করে, তখন user-এর session পুনঃব্যবহার করতে দেওয়ার বদলে তাকে নিজস্ব সীমিত authority-সহ credential দিন। OAuth 2.0 হলো মানক tool: user একটি নির্দিষ্ট client-এর জন্য নির্দিষ্ট scope অনুমোদন করে, এবং token-এ সেই client রেকর্ড থাকে। RFC 9700, OAuth 2.0 Security Best Current Practice, এটি নিরাপদভাবে deploy করার উপায় বর্ণনা করে। MCP server-গুলো একই pattern অনুসরণ করে: MCP authorization specification একটি protected MCP server-কে OAuth 2.1 resource server হিসেবে বিবেচনা করে। আমাদের post আপনার MCP server-কে কে কল করছে? tool call-এ এটি প্রয়োগ করে।

এটি সংবেদনশীল ক্রিয়ার জন্য ঠিক যা দরকার তা দেয়:

• token বলে দেয় কোন client কাজ করছে এবং কার হয়ে করছে।
• scope সে কী করতে পারবে তা সীমিত করে। calendar:write-সহ একটি scheduling agent password পরিবর্তন করতে পারে না।
• user নিজের credential না বদলিয়েই grant revoke করতে পারে, এবং OAuth 2.0 Token Revocation (RFC 7009) নির্ধারণ করে কীভাবে client authorization server-কে জানায় যে কোনো token আর valid থাকা উচিত নয়।
• audit log দেখায় যে user নয়, agent action সম্পাদন করেছে।

যদি আপনার app এখনো delegated credential support না করে, তাহলে agent-রা সবচেয়ে বেশি যে action-গুলোর প্রয়োজন হয় সেগুলোর জন্য এটিকে অগ্রাধিকার দিন। automated access-এর জন্য এটি এককভাবে সবচেয়ে কার্যকর control।

Step 4: কখন step-up check চাইবেন?

Step-up মানে কোনো সংবেদনশীল action-এর মুহূর্তে অতিরিক্ত assurance চাওয়া। OAuth-protected API-গুলোর জন্য RFC 9470 নির্ধারণ করে কীভাবে resource server client-কে জানায় যে বর্তমান token-এর authentication যথেষ্ট শক্তিশালী বা যথেষ্ট সাম্প্রতিক নয়। সঠিক step-up নির্ভর করে কে কাজ করছে তার ওপর:

• Interactive person (Human, Human + AI): re-authentication (NIST SP 800-63B-এর reauthentication requirement দেখুন), WebAuthn-এর উপর ভিত্তি করে একটি passkey prompt, বা একটি one-time code।
• Delegated credential-সহ agent: উচ্চ-tier action-এর জন্য dedicated scope, যা user স্পষ্টভাবে অনুমোদন করেছে, অথবা user-কে out of band পাঠানো একটি confirmation।
• Unknown: route-এর বিদ্যমান strong check, অপরিবর্তিত।

type Requirement = "none" | "reauth" | "explicit_scope" | "user_confirmation" | "review";

function stepUp(tier: Tier, ctx: Context): Requirement {
  if (tier !== "high") return "none";
  const { actor } = ctx.actor;
  if (actor === "human" || actor === "human_ai") return "reauth";
  if (actor === "agent" && ctx.credential.type === "oauth") return "explicit_scope";
  if (actor === "agent") return "user_confirmation";
  return "reauth";
}

লক্ষ্য করুন, একটি Human result step-up এড়িয়ে যায় না। এটি interactive person-এর জন্য উপযুক্ত step-up বেছে নেয়। Inference ভুল হতে পারে, তাই সেগুলো check-এর shape বদলাবে, কিন্তু তা সরিয়ে দেবে না।

Step 5: যেখানে judgment দরকার সেখানে human review-এ route করুন

কিছু action বিরল, উচ্চ-প্রভাবের এবং নিরাপদভাবে automate করা কঠিন: customer data-এর bulk export, credential হারানোর পর account recovery, বা একটি organization delete করা। এদের জন্য অনেক সময় যেকোনো automated rule-এর চেয়ে review queue-ই ভালো।

Actor context reviewer-কে evidence দিয়ে review দ্রুত এবং ন্যায্য করে তোলে: class, basis, ব্যবহৃত credential, একই ধরনের request-এর ইতিহাস। Reviewer সিদ্ধান্ত নেয়। Classification কেবল inform করে।

function shouldReview(route: string, ctx: Context): boolean {
  const reviewRoutes = new Set(["POST /exports", "POST /account/recover"]);
  if (!reviewRoutes.has(route)) return false;
  return !(ctx.credential.type === "oauth" && ctx.credential.scopes.includes("export:bulk"));
}

Step 6: tier অনুযায়ী failure behavior নির্বাচন করুন

Actor evaluation timeout হতে পারে বা evidence নাও পেতে পারে। আগে থেকেই নির্ধারণ করুন কী হবে।

• Low tier: fail open। Request স্বাভাবিকভাবে এগোয়।
• Medium tier: normal authorization সক্রিয় রেখে fail open।
• High tier: বিদ্যমান strong check-এ fail closed। অনুপস্থিত actor evidence কখনো protection দুর্বল করে না, এবং এটি এমন request-ও block করে না যা অন্যথায় আপনার normal check পাস করত।

মূল বৈশিষ্ট্য হলো symmetry। Actor evaluation-এ ব্যর্থতা action-টিকে ঠিক আগের মতোই safe এবং ঠিক আগের মতোই available রাখবে, যখন আপনি actor context যোগ করেননি।

Step 7: inference থেকে মানুষের সম্পর্কে পরিণতিমূলক সিদ্ধান্ত নেবেন না

Inferred classification হলো একটি interaction সম্পর্কে evidence, ব্যক্তির সম্পর্কে fact নয়। কেউ job application দেবে কি না, credit decision, exam result, housing, বা essential service-এ access - session automated বা AI-assisted দেখিয়েছে বলে কাউকে তা থেকে বঞ্চিত করবেন না। এই flow-গুলোতে actor context ব্যবহার করুন process বেছে নিতে, যেমন human review বা বিকল্প verification path, এবং নিশ্চিত করুন যে মানুষটি তা সম্পন্ন করতে পারে।

এটি fairness-এর নীতিও, আবার ব্যবহারিকও। Inference-এ false positive থাকে, এবং এই flow-গুলোতে false positive-এর খরচ গিয়ে পড়ে এমন একজনের ওপর, যে কিছুই ভুল করেনি।

Step 8: প্রথমে observation দিয়ে rollout করুন

এগুলোর কোনোটি real request-কে প্রভাবিত করার আগে, observation এবং preview mode-এ চালান:

1. tier, actor class, basis, credential type এবং আপনার policy যে step-up চাইত তা record করুন।
2. class অনুযায়ী high-tier request-এর sample review করুন। বৈধ agent-রা কি delegated credential ব্যবহার করছে, নাকি user session reuse করছে?
3. যে gap-গুলো পাবেন সেগুলো ঠিক করুন, প্রায়ই scoped credential দেওয়ার মাধ্যমে, before you enforce।
4. একটি route-এর ছোট অংশে enforce করুন, completion rate measure করুন, তারপর প্রসারিত করুন।

Step 9: "কী এবং কার হয়ে" - এই প্রশ্নের উত্তর দেয় এমন audit trail রাখুন

প্রতিটি high-tier action-এর জন্য later কী ঘটেছিল তা reconstruct করতে যথেষ্ট record রাখুন:

• request-এর সময় actor class এবং basis,
• credential type, এটি কোন client-কে issue করা হয়েছিল এবং এটি কোন subject-কে উপস্থাপন করে (OAuth 2.0 Token Exchange, RFC 8693, এই ধরনের "acting for" সম্পর্ক রেকর্ড করার জন্য একটি act claim নির্ধারণ করে),
• action-টি যে scope-গুলো authorize করেছে,
• প্রয়োগ করা step-up বা review requirement এবং তার result।

audit.write({
  action: "project.export",
  actor: ctx.actor,
  client: ctx.credential.type === "oauth" ? clientIdFromToken(req) : undefined,
  subject: ctx.credential.subject,
  scopes: ctx.credential.scopes,
  requirement,
  outcome: "approved",
  at: new Date().toISOString(),
});

এই trail থাকলে "একজন person না assistant এই project delete করেছে, এবং কে এটি approve করেছে" - এমন প্রশ্নের স্পষ্ট উত্তর পাওয়া যায়। এতে incident response দ্রুত হয় এবং ব্যবহারকারীরা আত্মবিশ্বাস পান যে আপনার app-এ automated help accountable।

একটি বাস্তব উদাহরণ

একটি project management app দেখতে পায় একটি assistant user-দের task due date update করছে, এবং মাঝে মাঝে পুরো project export করার চেষ্টা করছে।

• Task update করা medium tier। Assistant tasks:write-সহ একটি OAuth token ব্যবহার করে। Authorized, no step-up। Allowed.
• Project export করা high tier। Assistant-এর token-এ export:bulk নেই। App user-কে একটি confirmation request পাঠায়। User approve করে, এবং app সেই client-এর জন্য scope grant করে।
• একটি Unknown client reused session cookie ব্যবহার করে একই export করার চেষ্টা করে। বিদ্যমান re-authentication prompt প্রযোজ্য হয়, ঠিক যেমনটি আগে ছিল।

কেউ agent হওয়ার কারণে block হয়নি। প্রতিটি high-impact action স্পষ্ট authority বহন করেছে।

Proof of Actor কোথায় মানায়

Proof of Actor এই model-এর actor side দেয়: কে বা কী কাজ করছে এবং কোন basis-এ। আপনার application authentication, authorization এবং final decision বজায় রাখে। Actor detect করুন, প্রতিটি class কীভাবে আপনার সংবেদনশীল route ব্যবহার করে তা Understand করুন, এবং প্রতিটি request-কে সঠিক assurance level-এ Route করুন।

আপনার team-এর সঙ্গে আপনার application-এর জন্য এটি design করতে, early access-এর জন্য আবেদন করুন। SaaS scenario আরও বিস্তারিতভাবে জানতে দেখুন SaaS Apps & Websites।

Sources

• RFC 6749: The OAuth 2.0 Authorization Framework: client-দের জন্য scoped, delegated credential
• RFC 9700: Best Current Practice for OAuth 2.0 Security: OAuth deployment-এর জন্য বর্তমান security guidance
• RFC 7009: OAuth 2.0 Token Revocation: user-এর credential পরিবর্তন না করে grant revoke করা
• RFC 9470: OAuth 2.0 Step Up Authentication Challenge Protocol: stronger বা more recent authentication প্রয়োজন তা signal করা
• RFC 8693: OAuth 2.0 Token Exchange: delegation-এর জন্য act (actor) claim
• MCP specification 2026-07-28: Authorization: OAuth 2.1 resource server হিসেবে MCP server
• NIST SP 800-63B: Authentication and Authenticator Management: reauthentication guidance
• W3C Web Authentication (WebAuthn) Level 3: passkey prompt-এর পেছনের standard
• RFC 9421: HTTP Message Signatures: একটি verified agent signature কী স্থাপন করে