ସଂବେଦନଶୀଳ କାର୍ଯ୍ୟଗୁଡ଼ିକୁ ବୈଧ ଏଜେଣ୍ଟମାନଙ୍କୁ ବନ୍ଦ କରିନାହିଁ କିପରି ସୁରକ୍ଷିତ କରିବେ

କାହିଁକି କେବଳ agent ମାନଙ୍କୁ ସଂବେଦନଶୀଳ କାର୍ଯ୍ୟରୁ block କରି ଦେବେ ନାହିଁ?

ଆପଣଙ୍କ application ଭିତରେ କିଛି କାର୍ଯ୍ୟ ଅନ୍ୟମାନଙ୍କଠାରୁ ଅଧିକ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ। password ପରିବର୍ତ୍ତନ, team member ଯୋଡ଼ିବା, data export, project delete କରିବା, order approve କରିବା: ଯଦି ଏଗୁଡ଼ିକର କୌଣସିଟି ଠିକ୍ authority ବିନା ଘଟେ, କ୍ଷତି ସତ୍ୟ ହୋଇଥାଏ।

ସେହି ସମୟରେ, ଆପଣଙ୍କ app ଭିତରେ ବୈଧ କାମର ଅଧିକାଂଶ automation ଦ୍ୱାରା କରାଯାଉଛି। ଏକ user assistant କୁ ନିଜ settings update କରିବାକୁ କହେ। ଏକ partner integration schedule ଅନୁସାରେ record ସୃଷ୍ଟି କରେ। ଏକ internal agent support ticket file କରେ। ସମସ୍ତ automated client କୁ ସଂବେଦନଶୀଳ route ଠାରୁ block କରିଲେ ଏହି କାମ ଭାଙ୍ଗିଯାଏ ଏବଂ ଲୋକମାନଙ୍କୁ manual effort କିମ୍ବା ସୁରକ୍ଷିତ କରିବାକୁ କଠିନ workaround ଦିଗରେ ଠେଲିଦିଏ।

ଉତ୍ତରଟି "agent ମାନଙ୍କୁ block କରନ୍ତୁ" କିମ୍ବା "agent ମାନଙ୍କୁ trust କରନ୍ତୁ" ନୁହେଁ। ଏହା ଏକ ଏମିତି model ଯେଉଁଠି କାର୍ଯ୍ୟର risk, request ପଛର authority ଏବଂ actor ବିଷୟରେ evidence ପ୍ରତ୍ୟେକଟିର ଅଲଗା ଭୂମିକା ରହେ। ଏହି guide ସେହି model ଗଢ଼େ। ଏହାର ପଛର ବିସ୍ତୃତ ଚିନ୍ତାଧାରା ପାଇଁ, humans ଏବଂ AI agents ପାଇଁ app-level policy କିପରି design କରିବେ ଦେଖନ୍ତୁ।

ପଦକ୍ଷେପ 1: route ଗୁଡ଼ିକୁ risk ଅନୁସାରେ tier କରନ୍ତୁ

client ନୁହେଁ, କାର୍ଯ୍ୟଗୁଡ଼ିକୁ ଶ୍ରେଣୀବଦ୍ଧ କରି ଆରମ୍ଭ କରନ୍ତୁ। ଏକ ସରଳ three-tier 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 ଭିତରେ ଅନ୍ୟ ସବୁ କଥା ଏହି tier ଗୁଡ଼ିକରେ ଭିତ୍ତି କରେ।

ପଦକ୍ଷେପ 2: identity, credential ଏବଂ authorization କିପରି ଭିନ୍ନ?

ତିନୋଟି ପ୍ରଶ୍ନ ପ୍ରାୟତଃ ଏକାତ୍ମ ହୋଇଯାଏ:

1. କିଏ କିମ୍ବା କ'ଣ କାର୍ଯ୍ୟ କରୁଛି? ଏହା actor evidence: ଜଣେ ନିଜେ interative person, AI ସହାୟତା ସହିତ ଜଣେ person, ଜଣେ agent, କିମ୍ବା Unknown, ଯାହାର basis verified କିମ୍ବା declared ପରି।
2. କେଉଁ credential ପ୍ରଦର୍ଶିତ ହେଲା? session cookie, API key, OAuth access token।
3. ଏହି credential କୁ ଏହି resource ଉପରେ ଏହି କାର୍ଯ୍ୟ କରିବାକୁ ଅନୁମତି ଅଛି କି? ଏହା authorization।

