સંવેદનશીલ ક્રિયાઓને કાયદેસર એજન્ટોને અવરોધ્યા વિના કેવી રીતે સુરક્ષિત રાખવી

શા માટે માત્ર સંવેદનશીલ ક્રિયાઓ માટે agentsને બ્લોક ન કરી દઈએ?

તમારી applicationમાં કેટલીક ક્રિયાઓ બીજી કરતાં વધુ મહત્વપૂર્ણ હોય છે. પાસવર્ડ બદલવો, team member ઉમેરવો, data export કરવું, project delete કરવું, order approve કરવો: જો આમાંથી કંઈપણ યોગ્ય authority વગર થાય, તો નુકસાન વાસ્તવિક હોય છે.

સાથે સાથે, તમારી appમાં કાયદેસર કામનું વધુ ને વધુ automation દ્વારા થાય છે. વપરાશકર્તા assistantને તેની settings update કરવા કહે છે. partner integration schedule મુજબ records બનાવે છે. internal agent support tickets file કરે છે. સંવેદનશીલ routes પરથી દરેક automated clientને બ્લોક કરવાથી આ કામ તૂટી જાય છે અને લોકોને manual effort અથવા એવા workarounds તરફ ધકેલે છે જે સુરક્ષિત કરવું વધુ મુશ્કેલ હોય છે.

જવાબ "block agents" કે "trust agents" નથી. તે એવો મોડેલ છે જેમાં ક્રિયાનો જોખમ, વિનંતી પાછળની authority અને actor વિશેનો evidence દરેકની અલગ ભૂમિકા હોય. આ guide એ મોડેલ બનાવે છે. તેના પાછળના વ્યાપક વિચાર માટે, humans and 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: identity, credentials અને authorizationમાં શું ફરક છે?

ત્રણ પ્રશ્નો ઘણી વાર એકબીજામાં ભળી જાય છે:

1. કોણ અથવા શું કાર્ય કરી રહ્યું છે? આ actor evidence છે: interactive person, AI સહાય સાથેનો 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 ત્રીજા પ્રશ્નનો જવાબ આપે છે. તે પ્રથમ વિશે બહુ ઓછું કહે છે. 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 પરિણામને કારણે 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, તેને સુરક્ષિત રીતે કેવી રીતે deploy કરવું તે વર્ણવે છે. MCP servers એ જ પેટર્ન અનુસરે છે: MCP authorization specification protected MCP serverને OAuth 2.1 resource server તરીકે માનેછે. અમારી post તમારા MCP serverને કોણ call કરે છે? આને tool calls પર લાગુ કરે છે.

આ તમને સંવેદનશીલ ક્રિયાઓ માટે બરાબર જે જોઈએ તે આપે છે:

• token તમને જણાવે છે કે કયો client કાર્ય કરી રહ્યો છે અને કોના માટે.
• scopes તે શું કરી શકે છે તે મર્યાદિત કરે છે. calendar:write ધરાવતો scheduling agent પાસવર્ડ બદલી શકતો નથી.
• user પોતાની credentials બદલે વગર grant પાછું ખેંચી શકે છે, અને OAuth 2.0 Token Revocation (RFC 7009) client authorization serverને કેવી રીતે જણાવે છે કે token હવે માન્ય ન રહેવું જોઈએ તે વ્યાખ્યાયિત કરે છે.
• audit logs બતાવે છે કે action userએ નહીં, agentએ કર્યું હતું.

જો તમારી app હજી delegated credentialsને support કરતી ન હોય, તો agentsને સૌથી વધુ જોઈએ એવી ક્રિયાઓ માટે તેને પ્રાથમિકતા આપો. automated access માટે આ સૌથી અસરકારક control છે.

પગલું 4: તમે step-up check ક્યારે માંગશો?

Step-up એટલે સંવેદનશીલ actionના ક્ષણે વધારાનું assurance માગવું. OAuth-protected APIs માટે, RFC 9470 define કરે છે કે resource server કેવી રીતે clientને કહે છે કે current tokenની authentication પૂરતી strong અથવા recent નથી. યોગ્ય step-up કોણ કાર્ય કરી રહ્યું છે તેના પર આધાર રાખે છે:

• 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 માટે સમર્પિત scope, user દ્વારા સ્પષ્ટ રીતે મંજૂર, અથવા out of band userને મોકલાયેલી confirmation.
• Unknown: routeની વર્તમાન 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 પરિણામ step-upને છોડતું નથી. તે interactive person માટે યોગ્ય step-up પસંદ કરે છે. Inferences ખોટા હોઈ શકે છે, તેથી તેઓ checkનું સ્વરૂપ બદલવું જોઈએ, તેને દૂર નહીં કરવું.

પગલું 5: નિર્ણય જરૂરી હોય ત્યાં human review તરફ route કરો

કેટલીક ક્રિયાઓ દુર્લભ, ઉચ્ચ અસરવાળી અને સુરક્ષિત રીતે automate કરવી મુશ્કેલ હોય છે: customer dataના bulk exports, ખોવાયેલા credentials પછી account recovery, અથવા organization delete કરવું. આ માટે, કોઈપણ automated નિયમ કરતાં review queue ઘણીવાર વધુ સારી હોય છે.

Actor context reviewerને evidence આપીને reviewને વધુ ઝડપી અને ન્યાયી બનાવે છે: class, basis, વપરાયેલ credential, સમાન વિનંતીઓનો ઇતિહાસ. 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 time out થઈ શકે છે અથવા evidenceની અછત હોઈ શકે છે. આગોતરો નક્કી કરો કે શું થશે.

