ಸಂವೇದನಾಶೀಲ ಕ್ರಿಯೆಗಳನ್ನು ಮಾನ್ಯ ಏಜೆಂಟ್‌ಗಳನ್ನು ತಡೆದೇ ಹೇಗೆ ರಕ್ಷಿಸುವುದು

ಏಜೆಂಟ್‌ಗಳನ್ನು ಸಂವೇದನಾಶೀಲ ಕ್ರಿಯೆಗಳಿಂದ ಸರಿಯಾಗಿ ಏಕೆ ತಡೆಯಬಾರದು?

ನಿಮ್ಮ application ನಲ್ಲಿ ಕೆಲವು ಕ್ರಿಯೆಗಳು ಇತರಕ್ಕಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿರುತ್ತವೆ. password ಬದಲಿಸುವುದು, ತಂಡದ ಸದಸ್ಯರನ್ನು ಸೇರಿಸುವುದು, data export ಮಾಡುವುದು, project ಅಳಿಸುವುದು, order ಅನುಮೋದಿಸುವುದು: ಇವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಸರಿಯಾದ authority ಇಲ್ಲದೆ ನಡೆದರೆ, ಹಾನಿ ನಿಜವಾಗಿರುತ್ತದೆ.

ಅದೇ ಸಮಯದಲ್ಲಿ, ನಿಮ್ಮ app ನಲ್ಲಿ ಮಾನ್ಯ ಕೆಲಸದ ಹೆಚ್ಚಿನ ಭಾಗ automation ಮೂಲಕ ನಡೆಯುತ್ತದೆ. ಬಳಕೆದಾರನು assistant ಗೆ ತನ್ನ settings ಅನ್ನು update ಮಾಡುವಂತೆ ಕೇಳುತ್ತಾನೆ. partner integration ನಿಗದಿತ ವೇಳಾಪಟ್ಟಿಯಲ್ಲಿ records ರಚಿಸುತ್ತದೆ. internal agent support tickets ಸಲ್ಲಿಸುತ್ತದೆ. sensitive route ಗಳಿಂದ ಪ್ರತಿಯೊಂದು automated client ಅನ್ನು block ಮಾಡುವುದರಿಂದ ಆ ಕೆಲಸ ಮುರಿಯುತ್ತದೆ ಮತ್ತು ಜನರನ್ನು manual effort ಗೆ ಅಥವಾ secure ಮಾಡುವುದು ಕಷ್ಟವಾದ workaround ಗಳಿಗೆ ಹಿಂತಿರುಗುವಂತೆ ಮಾಡುತ್ತದೆ.

ಉತ್ತರ "agents ಅನ್ನು block ಮಾಡಿ" ಅಥವಾ "agents ಅನ್ನು ನಂಬಿ" ಎಂಬುದಲ್ಲ. ಇಲ್ಲಿ action ನ risk, request ಹಿಂದಿನ authority, ಮತ್ತು actor ಬಗ್ಗೆ ಇರುವ evidence - ಇವೆಲ್ಲವೂ ವಿಭಿನ್ನ ಪಾತ್ರ ವಹಿಸುವ model ಆಗಿದೆ. ಈ guide ಆ model ಅನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ. ಇದರ ಹಿಂದಿನ ವಿಶಾಲ ಚಿಂತನೆಗಾಗಿ humans ಮತ್ತು AI agents ಗಾಗಿ app-level policies ವಿನ್ಯಾಸಗೊಳಿಸುವುದು ನೋಡಿ.

ಹಂತ 1: ನಿಮ್ಮ route ಗಳನ್ನು risk ಆಧಾರದಲ್ಲಿ ಹಂತೀಕರಿಸಿ

ಮೊದಲು clients ಅನ್ನು ಅಲ್ಲ, ಕ್ರಿಯೆಗಳನ್ನು ವರ್ಗೀಕರಿಸಿ. ಸರಳ ಮೂರು-ಹಂತದ scheme ಹೆಚ್ಚಿನ 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",
};

ಹಂತಗಳು ನಿಧಾನವಾಗಿ ಬದಲಾಗುತ್ತವೆ ಮತ್ತು ಅವುಗಳ ಬಗ್ಗೆ 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 ಮೇಲೆ ಈ ಕ್ರಿಯೆ ಮಾಡಲು ಅನುಮತಿದೆಯೇ? ಇದು authorization.

