സെൻസിറ്റീവ് പ്രവർത്തനങ്ങളെ സാധുവായ ഏജന്റുകളെ തടയാതെ എങ്ങനെ സംരക്ഷിക്കാം

സെൻസിറ്റീവ് പ്രവർത്തനങ്ങളിൽ ഏജന്റുകളെ നേരിട്ട് ബ്ലോക്ക് ചെയ്യാതിരിക്കാൻ എന്തുകൊണ്ട്?

നിങ്ങളുടെ application-ലുള്ള ചില പ്രവർത്തനങ്ങൾ മറ്റുള്ളവയെക്കാൾ കൂടുതൽ പ്രധാനമാണ്. പാസ്‌വേഡ് മാറ്റുക, ടീം അംഗത്തെ ചേർക്കുക, data export ചെയ്യുക, ഒരു project delete ചെയ്യുക, ഒരു order അംഗീകരിക്കുക: ഇവയിൽ ഏതെങ്കിലും ശരിയായ അധികാരമില്ലാതെ സംഭവിച്ചാൽ നാശം യഥാർത്ഥമാണ്.

അതേസമയം, നിങ്ങളുടെ app-ൽ നടക്കുന്ന സാധുവായ ജോലികളുടെ ഒരു വലിയ പങ്കും automation ആണ് ചെയ്യുന്നത്. ഒരു user ഒരു assistant-നോട് തന്റെ settings പുതുക്കാൻ പറയുന്നു. ഒരു partner integration നിശ്ചിത ഷെഡ്യൂളിൽ records സൃഷ്ടിക്കുന്നു. ഒരു internal agent support tickets ഫയൽ ചെയ്യുന്നു. സെൻസിറ്റീവ് routes-ലേക്കുള്ള എല്ലാ automated client-കളെയും ബ്ലോക്ക് ചെയ്യുന്നത് ആ ജോലി തകർക്കുകയും ആളുകളെ വീണ്ടും manual effort-ലേക്കോ, സുരക്ഷിതമാക്കാൻ കൂടുതൽ ബുദ്ധിമുട്ടുള്ള workarounds-ലേക്കോ തള്ളുകയും ചെയ്യുന്നു.

ഉത്തരം "agents-നെ block ചെയ്യുക" അല്ലെങ്കിൽ "agents-നെ trust ചെയ്യുക" എന്നതല്ല. പ്രവർത്തിയുടെ risk, request-ന്റെ പിന്നിലുള്ള authority, actor-നെക്കുറിച്ചുള്ള evidence എന്നിവ ഓരോന്നും വ്യത്യസ്ത പങ്ക് വഹിക്കുന്ന ഒരു മാതൃകയാണ്. ഈ guide ആ മാതൃക നിർമ്മിക്കുന്നു. ഇതിന്റെ വിശാലമായ ചിന്തയ്ക്ക്, humans-നെയും AI agents-നെയും 위한 app-level policies രൂപകൽപ്പന ചെയ്യുന്നത് കാണുക.

Step 1: നിങ്ങളുടെ routes-നെ അപകടസാധ്യതപ്രകാരം പാളികളാക്കുക

Clients-നല്ല, actions-നെ classification ചെയ്യുന്നതിൽ നിന്ന് തുടങ്ങുക. കൂടുതൽ applications-ക്കും ലളിതമായ മൂന്ന്-പാളി പദ്ധതി മതിയാകും:

കോട് review-ൽ കാണാൻ കഴിയുന്ന രീതിയിൽ tier route configuration-ലേക്ക് എഴുതുക:

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. ആരാണ് അല്ലെങ്കിൽ എന്താണ് പ്രവർത്തിക്കുന്നത്? ഇത് 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 requests എന്താണ് തെളിയിക്കുന്നത്, എന്തല്ല എന്നിടത്ത് ഇത് വിശദമായി ഉൾക്കൊള്ളുന്നു. ശരിയായ scope ഉള്ള ഒരു OAuth token മൂന്നാമത്തെ ചോദ്യത്തിന് മറുപടി നൽകുന്നു. അത് ആദ്യ ചോദ്യത്തെക്കുറിച്ച് അധികം പറയുന്നില്ല. High-tier പ്രവർത്തനത്തിനുള്ള നിങ്ങളുടെ തീരുമാനത്തിന് മൂന്നാമത്തെ ചോദ്യത്തിന് നല്ല മറുപടി എപ്പോഴും ആവശ്യമാണ്, കൂടാതെ ആദ്യത്തെ ചോദ്യം അധിക ഉറപ്പ് എത്ര ചോദിക്കണം എന്നത് തിരഞ്ഞെടുക്കാൻ ഉപയോഗിക്കുന്നു.

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 ഫലം അനുകൂലമായതിനാൽ authorization ഒരിക്കലും ഇളവ് ചെയ്യില്ല. Actor context അധിക ആവശ്യങ്ങൾ ചേർക്കുകയോ, സമാനമായി സുരക്ഷിതമായ വഴികളിൽ ഒന്നിനെ തിരഞ്ഞെടുക്കുകയോ മാത്രമാണ് ചെയ്യുന്നത്.

Step 3: ആളുകൾക്കായി പ്രവർത്തിക്കുന്ന ഏജന്റുകൾക്ക് delegated authority ഉപയോഗിക്കുക

ഒരു agent ഒരു user-ന്റെ പേരിൽ പ്രവർത്തിക്കുമ്പോൾ, user-ന്റെ session വീണ്ടും ഉപയോഗിക്കാൻ അനുവദിക്കുന്നതിന് പകരം അതിന് പരിമിത authority ഉള്ള സ്വന്തം credential നൽകുക. OAuth 2.0 ആണ് സാധാരണ ഉപകരണം: user ഒരു പ്രത്യേക client-ക്ക് പ്രത്യേക scopes അംഗീകരിക്കുന്നു, token ആ client-നെ രേഖപ്പെടുത്തുന്നു. RFC 9700, OAuth 2.0 Security Best Current Practice, ഇത് സുരക്ഷിതമായി വിന്യസിക്കുന്നത് എങ്ങനെ എന്നത് വിശദീകരിക്കുന്നു. MCP servers ഇതേ മാതൃക പിന്തുടരുന്നു: MCP authorization specification ഒരു protected MCP server-നെ OAuth 2.1 resource server ആയി കണക്കാക്കുന്നു. ഞങ്ങളുടെ നിങ്ങളുടെ MCP server-ിലേക്ക് ആരാണ് വിളിക്കുന്നത്? എന്ന post tool calls-ലേക്ക് ഇത് പ്രയോഗിക്കുന്നു.

ഇത് സെൻസിറ്റീവ് പ്രവർത്തനങ്ങൾക്ക് നിങ്ങൾക്ക് വേണ്ടത് കൃത്യമായി നൽകുന്നു:

• Token ഏത് client ആണ് പ്രവർത്തിക്കുന്നത്, ആരുടെ പേരിലാണ് എന്ന് പറയുന്നു.
• Scopes അതിന് ചെയ്യാൻ കഴിയുന്നത് പരിമിതപ്പെടുത്തുന്നു. calendar:write ഉള്ള ഒരു scheduling agent പാസ്‌വേഡ് മാറ്റാൻ കഴിയില്ല.
• User സ്വന്തം credentials മാറ്റാതെ grant revoke ചെയ്യാൻ കഴിയും, കൂടാതെ OAuth 2.0 Token Revocation (RFC 7009) ഒരു token ഇനി valid ആകരുതെന്ന് authorization server-നോട് client എങ്ങനെ അറിയിക്കണം എന്ന് നിർവചിക്കുന്നു.
• Audit logs-ൽ action ചെയ്തത് agent ആണെന്ന് കാണിക്കും, user അല്ല.

നിങ്ങളുടെ app-ൽ ഇപ്പോഴും delegated credentials support ഇല്ലെങ്കിൽ, agents-ക്ക് ഏറ്റവും കൂടുതൽ ആവശ്യമായ പ്രവർത്തനങ്ങൾക്ക് അതിനെ മുൻഗണന നൽകുക. automated access-നുള്ള ഏറ്റവും ഫലപ്രദമായ control ഇതാണ്.

Step 4: എപ്പോൾ step-up check ചോദിക്കണം?

