সংবেদনশীল কাৰ্যসমূহ ব্লক নকৰাকৈ সৎ agent-সমূহক কেনেকৈ সুৰক্ষিত কৰিব

সংবেদনশীল কাৰ্যসমূহৰ পৰা agent-সমূহক সোজাকৈ block নকৰাৰ কাৰণ কি?

আপোনাৰ application-এ কিছু কাৰ্য আন কিছুমানতকৈ অধিক গুৰুত্বপূর্ণ। Password সলনি কৰা, team member যোগ কৰা, data export কৰা, project মচি পেলোৱা, order approve কৰা: যদি এইবোৰৰ কোনো এটা সঠিক authority অবিহনে ঘটে, ক্ষতি বাস্তৱ।

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

উত্তৰটো "agent block কৰক" বা "agent-ত বিশ্বাস কৰক" নহয়। ই এনে এটা model, য'ত action-ৰ risk, request-ৰ পিছে থকা authority, আৰু actor-ৰ বিষয়ে থকা evidence - এই তিনিটাই পৃথক ভূমিকা পালন কৰে। এই guide-এ সেই model গঢ়ে। ইয়াৰ পিছে থকা বিস্তৃত চিন্তাধাৰাৰ বাবে, humans আৰু AI agent-সমূহৰ বাবে app-level policy design কৰা চাওক।

Step 1: আপোনাৰ route-সমূহ risk অনুসাৰে স্তৰভিত্তিক কৰক

Client নহয়, action-সমূহৰ পৰা আৰম্ভ কৰক। এটা সৰল তিনিটা স্তৰৰ scheme অধিকাংশ application-ৰ বাবে কাম কৰে:

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-সমূহ ধীৰে সলনি হয় আৰু সেয়া বুজিবলৈ সহজ। এই guide-ৰ বাকি সকলো সিহঁতৰ ওপৰত নিৰ্ভৰ কৰে।

Step 2: Identity, credentials আৰু authorization কেনেকৈ পৃথক?

সাধাৰণতে তিনিটা প্ৰশ্ন একেলগে গণ্ডগোল হয়:

1. কোন বা কি acting কৰিছে? এয়া actor evidence: এজন interactive ব্যক্তি, AI সহায়ৰ সৈতে এজন ব্যক্তি, এজন agent, বা Unknown, verified বা declared-ৰ দৰে basis-সহ।
2. কোন credential present কৰা হৈছিল? এটা 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);
}

A favorable actor result-ৰ বাবে authorization কেতিয়াও relax কৰা নহয়। Actor context-এ কেৱল requirement যোগ কৰে বা সমানভাৱে নিৰাপদ path-সমূহৰ মাজত বাছনি কৰে।

Step 3: Agent-এ মানুহৰ হৈ কাম কৰিলে delegated authority ব্যৱহাৰ কৰক

যেতিয়া এটা agent-এ এজন user-ৰ হৈ কাম কৰে, user-ৰ session পুনৰ ব্যৱহাৰ কৰিবলৈ নিদি, সীমিত authority থকা নিজৰ credential দিয়ক। OAuth 2.0 হৈছে standard tool: user-এ কোনো specific client-ৰ বাবে specific scope অনুমোদন কৰে, আৰু token-এ সেই client-টোক record কৰে। 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-লৈ কোন call কৰিছে?-এ ইয়াক tool call-লৈ প্ৰয়োগ কৰে।

ইয়াৰ ফলত আপোনাক সংবেদনশীল কাৰ্যৰ বাবে ঠিক যিটো লাগে সেয়াই পোৱা যায়:

• Token-এ আপোনাক কোন client acting কৰিছে আৰু কাৰ হৈ সেইটো কয়।
• Scope-এ ই কি কৰিব পাৰে সেয়া সীমিত কৰে। calendar:write থকা এটা scheduling agent-এ password সলনি কৰিব নোৱাৰে।
• User-এ নিজৰ credential সলনি নকৰাকৈ grant revoke কৰিব পাৰে, আৰু OAuth 2.0 Token Revocation (RFC 7009)-এ token আৰু বৈধ নাথাকিব বুলি authorization server-লৈ client-এ কেনেকৈ কয় সেয়া সংজ্ঞায়িত কৰে।
• Audit log-সমূহে দেখুৱায় যে agent-এ, user-এ নহয়, কাৰ্যটো কৰিছিল।

