சேர்மான செயல்களைத் தடை செய்யாமல், உணர்வுப்பூர்வ செயல்களை எப்படி பாதுகாப்பது

உணர்வுப்பூர்வ செயல்களில் agents-ஐ ஏன் நேரடியாகத் தடுக்கக்கூடாது?

உங்கள் application-இல் சில செயல்கள் மற்றவற்றைவிட முக்கியமானவை. ஒரு கடவுச்சொல்லை மாற்றுதல், ஒரு team member-ஐ சேர்த்தல், data-வை export செய்தல், ஒரு project-ஐ நீக்குதல், ஒரு order-ஐ approve செய்தல்: இவற்றில் ஏதேனும் சரியான அதிகாரமின்றி நடந்தால், சேதம் உண்மையானது.

அதே நேரத்தில், உங்கள் app-இல் நடைபெறும் நியாயமான வேலைகளில் அதிகமானவை automation மூலம் நடைபெறுகின்றன. ஒரு user ஒரு assistant-ஐ தன் settings-ஐ update செய்யச் சொல்கிறார். ஒரு partner integration அட்டவணைப்படி records-ஐ உருவாக்குகிறது. ஒரு internal agent support tickets-ஐ file செய்கிறது. உணர்வுப்பூர்வ routes-இலிருந்து ஒவ்வொரு automated client-ஐயும் தடுக்குவது அந்த வேலையை உடைக்கிறது, மேலும் மக்களை manual effort-க்கு அல்லது பாதுகாப்பு செய்ய கடினமான workaround-களுக்கு தள்ளுகிறது.

பதில் "agents-ஐ block செய்" என்பதும் இல்லை, "agents-ஐ நம்பு" என்பதும் இல்லை. அது action-இன் risk, request-க்கு பின்னுள்ள authority, மற்றும் actor பற்றிய evidence ஆகியவை ஒவ்வொன்றும் தனித்த பங்கை வகிக்கும் ஒரு மாதிரி. இந்த guide அந்த மாதிரியை உருவாக்குகிறது. இதற்கு அடிப்படையான சிந்தனைக்காக, மனிதர்களுக்கும் AI agents-க்கும் app-level policies-ஐ வடிவமைப்பது என்பதைப் பார்க்கவும்.

படி 1: உங்கள் routes-ஐ risk அடிப்படையில் தரவரிசைப்படுத்துங்கள்

முதலில் clients-ஐ அல்ல, actions-ஐ வகைப்படுத்தத் தொடங்குங்கள். பெரும்பாலான applications-க்கு ஒரு எளிய மூன்று-அடுக்கு திட்டம் போதுமானது:

code review-இல் அது தெளிவாகத் தோன்றும்படி, route configuration-இல் அந்த tier-ஐ எழுதுங்கள்:

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 மெதுவாக மாறும், மேலும் அவற்றைப் பற்றி reasoning செய்வது எளிது. இந்த guide-இல் உள்ள மற்ற அனைத்தும் அவற்றை அடிப்படையாகக் கொண்டது.

படி 2: identity, credentials மற்றும் authorization எவ்வாறு வேறுபடுகின்றன?

மூன்று கேள்விகள் அடிக்கடி ஒன்றாக கலக்கப்படுகின்றன:

1. யார் அல்லது என்ன செய்கிறது? இது actor evidence: தொடர்பு கொள்ளும் மனிதர், AI உதவியுடன் செயல்படும் மனிதர், ஒரு 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 மூன்றாவது கேள்விக்குப் பதில் அளிக்கிறது. அது முதல் கேள்வியைப் பற்றி மிகக் குறைவாகவே சொல்கிறது. ஒரு உயர்-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: மனிதர்களின் சார்பாக செயல்படும் agents-க்கு delegated authority-ஐ பயன்படுத்துங்கள்

ஒரு agent ஒரு user-ஐ பிரதிநிதித்துவப்படுத்தி செயல்படும் போது, user-ன் session-ஐ மறுபயன்படுத்த விடாமல், வரம்பிட்ட authority-உடைய தனித்த 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 பாதுகாக்கப்பட்ட 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 இனி செல்லுபடியாக இருக்க வேண்டாம் என்று client authorization server-க்கு எவ்வாறு கூற வேண்டும் என்பதை வரையறுக்கிறது.
• Audit logs-ல் action-ஐ செய்தது user அல்ல, agent என்பது தெரிகிறது.

உங்கள் app இன்னும் delegated credentials-ஐ ஆதரிக்கவில்லை என்றால், agents அதிகமாக தேவைப்படும் actions-க்கு இதை முன்னுரிமை அளியுங்கள். automated access-க்கு இது மிகச் செயல்திறன் வாய்ந்த control ஆகும்.

படி 4: step-up check-ஐ எப்போது கேட்க வேண்டும்?