ଏକ verified agent signature (RFC 9421) ପ୍ରଥମ ପ୍ରଶ୍ନକୁ ଭଲ ଭାବରେ ଉତ୍ତର ଦିଏ। ଏହା ତୃତୀୟ ପ୍ରଶ୍ନ ବିଷୟରେ କିଛି କୁହେନାହିଁ, ଯାହା signed AI agent request ଗୁଡ଼ିକ କଣ ପ୍ରମାଣ କରେ, ଏବଂ କଣ କରେନାହିଁ ଭିତରେ ବିସ୍ତୃତ ଭାବେ ଆଲୋଚିତ। ଠିକ୍ scope ସହିତ ଏକ OAuth token ତୃତୀୟ ପ୍ରଶ୍ନକୁ ଉତ୍ତର ଦିଏ। ଏହା ପ୍ରଥମ ପ୍ରଶ୍ନ ବିଷୟରେ ଅଳ୍ପ କୁହେ। ଉଚ୍ଚ-tier କାର୍ଯ୍ୟ ପାଇଁ ଆପଣଙ୍କ ନିଷ୍ପତ୍ତିକୁ ସଦା ତୃତୀୟ ପ୍ରଶ୍ନର ଭଲ ଉତ୍ତର ଆବଶ୍ୟକ, ଏବଂ ପ୍ରଥମକୁ ବ୍ୟବହାର କରି କେତେ ଅଧିକ 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 ମଧ୍ୟରୁ ବାଛେ।

ପଦକ୍ଷେପ 3: People ପାଇଁ କାମ କରୁଥିବା agent ମାନଙ୍କୁ delegated authority ବ୍ୟବହାର କରନ୍ତୁ

ଯେତେବେଳେ ଜଣେ agent ଜଣେ user ପକ୍ଷରୁ କାମ କରେ, user ଙ୍କ session ପୁନଃବ୍ୟବହାର କରିବା ପରିବର୍ତ୍ତେ ତାକୁ ସୀମିତ authority ସହିତ ନିଜ credential ଦିଅନ୍ତୁ। OAuth 2.0 ସାଧାରଣ tool: user ନିର୍ଦ୍ଦିଷ୍ଟ client ପାଇଁ ନିର୍ଦ୍ଦିଷ୍ଟ scope ମାନେ approve କରନ୍ତି, ଏବଂ 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 ପରି ଧରେ। ଆମ ପୋଷ୍ଟ ଆପଣଙ୍କ MCP server କୁ କିଏ call କରୁଛି? ଏହାକୁ 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 ଦେଖାଏ ଯେ agent, user ନୁହେଁ, କାର୍ଯ୍ୟ କରିଥିଲା।

ଯଦି ଆପଣଙ୍କ app ଏଯାବତ୍ delegated credential support କରେନାହିଁ, agent ମାନଙ୍କୁ ସର୍ବାଧିକ ଯାହା ଆବଶ୍ୟକ ସେଇ କାର୍ଯ୍ୟ ପାଇଁ ଏହାକୁ ପ୍ରାଥମିକତା ଦିଅନ୍ତୁ। Automated access ପାଇଁ ଏହା ଏକମାତ୍ର ସର୍ବାଧିକ ପ୍ରଭାବଶାଳୀ control।

ପଦକ୍ଷେପ 4: step-up check କେବେ ଚାହିବେ?

Step-up ର ଅର୍ଥ ସଂବେଦନଶୀଳ କାର୍ଯ୍ୟର ମୁହୂର୍ତ୍ତରେ ଅତିରିକ୍ତ assurance ଚାହିବା। OAuth-protected API ପାଇଁ, RFC 9470 କିପରି resource server client କୁ କୁହେ ଯେ ବର୍ତ୍ତମାନର token ର authentication ପର୍ଯ୍ୟାପ୍ତ ଶକ୍ତିଶାଳୀ କିମ୍ବା ପର୍ଯ୍ୟାପ୍ତ recent ନୁହେଁ, ତାହା ପରିଭାଷା କରେ। ଠିକ୍ step-up କିଏ କାର୍ଯ୍ୟ କରୁଛି ତାହାରୁ ନିର୍ଭର କରେ:

• Interactive person (Human, Human + AI): ପୁନଃ authentication (ଦେଖନ୍ତୁ NIST SP 800-63B ଭିତରେ reauthentication ଆବଶ୍ୟକତା), WebAuthn ଉପରେ ନିର୍ମିତ passkey prompt, କିମ୍ବା one-time code।
• Delegated credential ସହିତ agent: ଉଚ୍ଚ-tier କାର୍ଯ୍ୟ ପାଇଁ ନିର୍ଦ୍ଦିଷ୍ଟ scope, user ଦ୍ୱାରା ସ୍ପଷ୍ଟଭାବେ granted, କିମ୍ବା out of band ଭାବେ user କୁ ପଠାଯାଇଥିବା confirmation।
• Unknown: route ର ବର୍ତ୍ତମାନର strong check, unchanged.

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 person ପାଇଁ ଯୋଗ୍ୟ step-up ବାଛେ। Inference ଭୁଲ ହୋଇପାରେ, ସେଥିପାଇଁ ସେଗୁଡ଼ିକ check ର ଆକୃତି ପରିବର୍ତ୍ତନ କରିବା ଉଚିତ୍, ଏହାକୁ ହଟାଇବା ନୁହେଁ।

