संवेदनशील कार्रवाइयों को वैध एजेंट्स को रोके बिना कैसे सुरक्षित करें

एजेंट्स को संवेदनशील कार्रवाइयों से बस ब्लॉक क्यों न करें?

आपके application में कुछ कार्रवाइयाँ दूसरों की तुलना में अधिक महत्वपूर्ण होती हैं। पासवर्ड बदलना, team member जोड़ना, data export करना, project delete करना, order approve करना: इनमें से कोई भी सही authority के बिना हो तो नुकसान वास्तविक होता है।

साथ ही, आपके app का अधिक वैध काम automation द्वारा किया जा रहा है। एक user किसी assistant से अपने settings अपडेट करने को कहता है। एक partner integration schedule पर records बनाता है। एक internal agent support tickets दर्ज करता है। संवेदनशील routes से हर automated client को ब्लॉक करना उस काम को तोड़ देता है और लोगों को फिर manual effort या ऐसे workarounds की ओर धकेल देता है जिन्हें secure करना और कठिन होता है।

उत्तर "agents को block करें" या "agents पर भरोसा करें" नहीं है। यह एक ऐसा model है जिसमें action का risk, request के पीछे की authority, और actor के बारे में evidence, तीनों की अलग भूमिका होती है। यह guide उसी model को बनाती है। इसके पीछे की व्यापक सोच के लिए humans और AI agents के लिए app-level policies design करना देखें।

Step 1: अपने routes को risk के आधार पर tier करें

Clients नहीं, बल्कि actions को वर्गीकृत करने से शुरू करें। अधिकांश applications के लिए एक सरल तीन-tier scheme पर्याप्त है:

Tier को route configuration में लिखें ताकि 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",
};

Tiers धीरे बदलते हैं और उन पर तर्क करना आसान होता है। इस guide की बाकी सारी बातें इन्हीं पर टिकती हैं।

Step 2: identity, credentials और 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 करने के लिए allowed है? यह authorization है।

एक verified agent signature (RFC 9421) पहला प्रश्न अच्छी तरह से उत्तर देता है। यह तीसरे के बारे में कुछ नहीं कहता, जैसा कि signed AI agent requests क्या साबित करते हैं, और क्या नहीं में विस्तार से कवर किया गया है। सही scope वाला OAuth token तीसरे प्रश्न का उत्तर देता है। यह पहले के बारे में बहुत कम बताता है। किसी high-tier action के लिए आपका निर्णय हमेशा तीसरे प्रश्न का अच्छा उत्तर माँगता है, और पहले का उपयोग यह चुनने के लिए करता है कि कितनी अतिरिक्त 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 केवल अतिरिक्त requirements जोड़ता है या समान रूप से सुरक्षित paths के बीच चयन करता है।

Step 3: लोगों की ओर से काम करने वाले agents के लिए delegated authority का उपयोग करें

जब कोई agent किसी user की ओर से काम करता है, तो उसे user के session को reuse करने देने के बजाय सीमित authority वाला अपना credential दें। OAuth 2.0 standard tool है: user किसी specific client के लिए specific scopes को approve करता है, और token उस client को दर्ज करता है। RFC 9700, OAuth 2.0 Security Best Current Practice, बताता है कि इसे सुरक्षित रूप से कैसे deploy करें। MCP servers भी यही pattern अपनाते हैं: MCP authorization specification एक protected MCP server को OAuth 2.1 resource server के रूप में treat करती है। हमारा post आपके MCP server को कौन call कर रहा है? इसे tool calls पर लागू करता है।

यह ठीक वही प्रदान करता है जिसकी आपको संवेदनशील कार्रवाइयों के लिए आवश्यकता है:

• Token आपको बताता है कि कौन-सा client act कर रहा है और किसके लिए।
• Scopes सीमित करते हैं कि वह क्या कर सकता है। calendar:write वाला scheduling agent पासवर्ड नहीं बदल सकता।
• User अपनी own credentials बदले बिना grant revoke कर सकता है, और OAuth 2.0 Token Revocation (RFC 7009) परिभाषित करता है कि client authorization server को कैसे बताता है कि कोई token अब valid नहीं रहना चाहिए।
• Audit logs दिखाते हैं कि action agent ने किया, user ने नहीं।

यदि आपका app अभी delegated credentials support नहीं करता, तो उन actions के लिए इसे प्राथमिकता दें जिनकी agents को सबसे अधिक आवश्यकता होती है। यह automated access के लिए सबसे प्रभावी single control है।

Step 4: step-up check कब माँगना चाहिए?

Step-up का मतलब है किसी संवेदनशील action के समय अतिरिक्त assurance माँगना। OAuth-protected APIs के लिए, RFC 9470 परिभाषित करता है कि resource server client को कैसे बताता है कि current token की authentication पर्याप्त मजबूत या recent नहीं है। सही step-up इस बात पर निर्भर करता है कि कौन act कर रहा है:

• Interactive person (Human, Human + AI): re-authentication (NIST SP 800-63B में reauthentication requirements देखें), WebAuthn पर आधारित passkey prompt, या one-time code.
• Delegated credential वाला Agent: high-tier action के लिए dedicated scope, जिसे user ने स्पष्ट रूप से grant किया हो, या user को out of band भेजी गई confirmation.
• Unknown: route का existing 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 को छोड़ता नहीं है। यह उस step-up को चुनता है जो interactive person के लिए उपयुक्त हो। Inferences गलत हो सकते हैं, इसलिए उन्हें check के shape को बदलना चाहिए, उसे हटाना नहीं।

Step 5: जहाँ judgment चाहिए वहाँ human review पर route करें

कुछ actions दुर्लभ, उच्च-प्रभाव वाले और सुरक्षित रूप से automate करने में कठिन होते हैं: customer data के bulk exports, lost credentials के बाद account recovery, या किसी organization को delete करना। इनके लिए, किसी automated rule से बेहतर अक्सर review queue होती है।

Actor context reviewer को evidence देकर review को तेज़ और अधिक न्यायसंगत बनाता है: class, basis, उपयोग किया गया credential, समान requests का इतिहास। 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: fail open, और सामान्य authorization लागू रहे।
• High tier: existing strong check पर fail closed. Missing actor evidence सुरक्षा को कभी कमजोर नहीं करता, और यह उस request को कभी ब्लॉक नहीं करता जो otherwise आपकी normal checks से pass हो जाती।

मुख्य गुण symmetry है। Actor evaluation में failure action को बिल्कुल उतना ही सुरक्षित, और बिल्कुल उतना ही available छोड़ना चाहिए, जितना actor context जोड़ने से पहले था।

Step 7: लोगों के बारे में inferences के आधार पर consequential निर्णय न लें

एक inferred classification किसी interaction के बारे में evidence है, किसी person के बारे में तथ्य नहीं। किसी को job application, credit decision, exam result, housing या essential service तक access सिर्फ इसलिए न दें कि कोई session automated या AI-assisted दिखा। ऐसे flows में, actor context का उपयोग process चुनने के लिए करें, जैसे human review या alternative verification path, और सुनिश्चित करें कि person इसे पूरा कर सके।

यह fairness का सिद्धांत भी है और व्यावहारिक भी। Inferences में false positives होते हैं, और इन flows में false positive की cost उस व्यक्ति पर पड़ती है जिसने कुछ गलत नहीं किया।

Step 8: पहले observation के साथ rollout करें

इसका real requests पर प्रभाव डालने से पहले, इसे observation और preview mode में चलाएँ:

1. Tier, actor class, basis, credential type और वह step-up record करें जिसकी आपकी policy आवश्यकता होगी।
2. Class के अनुसार high-tier requests के samples की review करें। क्या वैध agents delegated credentials का उपयोग कर रहे हैं, या user sessions को reuse कर रहे हैं?
3. जो gaps आपको मिलें उन्हें ठीक करें, अक्सर scoped credentials देकर, enforcement से पहले।
4. किसी single route के छोटे हिस्से पर enforce करें, completion rates मापें, फिर विस्तार करें।

Step 9: ऐसा audit trail रखें जो "कौन और किसकी ओर से" का उत्तर दे सके

हर high-tier action के लिए, बाद में क्या हुआ इसे reconstruct करने के लिए पर्याप्त जानकारी रिकॉर्ड करें:

• request के समय actor class और basis,
• credential type, जिस client को वह जारी किया गया था, और वह subject जिसे वह represent करता है (OAuth 2.0 Token Exchange, RFC 8693, ठीक इसी तरह के "acting for" relationship को रिकॉर्ड करने के लिए act claim define करता है),
• action को 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 के साथ, "क्या किसी person या assistant ने यह project delete किया, और किसने उसे approve किया" जैसा प्रश्न स्पष्ट उत्तर देता है। इससे incident response तेज़ होता है और उपयोगकर्ताओं को भरोसा मिलता है कि आपके app में automated help accountable है।

एक worked example

एक project management app देखता है कि एक assistant users के लिए task due dates update कर रहा है, और कभी-कभी पूरे projects 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 reused session cookie के साथ वही export करने की कोशिश करता है। Existing re-authentication prompt लागू होता है, बिल्कुल वैसे ही जैसे पहले होता था।

किसी को agent होने के कारण block नहीं किया गया। हर high-impact action के साथ स्पष्ट authority थी।

Proof of Actor कहाँ fit होता है

Proof of Actor इस model का actor side प्रदान करता है: कौन या क्या act कर रहा है और किस basis पर। आपका application authentication, authorization और अंतिम निर्णय बनाए रखता है। Actor detect करें, समझें कि प्रत्येक class आपके संवेदनशील routes का उपयोग कैसे करती है, और हर request को assurance के उचित स्तर पर route करें।

अपनी team के साथ इसे अपने application के लिए design करने हेतु, early access के लिए apply करें. अधिक detail में 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 deployments के लिए current security guidance
• RFC 7009: OAuth 2.0 Token Revocation: user की credentials बदले बिना 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 servers के रूप में MCP servers
• NIST SP 800-63B: Authentication and Authenticator Management: reauthentication guidance
• W3C Web Authentication (WebAuthn) Level 3: passkey prompts के पीछे का standard
• RFC 9421: HTTP Message Signatures: एक verified agent signature क्या स्थापित करती है