ಪರಿಶೀಲಿತ agent signature (RFC 9421) ಮೊದಲ ಪ್ರಶ್ನೆಗೆ ಚೆನ್ನಾಗಿ ಉತ್ತರಿಸುತ್ತದೆ. ಆದರೆ ಅದು ಮೂರನೆಯ ಪ್ರಶ್ನೆಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಈ ವಿಷಯವನ್ನು signed AI agent requests ಏನು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ, ಮತ್ತು ಏನು ಅಲ್ಲ ನಲ್ಲಿ ವಿವರವಾಗಿ ನೋಡಬಹುದು. ಸರಿಯಾದ scope ಹೊಂದಿರುವ OAuth token ಮೂರನೆಯ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಅದು ಮೊದಲ ಪ್ರಶ್ನೆಯ ಬಗ್ಗೆ ಕಡಿಮೆ ಮಾತ್ರ ಹೇಳುತ್ತದೆ. ಹೆಚ್ಚಿನ-ಹಂತದ ಕ್ರಿಯೆಗೆ ನಿಮ್ಮ ನಿರ್ಧಾರಕ್ಕೆ ಮೂರನೆಯ ಪ್ರಶ್ನೆಗೆ ಸದಾ ಉತ್ತಮ ಉತ್ತರ ಬೇಕು, ಮತ್ತು ಮೊದಲ ಪ್ರಶ್ನೆಯನ್ನು ಬಳಸಿ ಹೆಚ್ಚುವರಿ 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 ಬಳಕೆದಾರನ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿದಾಗ, ಬಳಕೆದಾರನ session ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡಲು ಬಿಡುವ ಬದಲು ಅದಕ್ಕೆ ಸೀಮಿತ authority ಹೊಂದಿದ ತನ್ನದೇ credential ನೀಡಿ. OAuth 2.0 ಮಾನಕ ಸಾಧನವಾಗಿದೆ: ಬಳಕೆದಾರನು ನಿರ್ದಿಷ್ಟ client ಗೆ ನಿರ್ದಿಷ್ಟ scopes ಅನ್ನು approve ಮಾಡುತ್ತಾನೆ, ಮತ್ತು token ಆ client ಅನ್ನು ದಾಖಲಿಸುತ್ತದೆ. RFC 9700, OAuth 2.0 Security Best Current Practice, ಅದನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಹೇಗೆ deploy ಮಾಡಬೇಕು ಎಂದು ವಿವರಿಸುತ್ತದೆ. MCP server ಗಳೂ ಇದೇ ಮಾದರಿಯನ್ನು ಅನುಸರಿಸುತ್ತವೆ: MCP authorization specification protected MCP server ಅನ್ನು OAuth 2.1 resource server ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ. ನಮ್ಮ post ನಿಮ್ಮ MCP server ಗೆ ಯಾರು ಕರೆ ಮಾಡುತ್ತಿದ್ದಾರೆ? ಇದನ್ನು tool calls ಗೆ ಅನ್ವಯಿಸುತ್ತದೆ.

ಇದರಿಂದ ಸಂವೇದನಾಶೀಲ ಕ್ರಿಯೆಗಳಿಗೆ ನಿಮಗೆ ನಿಖರವಾಗಿ ಬೇಕಾಗಿರುವುದು ಸಿಗುತ್ತದೆ:

• token ಯಾವ client ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಮತ್ತು ಯಾರ ಪರವಾಗಿ ಎಂದು ತಿಳಿಸುತ್ತದೆ.
• scopes ಅದು ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತವೆ. calendar:write ಹೊಂದಿರುವ scheduling agent password ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
• ಬಳಕೆದಾರನು ತನ್ನ credentials ಬದಲಾಯಿಸದೇ grant ಅನ್ನು revoke ಮಾಡಬಹುದು, ಮತ್ತು OAuth 2.0 Token Revocation (RFC 7009) token ಇನ್ನು ಮಾನ್ಯವಾಗಿರಬಾರದು ಎಂದು client authorization server ಗೆ ಹೇಗೆ ತಿಳಿಸಬೇಕು ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ.
• audit logs ನಲ್ಲಿ agent, ಬಳಕೆದಾರನಲ್ಲ, ಕ್ರಿಯೆಯನ್ನು ನಡೆಸಿದನೆಂದು ತೋರಿಸುತ್ತದೆ.