Step-up என்பது உணர்வுப்பூர்வ action நடக்கும் தருணத்தில் கூடுதல் assurance-ஐக் கேட்பதைக் குறிக்கும். OAuth-ஆல் பாதுகாக்கப்பட்ட APIs-க்கு, RFC 9470 resource server தற்போதைய token-இன் authentication போதுமான வலிமை உடையதல்ல அல்லது சமீபத்தியதல்ல என்பதை client-க்கு எவ்வாறு தெரிவிக்க வேண்டும் என்பதை வரையறுக்கிறது. சரியான step-up யார் செயல்படுகிறார் என்பதன் மீது சார்ந்துள்ளது:

• தொடர்பு கொள்ளும் மனிதர் (Human, Human + AI): மீண்டும் authentication செய்யுதல் (NIST SP 800-63B-இல் உள்ள reauthentication தேவைகளைப் பார்க்கவும்), WebAuthn-ஐ அடிப்படையாகக் கொண்ட passkey prompt, அல்லது ஒருமுறை code.
• Delegated credential உடைய agent: user-ஆல் தெளிவாக வழங்கப்பட்ட உயர்-tier செயலுக்கான தனித்த scope, அல்லது வெளி-சேனல் மூலம் user-க்கு அனுப்பப்படும் உறுதிப்படுத்தல்.
• 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-ஐத் தவிர்க்காது என்பதை கவனிக்கவும். அது தொடர்பு கொள்ளும் மனிதருக்கு பொருத்தமான step-up-ஐத் தேர்வு செய்கிறது. Inferences தவறாக இருக்கலாம், ஆகையால் அவை check-இன் வடிவத்தை மாற்ற வேண்டும், அதை நீக்கக்கூடாது.

படி 5: தீர்ப்பு தேவைப்படும் இடங்களில் மனித மதிப்பாய்வுக்கு வழிமாற்றுங்கள்

சில actions அரிதானவை, உயர்தாக்கம் உடையவை, மேலும் பாதுகாப்பாக automate செய்ய கடினமானவை: customer data-வின் bulk exports, lost credentials-க்குப் பிறகு account recovery, அல்லது ஒரு organization-ஐ நீக்குதல். இவற்றுக்கு எந்த automated rule-ஐவிடவும் review queue சிறந்ததாக இருக்கலாம்.

Actor context மதிப்பாய்வாளருக்கு evidence-ஐக் கொடுத்து மதிப்பாய்வை வேகமாகவும் நியாயமாகவும் ஆக்குகிறது: class, basis, பயன்படுத்தப்பட்ட credential, அதே போன்ற requests-இன் வரலாறு. மதிப்பாய்வாளர் தீர்மானிக்கிறார். 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 நடத்தைத் தேர்வு செய்யுங்கள்

Actor evaluation timeout ஆகலாம் அல்லது evidence இல்லாமலும் இருக்கலாம். முன்கூட்டியே என்ன நடக்கும் என்பதைத் தீர்மானியுங்கள்.

• குறைந்த tier: fail open. Request சாதாரணமாக தொடரும்.
• நடுத்தர tier: இயல்பான authorization உடன் fail open.
• உயர் tier: உள்ளேயுள்ள வலுவான check-க்கு fail closed. Actor evidence இல்லாமை பாதுகாப்பை ஒருபோதும் பலவீனப்படுத்தாது, மேலும் அது உங்கள் சாதாரண checks-ல் ஏற்கனவே கடந்திருக்கும் ஒரு request-ஐயும் தடுக்காது.

முக்கிய பண்பு சமச்சீர்மை. Actor evaluation-இல் தோல்வி ஏற்பட்டாலும், action-ஐ நீங்கள் actor context-ஐச் சேர்ப்பதற்கு முன் இருந்த அளவு பாதுகாப்பாகவும், அதே அளவு கிடைக்கத்தக்கதாகவும் விட்டுவிட வேண்டும்.

படி 7: Inferences-ஐ அடிப்படையாகக் கொண்டு மக்களைப் பற்றிய முக்கிய முடிவுகளை எடுக்காதீர்கள்

ஒரு inferred classification என்பது ஒரு interaction பற்றிய evidence, ஒரு நபரைப் பற்றிய உண்மை அல்ல. ஒரு session automated ஆகத் தெரிந்தது அல்லது AI உதவியுடன் இருந்தது என்பதற்காக ஒருவரின் job application-ஐ நிராகரிக்காதீர்கள், credit decision-ஐ மறுக்காதீர்கள், exam result-ஐ மறுக்காதீர்கள், housing-ஐ மறுக்காதீர்கள், அல்லது ஒரு அத்தியாவசிய service-க்கு அணுகலை மறுக்காதீர்கள். அத்தகைய flows-இல், மனித மதிப்பாய்வு அல்லது மாற்று verification பாதை போன்ற process-ஐத் தேர்வு செய்ய actor context-ஐப் பயன்படுத்துங்கள், மேலும் அந்த நபர் அதை முடிக்க முடியும் என்பதை உறுதிசெய்யுங்கள்.

இது நியாயக் கோட்பாடாகவும் நடைமுறை கோட்பாடாகவும் உள்ளது. Inferences-க்கு false positives இருக்கின்றன, மேலும் இந்த flows-இல் false positive-இன் செலவு எந்தத் தவறும் செய்யாத ஒருவர்மீது விழுகிறது.

