సున్నితమైన చర్యలను చట్టబద్ధమైన ఏజెంట్లను అడ్డుకోకుండా ఎలా రక్షించాలి

సున్నితమైన చర్యల నుంచి agents ను కేవలం block చేయకూడదే ఎందుకు?

మీ application లోని కొన్ని చర్యలు ఇతర వాటికంటే ఎక్కువ ప్రాముఖ్యాన్ని కలిగి ఉంటాయి. password మార్చడం, team member ను జోడించడం, data export చేయడం, project delete చేయడం, order approve చేయడం: వీటిలో ఏదైనా సరైన అధికారము లేకుండా జరిగితే, నష్టం నిజమైనదే.

అదే సమయంలో, మీ app లో legitimate work లో మరింత భాగం automation ద్వారా జరుగుతోంది. ఒక user తన settings ను update చేయమని assistant ను అడుగుతాడు. ఒక partner integration schedule ప్రకారం records సృష్టిస్తుంది. ఒక internal agent support tickets file చేస్తుంది. సున్నితమైన routes నుంచి ప్రతి automated client ను block చేయడం ఆ పనిని చెడగొడుతుంది మరియు ప్రజలను manual effort వైపుకు లేదా secure చేయడం మరింత కష్టమైన workaroundల వైపుకు నెడుతుంది.

సమాధానం "agents ను block చేయండి" లేదా "agents ను trust చేయండి" కాదు. చర్య ప్రమాదం, request వెనుక ఉన్న అధికారము, actor గురించి ఉన్న evidence - ఇవి ప్రతి ఒక్కటి ప్రత్యేక పాత్ర పోషించే మోడల్ అది. ఈ guide ఆ మోడల్‌ను నిర్మిస్తుంది. దీని వెనుక ఉన్న విస్తృత ఆలోచన కోసం, humans మరియు AI agents కోసం app-level policies రూపొందించడం చూడండి.

దశ 1: మీ routes ను ప్రమాదం ఆధారంగా tier చేయండి

clients ను కాదు, actions ను మొదట వర్గీకరించడం ప్రారంభించండి. చాలా applications కోసం ఒక సులభమైన మూడు-tier scheme పనిచేస్తుంది:

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

Tiers నెమ్మదిగా మారతాయి మరియు వాటిని గురించి తర్కించడం సులభం. ఈ guide లోని మిగతా అంతా వాటిపై ఆధారపడి ఉంటుంది.

దశ 2: identity, credentials మరియు authorization ఎలా భిన్నంగా ఉంటాయి?

మూడు ప్రశ్నలు తరచుగా కలిసి గందరగోళమవుతాయి:

1. ఎవరు లేదా ఏమి act చేస్తోంది? ఇది actor evidence: ఒక interactive person, AI సహాయంతో ఉన్న person, ఒక agent, లేదా Unknown, verified లేదా declared వంటి basis తో.
2. ఏ credential presented చేయబడింది? ఒక session cookie, ఒక API key, ఒక OAuth access token.
3. ఈ credential ఈ resource పై ఈ చర్య చేయడానికి అనుమతించబడిందా? ఇది authorization.

ఒక verified agent signature (RFC 9421) మొదటి ప్రశ్నకు బాగా సమాధానం ఇస్తుంది. అది మూడవ ప్రశ్న గురించి ఏమీ చెప్పదు, దీనిని signed AI agent requests ఏమి నిరూపిస్తాయి, మరియు ఏమి నిరూపించవు లో వివరంగా చూడవచ్చు. సరైన 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 ఫలితం అనుకూలంగా ఉందని authorization ఎప్పుడూ సడలించబడదు. Actor context కేవలం అవసరాలను జోడిస్తుంది లేదా సమానంగా సురక్షితమైన మార్గాల మధ్య ఎంపిక చేస్తుంది.

దశ 3: ప్రజల తరఫున act చేసే agents కోసం delegated authority ఉపయోగించండి

ఒక agent user తరఫున act చేసినప్పుడు, user session ను తిరిగి ఉపయోగించనివ్వడం కంటే దానికి పరిమిత అధికారమున్న తన స్వంత credential ఇవ్వండి. OAuth 2.0 ప్రామాణిక సాధనం: user నిర్దిష్ట client కోసం నిర్దిష్ట 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 గా పరిగణిస్తుంది. మా post మీ MCP server ను ఎవరు పిలుస్తున్నారు? దీన్ని tool calls కు వర్తింపజేస్తుంది.