• Low tier: fail open. વિનંતી સામાન્ય રીતે આગળ વધે છે.
• Medium tier: fail open, સામાન્ય authorization સાથે.
• High tier: હાજર strong check પર fail closed. actor evidenceની ગેરહાજરી સુરક્ષાને ક્યારેય નબળી બનાવતી નથી, અને તે એવી વિનંતીને ક્યારેય રોકતી નથી જે તમારી સામાન્ય ચકાસણીઓમાં અન્યથા પાસ થાતી.

મુખ્ય ગુણધર્મ symmetry છે. actor evaluationમાં failure actionને એટલું જ સુરક્ષિત અને એટલું જ ઉપલબ્ધ રાખે, જેટલું તે actor context ઉમેરતાં પહેલાં હતું.

પગલું 7: inferences પરથી લોકો વિશે પરિણામકારી નિર્ણય ન લો

inferred classification interaction વિશેનું evidence છે, વ્યક્તિ વિશેનું સત્ય નથી. session automated અથવા AI-assisted લાગતી હતી એટલા માટે કોઈને job application, credit decision, exam result, housing અથવા આવશ્યક સેવા સુધીની પહોંચ નકારશો નહીં. આવા flowsમાં, actor contextનો ઉપયોગ પ્રક્રિયા પસંદ કરવા માટે કરો, જેમ કે human review અથવા વૈકલ્પિક verification path, અને ખાતરી કરો કે વ્યક્તિ તેને પૂર્ણ કરી શકે.

આ fairness principle પણ છે અને વ્યવહારુ પણ. Inferencesમાં false positives હોય છે, અને આવા flowsમાં false positiveની કિંમત એવી વ્યક્તિ પર પડે છે જેણે કંઈ ખોટું કર્યું નથી.

પગલું 8: પહેલાં observation સાથે rollout કરો

આમાંથી કંઈપણ વાસ્તવિક વિનંતીઓને અસર કરે તે પહેલાં, તેને observation અને preview modeમાં ચલાવો:

1. tier, actor class, basis, credential type અને તમારી policy જે step-up માગે તે record કરો.
2. class પ્રમાણે high-tier વિનંતીઓના samples review કરો. શું કાયદેસર agents delegated credentials વાપરે છે, કે user sessions ફરી વાપરે છે?
3. enforce કરતાં પહેલાં, તમે શોધેલા gaps સુધારો, ઘણીવાર scoped credentials આપીને.
4. એક જ routeના નાના ભાગ પર enforce કરો, completion rates માપો, પછી વિસ્તાર કરો.

પગલું 9: એવો audit trail રાખો કે જે "કોણ અને કોની behalf પર" નો જવાબ આપે

દરેક high-tier action માટે, પછી શું થયું તે ફરી રચી શકાય એટલું record કરો:

• વિનંતી સમયે actor class અને basis,
• credential type, તે કયા clientને issue થયું અને તે કોને represent કરે છે (OAuth 2.0 Token Exchange, RFC 8693, delegation માટે ચોક્કસ આ પ્રકારના "acting for" સંબંધને record કરવા માટે act claim define કરે છે),
• actionને authorized કરનાર 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ને ઝડપી બનાવે છે અને usersને વિશ્વાસ આપે છે કે તમારી appમાં automated help જવાબદાર છે.

એક કાર્યાત્મક ઉદાહરણ

એક project management app users માટે task due dates update કરતો assistant જુએ છે, અને ક્યારેક આખા projects export કરવાનો પ્રયાસ પણ કરે છે.

• Task update કરવું 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 grant કરે છે.
• Unknown client ફરી વપરાયેલા session cookie સાથે એ જ export કરવાનો પ્રયાસ કરે છે. વર્તમાન re-authentication prompt લાગુ પડે છે, બરાબર જેમ પહેલાં થતો હતો.

કોઈને agent હોવા માટે બ્લોક કરવામાં આવ્યા નહોતા. દરેક high-impact action સાથે સ્પષ્ટ authority હતી.

Proof of Actor ક્યાં ફિટ થાય છે

Proof of Actor આ મોડેલનો actor ભાગ પ્રદાન કરે છે: કોણ અથવા શું કાર્ય કરી રહ્યું છે અને કયા આધાર પર. તમારી application authentication, authorization અને અંતિમ નિર્ણય જાળવે છે. actorને Detect કરો, દરેક class તમારી સંવેદનશીલ routesનો કેવી રીતે ઉપયોગ કરે છે તે Understand કરો, અને દરેક વિનંતીને યોગ્ય assurance સ્તર સુધી Route કરો.

તમારી application માટે અમારી ટીમ સાથે આ ડિઝાઇન કરવા માટે, 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 deployments માટે વર્તમાન security guidance
• RFC 7009: OAuth 2.0 Token Revocation: userની credentials બદલ્યા વગર grant revoke કરવું
• RFC 9470: OAuth 2.0 Step Up Authentication Challenge Protocol: વધુ strong અથવા વધુ recent authentication જરૂરી છે તે signal કરવું
• RFC 8693: OAuth 2.0 Token Exchange: delegation માટેનો act (actor) claim
• MCP specification 2026-07-28: Authorization: MCP servers as OAuth 2.1 resource 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 શું સ્થાપિત કરે છે તે