Step-up എന്നത് ഒരു സെൻസിറ്റീവ് പ്രവർത്തനത്തിന്റെ സമയത്ത് അധിക assurance ചോദിക്കുന്നതാണ്. OAuth-protected APIs-ക്കായി, RFC 9470 നിലവിലെ token-ന്റെ authentication മതിയായ ശക്തിയുള്ളതല്ല അല്ലെങ്കിൽ മതിയായ പുതുമയുള്ളതല്ല എന്ന് ഒരു resource server എങ്ങനെ client-നോട് പറയുന്നു എന്ന് നിർവചിക്കുന്നു. ശരിയായ step-up പ്രവർത്തിക്കുന്നത് ആരാണെന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു:

• Interactive person (Human, Human + AI): വീണ്ടും authentication ചെയ്യുക (NIST SP 800-63B-ലെ reauthentication ആവശ്യകതകൾ കാണുക), WebAuthn അടിസ്ഥാനമാക്കിയ passkey prompt, അല്ലെങ്കിൽ one-time code.
• Delegated credential ഉള്ള agent: ഉയർന്ന tier പ്രവർത്തനത്തിനായി user വ്യക്തമായി അനുവദിച്ച scope, അല്ലെങ്കിൽ 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 ഫലം step-up ഒഴിവാക്കുന്നില്ല എന്ന് ശ്രദ്ധിക്കുക. അത് interactive person-ന് അനുയോജ്യമായ step-up തിരഞ്ഞെടുക്കുന്നു. Inference-കൾ തെറ്റായിരിക്കാം, അതിനാൽ അവ check-ന്റെ രൂപം മാറ്റണം, അത് നീക്കം ചെയ്യരുത്.

Step 5: വിധിനിർണ്ണയം ആവശ്യമായിടത്ത് human review-ലേക്ക് route ചെയ്യുക

ചില പ്രവർത്തനങ്ങൾ അപൂർവവും ഉയർന്ന സ്വാധീനമുള്ളതും സുരക്ഷിതമായി ഓട്ടോമേറ്റ് ചെയ്യാൻ ബുദ്ധിമുട്ടുള്ളതുമാണ്: customer data-യുടെ bulk export, credentials നഷ്ടപ്പെട്ടതിന് ശേഷം account recovery, അല്ലെങ്കിൽ ഒരു organization delete ചെയ്യുക. ഇവയ്‌ക്ക്, ഏതെങ്കിലും automated rule-നെക്കാൾ review queue കൂടുതലായി അനുയോജ്യമാണ്.

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 behavior തിരഞ്ഞെടുക്കുക

Actor evaluation timeout ആകുകയോ evidence ഇല്ലാതാകുകയോ ചെയ്യാം. അതിനാൽ മുമ്പേ എന്താണ് സംഭവിക്കേണ്ടതെന്ന് തീരുമാനിക്കുക.

• Low tier: fail open. Request സാധാരണ പോലെ മുന്നോട്ട് പോകുന്നു.
• Medium tier: സാധാരണ authorization നിലവിലുണ്ടാകെ fail open.
• High tier: നിലവിലുള്ള ശക്തമായ check-ലേക്ക് fail closed. Actor evidence ഇല്ലാത്തത് ഒരിക്കലും സംരക്ഷണം ദുർബലമാക്കുന്നില്ല, കൂടാതെ നിങ്ങളുടെ സാധാരണ checks പാസാകുമായിരുന്നു എന്ന request-നെ അത് ഒരിക്കലും ബ്ലോക്ക് ചെയ്യില്ല.

പ്രധാന ഗുണം symmetry ആണ്. Actor evaluation-ൽ ഒരു failure ഉണ്ടായാൽ, actor context ചേർക്കുന്നതിന് മുമ്പുണ്ടായിരുന്നതുപോലെ തന്നെ action സുരക്ഷിതമായും, അതുപോലെ തന്നെ ലഭ്യമായും തുടരണം.

Step 7: Inference-കൾ അടിസ്ഥാനമാക്കി ആളുകളെക്കുറിച്ച് നിർണായക തീരുമാനങ്ങൾ എടുക്കരുത്