ఇది సున్నితమైన చర్యలకు మీకు అవసరమైనదాన్ని ఖచ్చితంగా అందిస్తుంది:

• token మీకు ఏ client act చేస్తోందో మరియు ఎవరికి బదులుగా చేస్తోందో చెబుతుంది.
• scopes అది ఏమి చేయగలదో పరిమితం చేస్తాయి. calendar:write ఉన్న scheduling agent password మార్చలేడు.
• user తన స్వంత credentials మార్చకుండా grant ను revoke చేయగలడు, మరియు OAuth 2.0 Token Revocation (RFC 7009) ఒక token ఇక చెల్లదని authorization server కి client ఎలా చెబుతుందో నిర్వచిస్తుంది.
• audit logs లో action ను user కాదు, agent చేశాడని కనిపిస్తుంది.

మీ app ఇప్పటివరకు delegated credentials కు మద్దతు ఇవ్వకపోతే, agents కు తరచుగా అవసరమయ్యే చర్యల కోసం దానిని ప్రాధాన్యంగా తీసుకోండి. automated access కోసం ఇది అత్యంత ప్రభావవంతమైన control ఒక్కటే.

దశ 4: step-up check ఎప్పుడు అడగాలి?

Step-up అంటే సున్నితమైన చర్య జరిగిన క్షణంలో అదనపు assurance అడగడం. OAuth-protected APIs కోసం, RFC 9470 ప్రస్తుత token యొక్క authentication తగినంత బలంగా లేదా తాజాగా లేదని resource server client కు ఎలా చెబుతుందో నిర్వచిస్తుంది. సరైన step-up ఎవరు act చేస్తున్నారన్నదానిపై ఆధారపడి ఉంటుంది:

• Interactive person (Human, Human + AI): మళ్లీ ధృవీకరించడం (NIST SP 800-63B లోని reauthentication requirements చూడండి), WebAuthn పై నిర్మించిన passkey prompt, లేదా ఒక one-time code.
• Delegated credential ఉన్న agent: high-tier చర్య కోసం ప్రత్యేకంగా ఉన్న scope, user స్పష్టంగా grant చేసినది, లేదా out of band గా user కు పంపిన 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 ఫలితం step-up ను దాటవేయదని గమనించండి. అది interactive person కు తగిన step-up ను ఎంచుకుంటుంది. Inferences తప్పు కావచ్చు, కాబట్టి అవి check యొక్క ఆకారాన్ని మార్చాలి, కానీ దాన్ని తీసేయకూడదు.

దశ 5: తీర్పు అవసరమైన చోట human review కు route చేయండి

కొన్ని చర్యలు అరుదైనవి, అధిక ప్రభావం కలిగినవి, మరియు సురక్షితంగా automation చేయడం కష్టం: customer data యొక్క bulk exports, credentials కోల్పోయిన తర్వాత account recovery, లేదా ఒక organization ను delete చేయడం. వీటి కోసం review queue ఏదైనా automated rule కంటే మెరుగైనది.

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: tier వారీగా failure behavior ఎంచుకోండి

Actor evaluation timeout కావచ్చు లేదా evidence లేకపోవచ్చు. ముందుగానే ఏమి జరుగుతుందో నిర్ణయించండి.

• Low tier: fail open. Request సాధారణంగా కొనసాగుతుంది.
• Medium tier: సాధారణ authorization అమల్లో ఉండగా fail open.
• High tier: existing strong check కు fail closed. Missing actor evidence protection ను ఎప్పుడూ బలహీనపరచదు, మరియు అది మీ సాధారణ checks లోపలుగా పాస్ అయ్యే request ను ఎప్పుడూ block చేయదు.

ముఖ్య లక్షణం symmetry. Actor evaluation లో failure, మీరు actor context జోడించే ముందు ఉన్నంత సురక్షితంగా, మరియు ఉన్నంత అందుబాటులో, చర్యను వదిలివేయాలి.

దశ 7: ఇన్‌ఫరెన్స్‌ల ఆధారంగా ప్రజల గురించి ప్రభావవంతమైన నిర్ణయాలు తీసుకోకండి