ನಿಮ್ಮ app ಇನ್ನೂ delegated credentials ಅನ್ನು support ಮಾಡುತ್ತಿಲ್ಲದಿದ್ದರೆ, agents ಹೆಚ್ಚಾಗಿ ಅಗತ್ಯವಿರುವ ಕ್ರಿಯೆಗಳಿಗೆ ಅದನ್ನು ಪ್ರಾಥಮ್ಯ ನೀಡಿ. ಸ್ವಯಂಚಾಲಿತ access ಗೆ ಇದು ಒಂದೇ ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿ control.

ಹಂತ 4: step-up ಪರಿಶೀಲನೆ ಯಾವಾಗ ಕೇಳಬೇಕು?

Step-up ಎಂದರೆ ಸಂವೇದನಾಶೀಲ ಕ್ರಿಯೆಯ ಕ್ಷಣದಲ್ಲಿ ಹೆಚ್ಚುವರಿ assurance ಕೇಳುವುದು. OAuth-ರಿಂದ protected ಇರುವ APIs ಗಾಗಿ, RFC 9470 resource server ನು client ಗೆ current token ನ authentication ಸಾಕಷ್ಟು ಬಲವಾಗಿಲ್ಲ ಅಥವಾ ಸಾಕಷ್ಟು ಹೊಸದಾಗಿಲ್ಲ ಎಂದು ಹೇಗೆ ತಿಳಿಸಬೇಕು ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಸರಿಯಾದ step-up ಯಾರು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ:

• ಸಂವಾದಾತ್ಮಕ ವ್ಯಕ್ತಿ (Human, Human + AI): ಪುನಃ authentication ( NIST SP 800-63B ಯಲ್ಲಿನ reauthentication ಅಗತ್ಯಗಳನ್ನು ನೋಡಿ), WebAuthn ಆಧಾರಿತ passkey prompt, ಅಥವಾ ಒಂದು ಬಾರಿಯ code.
• delegated credential ಹೊಂದಿರುವ agent: ಬಳಕೆದಾರನು ಸ್ಪಷ್ಟವಾಗಿ grant ಮಾಡಿದ ಹೆಚ್ಚಿನ-ಹಂತದ ಕ್ರಿಯೆಗೆ ಮೀಸಲಾದ scope, ಅಥವಾ ಬಳಕೆದಾರಿಗೆ out of band ಕಳುಹಿಸಿದ 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 ಅನ್ನು ತಪ್ಪಿಸುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಅದು ಸಂವಾದಾತ್ಮಕ ವ್ಯಕ್ತಿಗೆ ಸೂಕ್ತವಾದ step-up ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. inference ಗಳು ತಪ್ಪಾಗಬಹುದು, ಆದ್ದರಿಂದ ಅವು ಪರಿಶೀಲನೆಯ ಆಕಾರವನ್ನು ಬದಲಿಸಬೇಕು, ಆದರೆ ಅದನ್ನು ತೆಗೆದುಹಾಕಬಾರದು.

ಹಂತ 5: ನಿರ್ಣಯ ಅಗತ್ಯವಿರುವಲ್ಲಿ ಮಾನವ ವಿಮರ್ಶೆಗೆ route ಮಾಡಿ

ಕೆಲವು ಕ್ರಿಯೆಗಳು ವಿರಳ, ಹೆಚ್ಚಿನ ಪರಿಣಾಮದ ಮತ್ತು ಸುರಕ್ಷಿತವಾಗಿ automation ಮಾಡಲು ಕಷ್ಟಕರ: customer data ಗಳ bulk export, credentials ಕಳೆದುಹೋದ ನಂತರ account recovery, ಅಥವಾ organization ಅಳಿಸುವುದು. ಇವುಗಳಲ್ಲಿ, ಯಾವುದೇ automated rule ಗಿಂತ review queue ಹೆಚ್ಚಾಗಿ ಉತ್ತಮವಾಗಿರುತ್ತದೆ.