যদি আপোনাৰ app-এ এতিয়াও delegated credentials support নকৰে, agent-এ সঘনাই যি action-ৰ প্ৰয়োজন হয় তাৰ বাবে ইয়াক অগ্ৰাধিকাৰ দিয়ক। Automated access-ৰ বাবে এয়াই এককভাৱে আটাইতকৈ কার্যকৰী control।

Step 4: কেতিয়া আপুনি step-up check বিচাৰিব?

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

• Interactive ব্যক্তি (Human, Human + AI): re-authentication (NIST SP 800-63B-ৰ reauthentication requirements চাওক), WebAuthn-ৰ ওপৰত নিৰ্মিত passkey prompt, বা one-time code।
• Delegated credential থকা agent: high-tier action-ৰ বাবে নিবেদিত এটা scope, user-এ স্পষ্টভাৱে অনুমোদন কৰা, বা out of band user-লৈ পঠিওৱা confirmation।
• Unknown: route-ৰ বিদ্যমান শক্তিশালী 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 skip নকৰে। ই interactive ব্যক্তি-ৰ বাবে উপযোগী step-up বাছনি কৰে। Inference ভুল হ'ব পাৰে, সেয়ে ই check-ৰ আকৃতি সলনি কৰিব লাগে, তাক আঁতৰাব নালাগে।

Step 5: বিচাৰ-বিবেচনা লাগে তেনে ঠাইত human review-লৈ route কৰক

কিছুমান action বিৰল, উচ্চ-প্ৰভাৱৰ, আৰু সুৰক্ষিতভাৱে automation কৰা কঠিন: customer data-ৰ bulk export, credentials হেৰালে account recovery, বা এটা organization delete কৰা। এইবোৰৰ বাবে review queue সঘনাই কোনো automated rule-তকৈ উত্তম।

Actor context-এ reviewer-লৈ evidence দি review-টো অধিক সোনকালে আৰু ন্যায়সংগত কৰে: class, basis, ব্যৱহৃত credential, একেধৰণৰ request-ৰ ইতিহাস। Reviewer-এ সিদ্ধান্ত লয়। Classification-এ তথ্য দিয়ে।

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 আচৰণ বাছনি কৰক

Actor evaluation timeout হ'ব পাৰে বা evidence নাথাকিব পাৰে। আগতেই নিৰ্ণয় কৰক কি হ'ব।

• Low tier: fail open. Request সাধাৰণভাৱে আগবাঢ়ে।
• Medium tier: fail open, আৰু normal authorization বহাল থাকে।
• High tier: বিদ্যমান শক্তিশালী check-লৈ fail closed. Actor evidence-ৰ অভাৱে কেতিয়াও protection দুৰ্বল নকৰে, আৰু ই সেই request-টো ব্লকও নকৰে যি অন্যথা আপোনাৰ normal checks পাৰ হতেহেঁতেন।

মূল গুণটো হৈছে symmetry। Actor evaluation-ৰ failure-এ action-টোক ঠিক সিমানেই safe, আৰু ঠিক সিমানেই available, ৰাখিব লাগে, যিমানটা actor context যোগ কৰাৰ আগতে আছিল।

Step 7: Inference-ৰ ওপৰত মানুহৰ বিষয়ে ফলপ্ৰসূ সিদ্ধান্ত নল'ব

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

এয়া fairness principle আৰু practical principle দুয়োটাই। Inference-ত false positive থাকে, আৰু এই flow-সমূহত false positive-ৰ খৰচ কাৰোবাৰ ওপৰত পৰে যি একো ভুল কৰা নাছিল।

Step 8: প্ৰথমে observation-ৰ সৈতে rollout কৰক

ইয়াৰ কোনো অংশই বাস্তৱ request-ত প্ৰভাৱ পেলোৱাৰ আগতে, observation আৰু preview mode-ত চালাওক:

1. Tier, actor class, basis, credential type, আৰু আপোনাৰ policy-এ যি step-up বিচাৰিব সেয়া record কৰক।
2. Class অনুসাৰে high-tier request-ৰ sample পৰ্যালোচনা কৰক। Legitimate agent-সমূহে delegated credentials ব্যৱহাৰ কৰিছে নে user session পুনৰ ব্যৱহাৰ কৰিছে?
3. Enforce কৰাৰ আগতে, আপুনি বিচাৰি পোৱা gap-সমূহ ঠিক কৰক, সঘনাই scoped credential আগবঢ়াই।
4. এটা single route-ৰ সৰু অংশত enforce কৰক, completion rate measure কৰক, তাৰ পিছত বিস্তাৰ কৰক।

Step 9: "কোন আৰু কাৰ হৈ" সেয়া উত্তৰ দিব পৰা audit trail ৰাখক

প্ৰতিটো high-tier action-ৰ বাবে, পিছত কি হৈছিল সেয়া পুনর্গঠন কৰিবলৈ যথেষ্ট তথ্য record কৰক:

• request-ৰ মুহূৰ্তত actor class আৰু basis,
• credential type, যাক ই issue কৰা হৈছিল সেই client, আৰু ই যাক represent কৰে সেই subject (OAuth 2.0 Token Exchange, RFC 8693, -এ একে ধৰণৰ "acting for" relationship record কৰাৰ বাবে এটা act claim সংজ্ঞায়িত কৰে),
• action authorize কৰা scope-সমূহ,
• প্ৰয়োগ কৰা 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-সহ, "এজন ব্যক্তি বা assistant-এ এই project delete কৰিলে নে, আৰু কোনে approve কৰিলে" ধৰণৰ প্ৰশ্নৰ স্পষ্ট উত্তৰ থাকে। সেয়া incident response দ্রুত কৰে আৰু আপোনাৰ app-ত automated help accountable বুলি user-সকলক confidence দিয়ে।

এটা কাৰ্যকৰ উদাহৰণ

এটা project management app-এ task due date user-সকলৰ বাবে assistant-এ update কৰা দেখে, আৰু মাজে মাজে সমগ্ৰ project export কৰিবলৈ চেষ্টা কৰা দেখে।

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

Agent হোৱা বাবে কাকো block কৰা হোৱা নাছিল। প্ৰতিটো উচ্চ-প্ৰভাৱৰ action-এ স্পষ্ট authority বহন কৰিছিল।

Proof of Actor ক'ত খাপ খায়

Proof of Actor-এ এই model-ৰ actor দিশটো দিয়ে: কোন বা কি acting কৰিছে আৰু কোন basis-ত। আপোনাৰ application-এ authentication, authorization আৰু চূড়ান্ত সিদ্ধান্ত ৰাখে। Actor detect কৰক, প্ৰতিটো class-এ আপোনাৰ সংবেদনশীল route-সমূহ কেনেকৈ ব্যৱহাৰ কৰে সেইটো Understand কৰক, আৰু প্ৰতিটো request-ক উপযুক্ত assurance স্তৰলৈ Route কৰক।

আমাৰ team-ৰ সৈতে আপোনাৰ application-ৰ বাবে ইয়াক design কৰিবলৈ, early access-ৰ বাবে আবেদন কৰক। অধিক বিস্তৃত SaaS scenario-ৰ বাবে, SaaS Apps & Websites চাওক।

উৎসসমূহ

• RFC 6749: The OAuth 2.0 Authorization Framework: client-সমূহৰ বাবে scoped, delegated credentials
• 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: অধিক শক্তিশালী বা অধিক সাম্প্ৰতিক authentication প্ৰয়োজন বুলি সংকেত দিয়া
• RFC 8693: OAuth 2.0 Token Exchange: delegation-ৰ বাবে act (actor) claim
• MCP specification 2026-07-28: Authorization: MCP server-সমূহক OAuth 2.1 resource 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 কি স্থাপন কৰে