संवेदनशील क्रिया थांबविल्याशिवाय त्यांचे संरक्षण कसे करावे

संवेदनशील क्रियांना agents पासून थेट का रोखू नये?

तुमच्या application मधील काही क्रिया इतरांपेक्षा अधिक महत्त्वाच्या असतात. पासवर्ड बदलणे, टीम member जोडणे, data export करणे, project delete करणे, order approve करणे: यापैकी काहीही योग्य अधिकारांशिवाय घडले, तर नुकसान खरे असते.

त्याच वेळी, तुमच्या app मधील वैध कामाचा मोठा भाग automation द्वारे केला जातो. एक user assistant ला त्याच्या settings update करायला सांगतो. एक partner integration schedule वर records तयार करते. एक internal agent support tickets file करतो. संवेदनशील routes वरून प्रत्येक automated client ला block केल्याने हे काम तुटते आणि लोकांना manual प्रयत्नांकडे किंवा secure करणे कठीण असलेल्या workarounds कडे ढकलले जाते.

उत्तर हे "agents block करा" किंवा "agents वर विश्वास ठेवा" असे नाही. उत्तर असे मॉडेल आहे ज्यात action चा धोका, request मागील authority आणि actor बद्दलचा evidence हे प्रत्येक वेगळ्या भूमिकेत काम करतात. हा guide ते मॉडेल तयार करतो. त्यामागील व्यापक विचारासाठी human आणि AI agents साठी app-level policies तयार करणे पहा.

पायरी 1: तुमचे routes धोक्यानुसार स्तरांमध्ये विभागा

clients ऐवजी actions चे वर्गीकरण करून सुरुवात करा. बहुतेक applications साठी साधी तीन-स्तरीय योजना काम करते:

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",
};

स्तर हळूहळू बदलतात आणि त्यांचा विचार करणे सोपे असते. या guide मधील बाकी सर्व काही त्यांच्यावर आधारलेले आहे.

पायरी 2: ओळख, credentials आणि authorization यांमध्ये काय फरक आहे?

तीन प्रश्न अनेकदा एकमेकांत मिसळले जातात:

1. कोण किंवा काय कृती करत आहे? हा actor evidence आहे: परस्परसंवादी person, AI assistance सह person, agent, किंवा Unknown, ज्याचा आधार verified किंवा declared असा असू शकतो.
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 तिसऱ्या प्रश्नाचे उत्तर देतो. तो पहिल्या प्रश्नाबद्दल फारसे सांगत नाही. उच्च-स्तरीय 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 परिणाम अनुकूल असल्यामुळे authorization कधीही शिथिल केली जात नाही. Actor context फक्त अतिरिक्त आवश्यकता जोडतो किंवा समान सुरक्षित मार्गांमधून निवड करतो.

पायरी 3: लोकांसाठी कृती करणाऱ्या agents साठी 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 कोण कॉल करत आहे? हे tool calls वर लागू करते.

यामुळे संवेदनशील क्रियांसाठी नेमके जे हवे ते मिळते:

• Token तुम्हाला कोणता client कृती करत आहे आणि कुणासाठी, हे सांगतो.
• Scopes ते काय करू शकते ते मर्यादित करतात. calendar:write असलेला scheduling agent पासवर्ड बदलू शकत नाही.
• User स्वतःची credentials न बदलता grant revoke करू शकतो, आणि OAuth 2.0 Token Revocation (RFC 7009) token आता वैध नसावा हे authorization server ला client कसे सांगतो ते परिभाषित करते.
• Audit logs दाखवतात की कृती user ने नाही, तर agent ने केली.

जर तुमच्या app मध्ये अजून delegated credentials समर्थित नसतील, तर agentsना सर्वाधिक आवश्यक असलेल्या क्रियांसाठी त्यांना प्राधान्य द्या. automated access साठी हा एकल सर्वात प्रभावी control आहे.

पायरी 4: step-up तपासणी कधी मागावी?

Step-up म्हणजे संवेदनशील action च्या क्षणी अतिरिक्त assurance मागणे. OAuth-protected APIs साठी, RFC 9470 resource server ला current token चे authentication पुरेसे मजबूत किंवा अलीकडचे नाही हे client ला कसे सांगायचे ते परिभाषित करते. योग्य step-up कोण कृती करत आहे यावर अवलंबून असतो:

• परस्परसंवादी person (Human, Human + AI): पुन्हा authentication करणे (NIST SP 800-63B मधील reauthentication requirements पहा), WebAuthn वर आधारित passkey prompt, किंवा one-time code.
• Delegated credential असलेला agent: उच्च-स्तरीय action साठी समर्पित scope, user ने स्पष्टपणे दिलेला, किंवा out of band user ला पाठवलेली confirmation.
• Unknown: route ची विद्यमान मजबूत तपासणी, 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 परिणाम step-up वगळत नाही. तो परस्परसंवादी person साठी योग्य असा step-up निवडतो. Inferences चुकीच्या ठरू शकतात, म्हणून त्यांनी check चे रूप बदलावे, ते काढून टाकू नये.

पायरी 5: निर्णय आवश्यक असेल तेथे human review कडे route करा

काही actions दुर्मीळ, उच्च-प्रभावी आणि सुरक्षितपणे automate करणे कठीण असतात: ग्राहक data चे bulk exports, 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"));
}

पायरी 6: प्रत्येक स्तरासाठी failure वर्तन निवडा

Actor evaluation timeout होऊ शकते किंवा evidence नसू शकते. आधीच ठरवा काय होईल.