Actor context ವಿಮರ್ಶಕರಿಗೆ ಸಾಕ್ಷ್ಯವನ್ನು ನೀಡುವ ಮೂಲಕ ವಿಮರ್ಶೆಯನ್ನು ವೇಗವಾಗಿ ಮತ್ತು ನ್ಯಾಯವಾಗಿ ಮಾಡುತ್ತದೆ: ವರ್ಗ, basis, ಬಳಸಿದ credential, ಸಮಾನ requests ಗಳ ಇತಿಹಾಸ. ವಿಮರ್ಶಕನು ನಿರ್ಧರಿಸುತ್ತಾನೆ. ವರ್ಗೀಕರಣವು ತಿಳಿಸುತ್ತದೆ.

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 ಮೌಲ್ಯಮಾಪನ timeout ಆಗಬಹುದು ಅಥವಾ ಸಾಕ್ಷ್ಯ ಕೊರತೆಯಾಗಬಹುದು. ಏನಾಗಬೇಕು ಎಂದು ಮುಂಚಿತವಾಗಿ ನಿರ್ಧರಿಸಿ.

• ಕಡಿಮೆ ಹಂತ: fail open. request ಸಾಮಾನ್ಯವಾಗಿ ಮುಂದುವರಿಯುತ್ತದೆ.
• ಮಧ್ಯಮ ಹಂತ: ಸಾಮಾನ್ಯ authorization ಜಾರಿಯಲ್ಲಿರುವ ಸ್ಥಿತಿಯಲ್ಲಿ fail open.
• ಹೆಚ್ಚು ಹಂತ: ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ strong check ಗೆ fail closed. ಕಾಣೆಯಾದ actor evidence ರಕ್ಷಣೆಯನ್ನು ಎಂದಿಗೂ ದುರ್ಬಲಗೊಳಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅದು ನಿಮ್ಮ ಸಾಮಾನ್ಯ checks ಗಳಲ್ಲಿ ಪಾಸಾಗುತ್ತಿತ್ತು ಎಂಬ request ಅನ್ನು ಎಂದಿಗೂ block ಮಾಡುವುದಿಲ್ಲ.

ಮುಖ್ಯ ಗುಣ symmetry. actor evaluation ನಲ್ಲಿ failure ಇದ್ದರೂ, ನೀವು actor context ಸೇರಿಸುವ ಮೊದಲು ಅದು ಎಷ್ಟು ಸುರಕ್ಷಿತವಾಗಿತ್ತೋ ಮತ್ತು ಎಷ್ಟು ಲಭ್ಯವಾಗಿತ್ತೋ, ಅದೇ ರೀತಿಯಲ್ಲಿ action ಉಳಿಯಬೇಕು.

ಹಂತ 7: inference ಗಳ ಆಧಾರದಲ್ಲಿ ಜನರ ಬಗ್ಗೆ ಪರಿಣಾಮಕಾರಿ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಡಿ

inferred ವರ್ಗೀಕರಣವು interaction ಬಗ್ಗೆ ಇರುವ evidence, ವ್ಯಕ್ತಿಯ ಬಗ್ಗೆ ಇರುವ ಸತ್ಯವಲ್ಲ. session automation ಆಗಿ ಅಥವಾ AI ಸಹಾಯದಿಂದ ಕಾಣಿಸಿಕೊಂಡಿತು ಎಂಬ ಕಾರಣಕ್ಕೆ, ಯಾರಿಗಾದರೂ ಉದ್ಯೋಗ ಅರ್ಜಿ, credit ನಿರ್ಧಾರ, ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶ, ವಸತಿ ಅಥವಾ ಅಗತ್ಯ ಸೇವೆಗೆ ಪ್ರವೇಶವನ್ನು ನಿರಾಕರಿಸಬೇಡಿ. ಇಂತಹ flows ನಲ್ಲಿ, actor context ಅನ್ನು ಮಾನವ ವಿಮರ್ಶೆ ಅಥವಾ ಪರ್ಯಾಯ verification ಮಾರ್ಗದಂತೆ ಪ್ರಕ್ರಿಯೆ ಆಯ್ಕೆ ಮಾಡಲು ಬಳಸಿ, ಮತ್ತು ವ್ಯಕ್ತಿ ಅದನ್ನು ಪೂರ್ಣಗೊಳಿಸಬಹುದೆಂದು ಖಚಿತಪಡಿಸಿ.