ପଦକ୍ଷେପ 5: ଯେଉଁଠି judgment ଆବଶ୍ୟକ, ସେଠାରେ human review କୁ route କରନ୍ତୁ

କିଛି କାର୍ଯ୍ୟ ଦୁର୍ଲଭ, ଉଚ୍ଚ-ପ୍ରଭାବୀ ଏବଂ ସୁରକ୍ଷିତ ଭାବେ automate କରିବା କଠିନ: customer data ର bulk export, lost credential ପରେ account recovery, କିମ୍ବା organization delete କରିବା। ଏଗୁଡ଼ିକ ପାଇଁ, କୌଣସି automated rule ଠାରୁ ମଧ୍ୟ review queue ଅଧିକ ଭଲ ହୋଇପାରେ।

Actor context reviewer କୁ evidence ଦେଇ review କୁ ଶୀଘ୍ର ଏବଂ ନ୍ୟାୟସଙ୍ଗତ କରେ: class, basis, ବ୍ୟବହୃତ credential, ସମାନ request ର history। 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"));
}

ପଦକ୍ଷେପ 6: tier ଅନୁସାରେ failure behavior ବାଛନ୍ତୁ

Actor evaluation timeout ହୋଇପାରେ କିମ୍ବା evidence ନଥାଇପାରେ। ପୂର୍ବରୁ ନିଷ୍ପତ୍ତି କରନ୍ତୁ କ’ଣ ହେବ।

• କମ୍ tier: fail open. Request ସାଧାରଣଭାବେ ଆଗକୁ ବଢ଼େ।
• ମଧ୍ୟମ tier: fail open, ସାଧାରଣ authorization ସହିତ ଚାଲୁ ରହେ।
• ଉଚ୍ଚ tier: ଏହାକୁ ବର୍ତ୍ତମାନର strong check କୁ fail closed କରନ୍ତୁ। ଅନୁପସ୍ଥିତ actor evidence ସୁରକ୍ଷାକୁ କେବେ ମଧ୍ୟ ଦୁର୍ବଳ କରେନାହିଁ, ଏବଂ ଏହା କେବେ ମଧ୍ୟ ଏମିତି request କୁ block କରେନାହିଁ ଯାହା ନହେଲେ ଆପଣଙ୍କ ସାଧାରଣ check ଉପରେ pass ହୋଇଥାନ୍ତା।

ମୁଖ୍ୟ property symmetry। Actor evaluation ର failure action କୁ ସେଇପରି ସୁରକ୍ଷିତ ରଖିବା ଉଚିତ୍, ଏବଂ ସେଇପରି available, ଯେପରି actor context ଯୋଡ଼ିବା ପୂର୍ବରୁ ଥିଲା।

ପଦକ୍ଷେପ 7: Inference ଠାରୁ people ବିଷୟରେ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ ନିଷ୍ପତ୍ତି ନିଅନ୍ତୁ ନାହିଁ

ଏକ inferred classification interaction ବିଷୟରେ evidence, person ବିଷୟରେ fact ନୁହେଁ। କାହାର job application, credit decision, exam result, housing କିମ୍ବା essential service ର access କୁ deny କରନ୍ତୁ ନାହିଁ କେବଳ session automated କିମ୍ବା AI-assisted ପରି ଦେଖାଗଲା ବୋଲି। ସେହି flow ଗୁଡ଼ିକରେ, actor context ବ୍ୟବହାର କରି human review କିମ୍ବା alternative verification path ପରି process ବାଛନ୍ତୁ, ଏବଂ person ସେହି process ସମାପ୍ତ କରିପାରିବେ ବୋଲି ନିଶ୍ଚିତ କରନ୍ତୁ।

ଏହା fairness principle ମଧ୍ୟ ଏବଂ practical ମଧ୍ୟ। Inference ର false positive ଥାଏ, ଏବଂ ଏହି flow ମାନେର false positive ର cost ସେହି ଲୋକ ଉପରେ ପଡ଼େ ଯିଏ କିଛି ଭୁଲ କରିନାହାନ୍ତି।

ପଦକ୍ଷେପ 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 ପୁନଃବ୍ୟବହାର କରୁଛନ୍ତି?
3. ଆପଣ ଯେ gap ଖୋଜନ୍ତି ସେଗୁଡ଼ିକ ସମାଧାନ କରନ୍ତୁ, ପ୍ରାୟତଃ scoped credential ପ୍ରଦାନ କରି, ତାପରେ enforce କରନ୍ତୁ।
4. ଗୋଟିଏ route ର ଛୋଟ ଅଂଶରେ enforce କରନ୍ତୁ, completion rate ମାପନ୍ତୁ, ତାପରେ ବିସ୍ତାର କରନ୍ତୁ।