படி 8: முதலில் observation-உடன் வெளியிடுங்கள்

இது உண்மையான requests-ஐ பாதிக்கும் முன், அதை observation மற்றும் preview mode-இல் இயக்குங்கள்:

1. Tier, actor class, basis, credential type, மற்றும் உங்கள் policy கேட்கும் step-up-ஐப் பதிவு செய்யுங்கள்.
2. High-tier requests-இன் மாதிரிகளை class அடிப்படையில் மதிப்பாய்வு செய்யுங்கள். Legitimate agents delegated credentials-ஐப் பயன்படுத்துகிறார்களா, அல்லது user sessions-ஐ மறுபயன்படுத்துகிறார்களா?
3. நீங்கள் கண்ட இடைவெளிகளை சரிசெய்யுங்கள், பெரும்பாலும் scoped credentials-ஐ வழங்குவதன் மூலம், enforce செய்வதற்கு முன்.
4. ஒரு single route-இன் சிறிய பகுதி மீது enforce செய்து, completion rates-ஐ அளந்து, பின்னர் விரிவாக்குங்கள்.

படி 9: "யார் மற்றும் யாரின் சார்பாக" என்பதற்கு பதில் அளிக்கும் audit trail-ஐ வைத்திருங்கள்

ஒவ்வொரு high-tier action-க்கும், பின்னர் நடந்ததை மீண்டும் உருவாக்கத் தேவையான அளவு விவரங்களைப் பதிவு செய்யுங்கள்:

• request நேரத்தில் இருந்த actor class மற்றும் basis,
• credential வகை, அது வழங்கப்பட்ட client, மற்றும் அது பிரதிநிதிக்கும் subject (OAuth 2.0 Token Exchange, RFC 8693 இதுபோன்ற "சார்பாக செயல்படுதல்" உறவைத் துல்லியமாகப் பதிவு செய்ய act claim-ஐ வரையறுக்கிறது),
• action-ஐ authorize செய்த 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-ஐ ஒரு மனிதர் அல்லது ஒரு assistant நீக்கினாரா, அதை யார் approve செய்தார்" போன்ற கேள்விக்கு தெளிவான பதில் இருக்கும். இது incident response-ஐ வேகப்படுத்துகிறது மற்றும் உங்கள் app-இல் automated help-க்கு பொறுப்புணர்வு இருக்கிறது என்ற நம்பிக்கையை users-க்கு அளிக்கிறது.

ஒரு செயல்பாட்டு உதாரணம்

ஒரு project management app, users-க்காக task due dates-ஐ புதுப்பிக்கும் ஒரு assistant-ஐ காண்கிறது, மேலும் சில சமயங்களில் முழு projects-ஐ export செய்ய முயல்கிறது.

• Task-ஐப் புதுப்பித்தல் நடுத்தர tier. Assistant tasks:write உடைய ஒரு OAuth token-ஐப் பயன்படுத்துகிறது. Authorized, step-up இல்லை. Allowed.
• ஒரு project-ஐ export செய்தல் உயர் tier. Assistant-ன் token-க்கு export:bulk இல்லை. App user-க்கு ஒரு confirmation request-ஐ அனுப்புகிறது. User approve செய்கிறார், மேலும் app அந்த client-க்கு scope-ஐ வழங்குகிறது.
• ஒரு Unknown client மறுபயன்படுத்தப்பட்ட session cookie-உடன் அதே export-ஐ முயல்கிறது. உள்ள existing re-authentication prompt பயன்படுத்தப்படுகிறது, முன்பு இருந்ததுபோலவே.

யாரும் agent என்பதற்காக தடுக்கப்படவில்லை. ஒவ்வொரு உயர்தாக்கம் உள்ள action-வும் தெளிவான authority-ஐக் கொண்டிருந்தது.

Proof of Actor எங்கு பொருந்துகிறது

Proof of Actor இந்த மாதிரியின் actor பக்கத்தை வழங்குகிறது: யார் அல்லது என்ன செய்கிறது, எந்த basis-இல் செய்கிறது என்பதைக் கூறுகிறது. உங்கள் application authentication, authorization மற்றும் இறுதி முடிவைத் தானே வைத்திருக்கிறது. Actor-ஐ Detect செய்யுங்கள், ஒவ்வொரு class-மும் உங்கள் உணர்வுப்பூர்வ routes-ஐ எவ்வாறு பயன்படுத்துகிறது என்பதை Understand செய்யுங்கள், மேலும் ஒவ்வொரு request-ஐயும் சரியான assurance நிலைக்கு Route செய்யுங்கள்.

உங்கள் application-க்காக இதை எங்கள் team-உடன் வடிவமைக்க, early access-க்கு விண்ணப்பிக்கவும். SaaS சூழல்களை மேலும் விவரமாக அறிய, 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 தேவை என்பதை signal செய்வது
• 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 வழிகாட்டல்
• W3C Web Authentication (WebAuthn) Level 3: passkey prompts-க்கு பின்னுள்ள standard
• RFC 9421: HTTP Message Signatures: ஒரு verified agent signature என்ன நிறுவுகிறது