Inferred classification అనేది ఒక interaction గురించి evidence, ఒక వ్యక్తి గురించి నిజం కాదు. Session automated గా లేదా AI-assisted గా కనిపించిందని ఎవరికైనా job application, credit decision, exam result, housing లేదా అవసరమైన సేవకు access నిరాకరించవద్దు. అలాంటి flows లో, actor context ను human review లేదా ప్రత్యామ్నాయ verification path వంటి process ను ఎంచుకోవడానికి ఉపయోగించండి, మరియు వ్యక్తి దాన్ని పూర్తి చేయగలిగేలా చూడండి.

ఇది fairness principle కూడా, practical one కూడా. Inferences లో false positives ఉంటాయి, మరియు అలాంటి flows లో false positive ఖర్చు తప్పు చేయని వ్యక్తిపైనే పడుతుంది.

దశ 8: ముందుగా observation తో rollout చేయండి

ఇది నిజమైన requests ను ప్రభావితం చేయడానికి ముందు, observation మరియు preview mode లో నడపండి:

1. tier, actor class, basis, credential type, మరియు మీ policy కోరే step-up ను record చేయండి.
2. class వారీగా high-tier requests నమూనాలను review చేయండి. Legitimate agents delegated credentials ను ఉపయోగిస్తున్నారా, లేదా user sessions ను తిరిగి ఉపయోగిస్తున్నారా?
3. మీరు కనుగొన్న gaps ను సరిచేయండి, తరచుగా scoped credentials అందించడం ద్వారా, enforce చేసే ముందు.
4. ఒకే route యొక్క చిన్న భాగంలో enforce చేయండి, completion rates ను కొలవండి, తర్వాత విస్తరించండి.

దశ 9: "ఎవరు మరియు ఎవరికి బదులుగా" అనే ప్రశ్నకు సమాధానమిచ్చే audit trail ఉంచండి

ప్రతి high-tier చర్య కోసం, తర్వాత ఏమి జరిగిందో పునర్నిర్మించడానికి తగినంత నమోదు చేయండి:

• request సమయంలో actor class మరియు basis,
• credential type, అది ఇచ్చిన client, మరియు అది ప్రాతినిధ్యం వహించే subject (OAuth 2.0 Token Exchange, RFC 8693, ఇలాంటి "acting for" సంబంధాన్ని ఖచ్చితంగా నమోదు చేయడానికి act claim ను నిర్వచిస్తుంది),
• చర్యను authorized చేసిన 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 ను person లేదా assistant delete చేశారా, మరియు దాన్ని ఎవరు approve చేశారు" వంటి ప్రశ్నకు స్పష్టమైన సమాధానం ఉంటుంది. అది incident response ను వేగవంతం చేస్తుంది, మరియు మీ app లో automated help బాధ్యతాయుతంగా ఉందని users కు నమ్మకం ఇస్తుంది.

ఒక పని ఉదాహరణ

ఒక project management app users కోసం ఒక assistant task due dates update చేస్తోంది, మరియు అప్పుడప్పుడు entire 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 తిరిగి ఉపయోగించిన session cookie తో అదే export ను ప్రయత్నిస్తుంది. ఉన్న re-authentication prompt వర్తిస్తుంది, అది ముందు ఎలా ఉన్నదో అచ్చుగా అలాగే.

Agent అయినందుకు ఎవరూ block చేయబడలేదు. ప్రతి high-impact చర్య స్పష్టమైన అధికారంతో సాగింది.

Proof of Actor ఎక్కడ సరిపోతుంది

Proof of Actor ఈ model యొక్క actor వైపును అందిస్తుంది: ఎవరు లేదా ఏమి act చేస్తున్నారు, మరియు ఏ basis పై. మీ application authentication, authorization, మరియు తుది నిర్ణయాన్ని కొనసాగిస్తుంది. Actor ను Detect చేయండి, ప్రతి class మీ సున్నితమైన routes ను ఎలా ఉపయోగిస్తుందో Understand చేయండి, మరియు ప్రతి request ను సరైన assurance స్థాయికి Route చేయండి.

మా team తో మీ application కోసం దీన్ని design చేయడానికి, early access కోసం apply చేయండి. 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: మరింత బలమైన లేదా తాజా 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 ఏమి స్థాపిస్తుందో