ପଦକ୍ଷେପ 9: "କିଏ ଏବଂ କାହା ପକ୍ଷରୁ" ଉତ୍ତର ଦେଇପାରୁଥିବା audit trail ରଖନ୍ତୁ

ପ୍ରତ୍ୟେକ high-tier କାର୍ଯ୍ୟ ପାଇଁ, ପରେ କ’ଣ ଘଟିଲା ତାହା ପୁନଃନିର୍ମାଣ କରିବାକୁ ପର୍ଯ୍ୟାପ୍ତ record କରନ୍ତୁ:

• request ସମୟର actor class ଏବଂ basis,
• credential type, ଯେ client କୁ ଏହା issue ହୋଇଥିଲା ଏବଂ ଯେ subject କୁ ଏହା ପ୍ରତିନିଧିତ୍ୱ କରେ (OAuth 2.0 Token Exchange, RFC 8693, exactly ଏହି ପ୍ରକାରର "acting for" relationship record କରିବା ପାଇଁ ଏକ act claim ପରିଭାଷା କରେ),
• କାର୍ଯ୍ୟକୁ authorization ଦେଇଥିବା scope,
• ଲାଗୁ ହୋଇଥିବା step-up କିମ୍ବା review ଆବଶ୍ୟକତା ଏବଂ ଏହାର 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 ସହିତ, "ଏହି project କୁ କିଏ ଡିଲିଟ୍ କଲା, ଜଣେ person କି assistant, ଏବଂ କିଏ ଏହା approve କଲା" ପରି ପ୍ରଶ୍ନର ସ୍ପଷ୍ଟ ଉତ୍ତର ମିଳେ। ଏହା incident response କୁ ଶୀଘ୍ର କରେ ଏବଂ user ମାନଙ୍କୁ ନିଶ୍ଚିତତା ଦେଇଥାଏ ଯେ ଆପଣଙ୍କ 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, କୌଣସି step-up ନାହିଁ। Allowed.
• Project export କରିବା high tier। Assistant ର token ରେ export:bulk ନାହିଁ। App user କୁ confirmation request ପଠାଏ। User approve କରନ୍ତି, ଏବଂ app ସେ client ପାଇଁ scope grant କରେ।
• ଏକ Unknown client ପୁନଃବ୍ୟବହୃତ session cookie ସହିତ ସମାନ export ଚେଷ୍ଟା କରେ। ବର୍ତ୍ତମାନର re-authentication prompt ଲାଗୁ ହୁଏ, ଠିକ୍ ପୂର୍ବବତ୍।

କେହି ମଧ୍ୟ agent ଥିବାରୁ block ହେଲେ ନାହିଁ। ପ୍ରତ୍ୟେକ ଉଚ୍ଚ-ପ୍ରଭାବୀ କାର୍ଯ୍ୟ ସ୍ପଷ୍ଟ authority ସହିତ ଥିଲା।

Proof of Actor କେଉଁଠି fit ହୁଏ

Proof of Actor ଏହି model ର actor ପକ୍ଷ ଯୋଗାଇଥାଏ: କିଏ କିମ୍ବା କ'ଣ କାର୍ଯ୍ୟ କରୁଛି ଏବଂ କେଉଁ basis ଉପରେ। ଆପଣଙ୍କ application authentication, authorization ଏବଂ final decision ରଖେ। Actor କୁ Detect କରନ୍ତୁ, ପ୍ରତ୍ୟେକ class ଆପଣଙ୍କ ସଂବେଦନଶୀଳ route ଗୁଡ଼ିକୁ କିପରି ବ୍ୟବହାର କରେ ତାହା Understand କରନ୍ତୁ, ଏବଂ ପ୍ରତ୍ୟେକ request କୁ ଠିକ୍ assurance level କୁ Route କରନ୍ତୁ।

ଆମ ଟିମ୍ ସହିତ ଆପଣଙ୍କ application ପାଇଁ ଏହା design କରିବାକୁ, early access ପାଇଁ apply କରନ୍ତୁ। SaaS scenario ବିଷୟରେ ଅଧିକ detail ପାଇଁ, SaaS Apps & Websites ଦେଖନ୍ତୁ।

ଉତ୍ସ

• 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: ଶକ୍ତିଶାଳୀ କିମ୍ବା ଅଧିକ recent authentication ଆବଶ୍ୟକ ବୋଲି ସଙ୍କେତ ଦେବା
• 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 କ'ଣ established କରେ