ഒരു inferred classification interaction-നെക്കുറിച്ചുള്ള evidence ആണ്, ഒരു വ്യക്തിയെക്കുറിച്ചുള്ള വസ്തുതയല്ല. ഒരു session automated അല്ലെങ്കിൽ AI-assisted ആയി തോന്നിയതിനാൽ ആരുടെയെങ്കിലും job application, credit decision, exam result, housing, അല്ലെങ്കിൽ ആവശ്യമായ ഒരു സേവനത്തിലേക്കുള്ള access നിഷേധിക്കരുത്. അത്തരം flows-ൽ, human review അല്ലെങ്കിൽ alternative verification path പോലുള്ള ഒരു process തിരഞ്ഞെടുക്കാൻ actor context ഉപയോഗിക്കുക, പിന്നെ ആ person-ന് അത് പൂർത്തിയാക്കാൻ കഴിയുമെന്ന് ഉറപ്പാക്കുക.

ഇത് fairness-ന്റെ ഒരു സിദ്ധാന്തവും, പ്രായോഗികമായതുമാണ്. Inference-കൾക്ക് false positives ഉണ്ടാകും, ഈ flows-ലുള്ള false positive-ന്റെ ചെലവ് തെറ്റൊന്നും ചെയ്യാത്ത ഒരാളുടെ മേലാണ് വീഴുന്നത്.

Step 8: ആദ്യം observation ഉപയോഗിച്ച് rollout ചെയ്യുക

ഇത് യഥാർത്ഥ requests-നെ ബാധിക്കുന്നതിന് മുമ്പ്, observation, preview mode എന്നിവയിൽ പ്രവർത്തിപ്പിക്കുക:

1. Tier, actor class, basis, credential type, നിങ്ങളുടെ policy ആവശ്യപ്പെടുന്ന step-up എന്നിവ രേഖപ്പെടുത്തുക.
2. Class പ്രകാരം high-tier requests-ന്റെ samples പരിശോധിക്കുക. സാധുവായ agents delegated credentials ഉപയോഗിക്കുന്നുണ്ടോ, അല്ലെങ്കിൽ user sessions വീണ്ടും ഉപയോഗിക്കുന്നുണ്ടോ?
3. നിങ്ങൾ കണ്ടെത്തുന്ന gaps പരിഹരിക്കുക, പലപ്പോഴും scoped credentials നൽകുന്നതിലൂടെ, enforce ചെയ്യുന്നതിന് മുമ്പ്.
4. ഒരു single route-ന്റെ ചെറിയ ഭാഗത്ത് enforce ചെയ്യുക, completion rates അളക്കുക, പിന്നെ വ്യാപിപ്പിക്കുക.

Step 9: "ആരാണ്, ആരുടെ പേരിൽ" എന്ന് മറുപടി നൽകുന്ന audit trail നിലനിർത്തുക

ഓരോ high-tier പ്രവർത്തനത്തിനും, പിന്നീട് സംഭവിച്ചത് പുനർനിർമ്മിക്കാൻ മതിയായ വിവരങ്ങൾ രേഖപ്പെടുത്തുക:

• request സമയത്തെ actor class, basis എന്നിവ,
• credential type, അത് ഏത് client-ന് നൽകിയതാണ്, അത് പ്രതിനിധീകരിക്കുന്ന subject (OAuth 2.0 Token Exchange, RFC 8693, ഇത്തരത്തിലുള്ള കൃത്യമായ "acting for" ബന്ധം രേഖപ്പെടുത്താൻ act claim നിർവചിക്കുന്നു),
• പ്രവർത്തനം authorize ചെയ്ത scopes,
• പ്രയോഗിച്ച step-up അല്ലെങ്കിൽ review requirement, അതിന്റെ ഫലം.

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 delete ചെയ്തത് person ആണോ assistant ആണോ, അത് ആരാണ് approve ചെയ്തത്" പോലെയുള്ള ചോദ്യത്തിന് വ്യക്തമായ മറുപടി ലഭിക്കും. അതുവഴി incident response വേഗത്തിലാകുകയും നിങ്ങളുടെ app-ലുള്ള automated സഹായം ഉത്തരവാദിത്തമുള്ളതാണെന്ന് users-ക്ക് ആത്മവിശ്വാസം നൽകുകയും ചെയ്യുന്നു.

ഒരു worked example