ಇದು fairness ತತ್ವವೂ ಹೌದು ಮತ್ತು ಪ್ರಾಯೋಗಿಕವೂ ಹೌದು. inference ಗಳಿಗೆ false positive ಗಳು ಇರುತ್ತವೆ, ಮತ್ತು ಇಂತಹ flows ನಲ್ಲಿ false positive ನ ವೆಚ್ಚವನ್ನು ತಪ್ಪೇನೂ ಮಾಡದ ವ್ಯಕ್ತಿಯೇ ಹೊರುತ್ತಾನೆ.

ಹಂತ 8: ಮೊದಲು observation ಮೂಲಕ ಬಿಡುಗಡೆ ಮಾಡಿ

ಇದರಿಂದ ನಿಜವಾದ requests ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಮೊದಲು, observation ಮತ್ತು preview mode ನಲ್ಲಿ ನಡೆಸಿ:

1. ಹಂತ, actor ವರ್ಗ, basis, credential type ಮತ್ತು ನಿಮ್ಮ policy ಅಗತ್ಯಪಡಿಸುವ step-up ಅನ್ನು ದಾಖಲಿಸಿ.
2. ವರ್ಗದ ಆಧಾರದಲ್ಲಿ ಹೆಚ್ಚಿನ-ಹಂತದ requests ಗಳ ಮಾದರಿಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಮಾನ್ಯ agents ಗಳು delegated credentials ಬಳಸುತ್ತಿದ್ದಾರೆಯೇ, ಅಥವಾ user sessions ಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತಿದ್ದಾರೆಯೇ?
3. ನೀವು ಕಂಡುಕೊಳ್ಳುವ gaps ಗಳನ್ನು ಸರಿಪಡಿಸಿ, ಬಹುಸಾರಿಗೆ scoped credentials ನೀಡುವ ಮೂಲಕ, ನೀವು enforce ಮಾಡುವ ಮೊದಲು.
4. ಒಂದೇ route ನ ಸಣ್ಣ ಭಾಗದಲ್ಲಿ enforce ಮಾಡಿ, completion rates ಅಳೆಯಿರಿ, ನಂತರ ವಿಸ್ತರಿಸಿ.

ಹಂತ 9: "ಯಾರು ಮತ್ತು ಯಾರ ಪರವಾಗಿ" ಎಂಬುದಕ್ಕೆ ಉತ್ತರ ನೀಡುವ audit trail ಇರಲಿ

ಪ್ರತಿಯೊಂದು ಹೆಚ್ಚಿನ-ಹಂತದ ಕ್ರಿಯೆಗೆ, ನಂತರ ಏನಾಯಿತು ಎಂಬುದನ್ನು ಮರುನಿರ್ಮಿಸಲು ಸಾಕಷ್ಟು ದಾಖಲಿಸಿ:

• request ಸಮಯದಲ್ಲಿನ actor ವರ್ಗ ಮತ್ತು basis,
• credential type, ಅದು ಯಾರಿಗೆ ನೀಡಲಾಗಿತ್ತು ಮತ್ತು ಅದು ಯಾರನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ ಎಂಬುದು (OAuth 2.0 Token Exchange, RFC 8693, ನಿಖರವಾಗಿ ಇಂತಹ "acting for" ಸಂಬಂಧವನ್ನು ದಾಖಲಿಸಲು act claim ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ),
• ಕ್ರಿಯೆಯನ್ನು 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 ನಲ್ಲಿ automation ಸಹಾಯ ಹೊಣೆಗಾರಿಕೆಯಿಂದ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬ ನಂಬಿಕೆಯನ್ನು ಬಳಕೆದಾರರಿಗೆ ನೀಡುತ್ತದೆ.

ಕಾರ್ಯನಿರ್ವಹಿಸಿದ ಉದಾಹರಣೆ

ಒಂದು project management app ನಲ್ಲಿ assistant ಬಳಕೆದಾರರಿಗಾಗಿ task due date ಗಳನ್ನು update ಮಾಡುತ್ತದೆ, ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಸಂಪೂರ್ಣ project ಗಳನ್ನು export ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ.