• कमी स्तर: fail open. Request सामान्यपणे पुढे जाते.
• मध्यम स्तर: fail open, आणि सामान्य authorization अस्तित्वात असते.
• उच्च स्तर: विद्यमान मजबूत तपासणीसाठी fail closed. Missing actor evidence कधीही protection कमकुवत करत नाही, आणि ते अशा request ला कधीही block करत नाही जे तुमच्या सामान्य तपासणीतून अन्यथा पास झाले असते.

महत्त्वाचे वैशिष्ट्य म्हणजे symmetry. Actor evaluation मधील failure मुळे action तितकाच सुरक्षित, आणि तितकाच उपलब्ध, राहिला पाहिजे जितका actor context जोडण्यापूर्वी होता.

पायरी 7: Inferences वरून लोकांबद्दल महत्त्वाचे निर्णय घेऊ नका

Inferred classification ही एका interaction बद्दलची evidence आहे, एखाद्या व्यक्तीबद्दलची वस्तुस्थिती नाही. जर session automated किंवा AI-assisted दिसली म्हणून एखाद्याचा job application, credit decision, exam result, housing किंवा आवश्यक सेवेचा access नाकारा. अशा flows मध्ये actor context चा उपयोग प्रक्रिया निवडण्यासाठी करा, जसे की human review किंवा पर्यायी verification path, आणि ती व्यक्ती ते पूर्ण करू शकेल याची खात्री करा.

हे न्याय्यतेचे तत्त्व आहे आणि व्यावहारिकही आहे. Inferences मध्ये false positives असतात, आणि अशा flows मधील false positive ची किंमत अशा व्यक्तीवर पडते जिने काहीही चूक केलेली नसते.

पायरी 8: प्रथम observation सह rollout करा

यापैकी काहीही प्रत्यक्ष requests वर परिणाम करण्यापूर्वी, observation आणि preview mode मध्ये चालवा:

1. Tier, actor class, basis, credential type आणि तुमच्या policy ला आवश्यक असलेला step-up नोंदवा.
2. वर्गानुसार उच्च-स्तरीय requests चे नमुने तपासा. वैध agents delegated credentials वापरत आहेत का, की user sessions पुन्हा वापरत आहेत?
3. तुम्हाला आढळलेली अंतरं, अनेकदा scoped credentials देऊन, enforce करण्यापूर्वी दुरुस्त करा.
4. एका route च्या छोट्या भागावर enforce करा, completion rates मोजा, आणि मग विस्तार करा.

पायरी 9: "कोण आणि कुणाच्या वतीने" हे उत्तर देणारा audit trail ठेवा

प्रत्येक उच्च-स्तरीय action साठी, नंतर काय घडले ते पुन्हा तयार करता येईल इतके नोंदवा:

• request च्या वेळी actor class आणि basis,
• credential type, ते ज्या client ला दिले गेले आणि ते कोणाचे प्रतिनिधित्व करते हे subject (OAuth 2.0 Token Exchange, RFC 8693, ने exactly अशा "acting for" नात्याची नोंद करण्यासाठी एक act claim परिभाषित केला आहे),
• action अधिकृत करणारे scopes,
• लागू केलेली step-up किंवा review आवश्यकता आणि त्याचा परिणाम.

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 ने delete केला की assistant ने, आणि ते कोणी approve केले" अशा प्रश्नाचे स्पष्ट उत्तर मिळते. त्यामुळे incident response जलद होते आणि वापरकर्त्यांना तुमच्या app मधील automated मदत accountable आहे यावर विश्वास बसतो.

एक worked example

एक project management app पाहते की एक assistant users साठी task due dates update करत आहे, आणि कधी कधी संपूर्ण projects export करण्याचा प्रयत्न करत आहे.

• Task update करणे मध्यम स्तराचे आहे. Assistant tasks:write असलेला OAuth token वापरते. Authorized, step-up नाही. Allowed.
• Project export करणे उच्च स्तराचे आहे. Assistant च्या token मध्ये export:bulk नाही. App user ला confirmation request पाठवते. User मंजुरी देतो, आणि app त्या client साठी scope देते.
• एक Unknown client पुन्हा वापरलेल्या session cookie सह तोच export करण्याचा प्रयत्न करतो. विद्यमान re-authentication prompt लागू होतो, अगदी पूर्वीप्रमाणे.

कोणालाही agent असल्यामुळे block केले गेले नाही. प्रत्येक उच्च-प्रभावी action कडे स्पष्ट authority होती.

Proof of Actor कुठे बसते

Proof of Actor या मॉडेलचा actor बाजू पुरवते: कोण किंवा काय कृती करत आहे आणि कोणत्या आधारावर. तुमचे application authentication, authorization आणि अंतिम निर्णय स्वतः राखते. Actor Detect करा, प्रत्येक class तुमचे संवेदनशील routes कसे वापरते ते Understand करा, आणि प्रत्येक request ला योग्य assurance स्तराकडे Route करा.

तुमच्या application साठी हे आमच्या टीमसोबत डिझाइन करण्यासाठी, early access साठी अर्ज करा. SaaS scenarios अधिक तपशीलात पाहण्यासाठी, SaaS Apps & Websites पहा.

स्रोत

• RFC 6749: The OAuth 2.0 Authorization Framework: clients साठी scoped, delegated credentials
• RFC 9700: Best Current Practice for OAuth 2.0 Security: OAuth deployments साठी सद्य सुरक्षा मार्गदर्शन
• RFC 7009: OAuth 2.0 Token Revocation: user ची credentials न बदलता 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 servers हे OAuth 2.1 resource servers म्हणून
• NIST SP 800-63B: Authentication and Authenticator Management: reauthentication मार्गदर्शन
• W3C Web Authentication (WebAuthn) Level 3: passkey prompts मागील मानक
• RFC 9421: HTTP Message Signatures: verified agent signature काय स्थापित करते ते