ഒരു project management app-ൽ ഒരു assistant users-ക്കായി task due dates പുതുക്കുകയും, ഇടയ്ക്കിടെ മുഴുവൻ projects export ചെയ്യാൻ ശ്രമിക്കുകയും ചെയ്യുന്നു.

• ഒരു task പുതുക്കുന്നത് medium tier ആണ്. Assistant tasks:write ഉള്ള ഒരു OAuth token ഉപയോഗിക്കുന്നു. Authorized, step-up ഇല്ല. അനുവദിച്ചു.
• ഒരു project export ചെയ്യുന്നത് high tier ആണ്. Assistant-ന്റെ token-ൽ export:bulk ഇല്ല. App user-ന് ഒരു confirmation request അയയ്ക്കുന്നു. User approve ചെയ്യുന്നു, പിന്നെ app ആ client-ക്കായി scope അനുവദിക്കുന്നു.
• ഒരു Unknown client വീണ്ടും ഉപയോഗിച്ച session cookie ഉപയോഗിച്ച് അതേ export ശ്രമിക്കുന്നു. നിലവിലുള്ള re-authentication prompt പ്രയോഗിക്കുന്നു, മുമ്പുണ്ടായിരുന്നതുപോലെ തന്നെ.

ഏജന്റ് ആയതിനാൽ ആരും ബ്ലോക്ക് ചെയ്യപ്പെട്ടില്ല. ഓരോ ഉയർന്ന സ്വാധീനമുള്ള പ്രവർത്തനവും വ്യക്തമായ അധികാരം വഹിച്ചു.

Proof of Actor എവിടെയാണ് അനുയോജ്യം

Proof of Actor ഈ മാതൃകയുടെ actor വശം നൽകുന്നു: ആരാണ് അല്ലെങ്കിൽ എന്താണ് പ്രവർത്തിക്കുന്നത്, ഏത് basis-ൽ. നിങ്ങളുടെ application authentication, authorization, അന്തിമ തീരുമാനം എന്നിവ കൈകാര്യം ചെയ്യുന്നു. Actor-നെ detect ചെയ്യുക, ഓരോ class-വും നിങ്ങളുടെ സെൻസിറ്റീവ് routes എങ്ങനെ ഉപയോഗിക്കുന്നു എന്ന് Understand ചെയ്യുക, ഓരോ request-ഉം ശരിയായ assurance നിലയിലേക്ക് Route ചെയ്യുക.

നിങ്ങളുടെ application-നായി ഇത് ഞങ്ങളുടെ team-ോടെ രൂപകൽപ്പന ചെയ്യാൻ, early access-ക്കായി അപേക്ഷിക്കുക. കൂടുതൽ വിശദമായ SaaS scenarios-ക്കായി, SaaS Apps & Websites കാണുക.

Sources

• RFC 6749: The OAuth 2.0 Authorization Framework: clients-ക്കുള്ള scoped, delegated credentials
• RFC 9700: Best Current Practice for OAuth 2.0 Security: OAuth വിന്യാസങ്ങൾക്കുള്ള നിലവിലെ സുരക്ഷാ മാർഗ്ഗനിർദ്ദേശം
• RFC 7009: OAuth 2.0 Token Revocation: user-ന്റെ credentials മാറ്റാതെ ഒരു grant revoke ചെയ്യുക
• RFC 9470: OAuth 2.0 Step Up Authentication Challenge Protocol: കൂടുതൽ ശക്തമായ അല്ലെങ്കിൽ പുതുമയുള്ള authentication ആവശ്യമാണ് എന്ന് signaling ചെയ്യുക
• RFC 8693: OAuth 2.0 Token Exchange: delegation-നുള്ള act (actor) claim
• MCP specification 2026-07-28: Authorization: MCP servers, OAuth 2.1 resource servers ആയി
• NIST SP 800-63B: Authentication and Authenticator Management: reauthentication മാർഗ്ഗനിർദ്ദേശം
• W3C Web Authentication (WebAuthn) Level 3: passkey prompts-ന്റെ പിന്നിലെ standard
• RFC 9421: HTTP Message Signatures: ഒരു verified agent signature എന്താണ് സ്ഥാപിക്കുന്നത്