• ಒಂದು task ಅನ್ನು update ಮಾಡುವುದು ಮಧ್ಯಮ ಹಂತ. assistant tasks:write ಹೊಂದಿರುವ OAuth token ಅನ್ನು ಬಳಸುತ್ತದೆ. Authorized, step-up ಇಲ್ಲ. ಅನುಮತಿಸಲಾಗಿದೆ.
• project ಅನ್ನು export ಮಾಡುವುದು ಹೆಚ್ಚಿನ ಹಂತ. assistant ನ token ನಲ್ಲಿ export:bulk ಇಲ್ಲ. app ಬಳಕೆದಾರಿಗೆ confirmation request ಕಳುಹಿಸುತ್ತದೆ. ಬಳಕೆದಾರನು approve ಮಾಡುತ್ತಾನೆ, ಮತ್ತು app ಆ client ಗೆ scope ಅನ್ನು grant ಮಾಡುತ್ತದೆ.
• Unknown client ಮರುಬಳಕೆ ಮಾಡಿದ session cookie ಜೊತೆಗೆ ಅದೇ export ಅನ್ನು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ re-authentication prompt ಅನ್ವಯಿಸುತ್ತದೆ, ಅದು ಹಿಂದೆಯೇ ಹೇಗಿತ್ತೋ ಹಾಗೆಯೇ.

ಯಾರನ್ನೂ agent ಆಗಿರುವುದಕ್ಕಾಗಿ block ಮಾಡಲಾಗಲಿಲ್ಲ. ಪ್ರತಿಯೊಂದು ಹೆಚ್ಚಿನ-ಪ್ರಭಾವದ ಕ್ರಿಯೆಯೂ ಸ್ಪಷ್ಟ authority ಯೊಂದಿಗೆ ನಡೆದಿತು.

Proof of Actor ಇಲ್ಲಿ ಹೇಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ

Proof of Actor ಈ model ನ actor ಭಾಗವನ್ನು ಒದಗಿಸುತ್ತದೆ: ಯಾರು ಅಥವಾ ಏನು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಮತ್ತು ಯಾವ basis ಮೇಲೆ. ನಿಮ್ಮ application authentication, authorization ಮತ್ತು ಅಂತಿಮ ನಿರ್ಧಾರವನ್ನು ತಾನೇ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. actor ಅನ್ನು Detect ಮಾಡಿ, ಪ್ರತಿಯೊಂದು ವರ್ಗವು ನಿಮ್ಮ ಸಂವೇದನಾಶೀಲ route ಗಳನ್ನು ಹೇಗೆ ಬಳಸುತ್ತದೆ ಎಂದು Understand ಮಾಡಿ, ಮತ್ತು ಪ್ರತಿಯೊಂದು request ಅನ್ನು ಸರಿಯಾದ assurance ಮಟ್ಟಕ್ಕೆ Route ಮಾಡಿ.

ನಿಮ್ಮ application ಗಾಗಿ ಇದನ್ನು ನಮ್ಮ ತಂಡದೊಂದಿಗೆ ವಿನ್ಯಾಸಗೊಳಿಸಲು, early access ಗೆ ಅರ್ಜಿ ಸಲ್ಲಿಸಿ. SaaS ಸನ್ನಿವೇಶಗಳನ್ನು ಹೆಚ್ಚಿನ ವಿವರದಲ್ಲಿ ನೋಡಲು, SaaS Apps & Websites ನೋಡಿ.

ಮೂಲಗಳು

• RFC 6749: The OAuth 2.0 Authorization Framework: clients ಗಾಗಿ scope ಹೊಂದಿದ, delegated credentials
• RFC 9700: Best Current Practice for OAuth 2.0 Security: OAuth deployments ಗೆ ಪ್ರಸ್ತುತ security ಮಾರ್ಗದರ್ಶನ
• RFC 7009: OAuth 2.0 Token Revocation: ಬಳಕೆದಾರನ 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 ಮಾರ್ಗದರ್ಶನ
• W3C Web Authentication (WebAuthn) Level 3: passkey prompts ಹಿಂದೆ ಇರುವ ಮಾನಕ
• RFC 9421: HTTP Message Signatures: ಪರಿಶೀಲಿತ agent signature ಏನು ಸ್ಥಾಪಿಸುತ್ತದೆ ಎಂಬುದು