ਮਾਰਗਦਰਸ਼ਕ

ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ ਨੂੰ ਰੋਕਿਆਂ ਬਿਨਾਂ legitimate agents ਤੋਂ ਕਿਵੇਂ ਬਚਾਅ ਕਰੀਏ

account ਬਦਲਾਵਾਂ ਅਤੇ ਉੱਚ-ਅਸਰ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਦਾ ਇੱਕ ਵਿਆਵਹਾਰਿਕ ਮਾਡਲ, ਜਦੋਂ ਕਿ legitimate automated clients ਨੂੰ ਤੁਹਾਡੇ app ਵਿੱਚ ਲਾਭਦਾਇਕ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਮਿਲਦੀ ਰਹੇ.

ਦੁਆਰਾ Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

ਉੱਚ ਪੱਧਰ · 10 ਮਿੰਟ ਪੜ੍ਹਨ ਦਾ ਸਮਾਂ

ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ ਲਈ agents ਨੂੰ ਸਿਰਫ਼ block ਕਿਉਂ ਨਾ ਕਰੀਏ?

ਤੁਹਾਡੇ application ਵਿੱਚ ਕੁਝ ਕਾਰਵਾਈਆਂ ਹੋਰਾਂ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀਆਂ ਹਨ। Password ਬਦਲਣਾ, team member ਜੋੜਨਾ, data export ਕਰਨਾ, project delete ਕਰਨਾ, order approve ਕਰਨਾ: ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਹੀ authority ਤੋਂ ਬਿਨਾਂ ਹੋ ਜਾਵੇ, ਤਾਂ ਨੁਕਸਾਨ ਹਕੀਕਤੀ ਹੁੰਦਾ ਹੈ।

ਉਸੇ ਵੇਲੇ, ਤੁਹਾਡੇ app ਵਿੱਚ legitimate ਕੰਮ ਦਾ ਵੱਧ ਹਿੱਸਾ automation ਰਾਹੀਂ ਹੁੰਦਾ ਹੈ। ਇੱਕ user assistant ਨੂੰ ਆਪਣੇ settings update ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ। ਇੱਕ partner integration schedule ਅਨੁਸਾਰ records ਬਣਾਉਂਦਾ ਹੈ। ਇੱਕ internal agent support tickets file ਕਰਦਾ ਹੈ। ਹਰ automated client ਨੂੰ ਸੰਵੇਦਨਸ਼ੀਲ routes ਤੋਂ block ਕਰਨਾ ਉਸ ਕੰਮ ਨੂੰ ਤੋੜਦਾ ਹੈ ਅਤੇ ਲੋਕਾਂ ਨੂੰ ਮੁੜ manual effort ਜਾਂ ਐਸੇ workaround ਵੱਲ ਧੱਕਦਾ ਹੈ ਜੋ secure ਕਰਨਾ ਔਖਾ ਹੁੰਦਾ ਹੈ।

ਜਵਾਬ "agents ਨੂੰ block ਕਰੋ" ਜਾਂ "agents 'ਤੇ ਭਰੋਸਾ ਕਰੋ" ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਐਸਾ model ਹੈ ਜਿੱਥੇ action ਦਾ risk, request ਦੇ ਪਿੱਛੇ authority ਅਤੇ actor ਬਾਰੇ evidence ਹਰ ਇੱਕ ਆਪਣੀ ਵੱਖਰੀ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦੇ ਹਨ। ਇਹ guide ਉਹ model ਬਣਾਉਂਦੀ ਹੈ। ਇਸ ਦੇ ਪਿੱਛੇ ਵੱਡੀ ਸੋਚ ਲਈ, humans ਅਤੇ AI agents ਲਈ app-level policies design ਕਰਨਾ ਵੇਖੋ।

Step 1: ਆਪਣੇ routes ਨੂੰ risk ਅਨੁਸਾਰ tier ਕਰੋ

Clients ਨਹੀਂ, actions ਨੂੰ classify ਕਰਕੇ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਸਧਾਰਣ ਤਿੰਨ-tier scheme ਜ਼ਿਆਦਾਤਰ applications ਲਈ ਕੰਮ ਕਰਦੀ ਹੈ:

Tier	ਉਦਾਹਰਨਾਂ	ਮੂਲ ਲੋੜ
ਘੱਟ	Public data read ਕਰਨਾ, search, ਆਪਣਾ dashboard ਦੇਖਣਾ	ਆਮ authentication, ਜੇ ਹੋਵੇ
ਦਰਮਿਆਨਾ	ਆਪਣਾ content ਬਣਾਉਣਾ ਜਾਂ edit ਕਰਨਾ, ਇੱਕ viewer ਨੂੰ invite ਕਰਨਾ	Authenticated, resource ਲਈ authorized
ਉੱਚ	Credentials ਬਦਲਣਾ, ownership ਬਦਲਣਾ, bulk export, delete ਕਰਨਾ, approve ਕਰਨਾ	Authorized ਨਾਲ step-up ਜਾਂ review

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 ਵਿੱਚ ਬਾਕੀ ਸਭ ਕੁਝ ਉਨ੍ਹਾਂ 'ਤੇ ਟਿਕਦਾ ਹੈ।

Step 2: Identity, credentials ਅਤੇ authorization ਵਿੱਚ ਕੀ ਫਰਕ ਹੈ?

ਤਿੰਨ ਸਵਾਲ ਅਕਸਰ ਇਕੱਠੇ ਗੁੰਝਲਦੇ ਹਨ:

ਕੌਣ ਜਾਂ ਕੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ? ਇਹ actor evidence ਹੈ: ਇੱਕ interactive person, AI ਦੀ ਮਦਦ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ person, ਇੱਕ agent, ਜਾਂ Unknown, ਕਿਸੇ basis ਜਿਵੇਂ verified ਜਾਂ declared ਨਾਲ।
ਕਿਹੜਾ credential ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਸੀ? ਇੱਕ session cookie, ਇੱਕ API key, ਇੱਕ OAuth access token।
ਕੀ ਇਹ credential ਇਸ resource 'ਤੇ ਇਹ action ਕਰਨ ਲਈ allowed ਹੈ? ਇਹ authorization ਹੈ।

ਇੱਕ verified agent signature (RFC 9421) ਪਹਿਲੇ ਸਵਾਲ ਦਾ ਵਧੀਆ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਇਹ ਤੀਜੇ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ, ਇੱਕ ਨੁਕਤਾ ਜਿਸਦੀ ਵਿਸਥਾਰ ਨਾਲ ਚਰਚਾ signed AI agent requests ਕੀ ਸਾਬਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਕੀ ਨਹੀਂ ਵਿੱਚ ਕੀਤੀ ਗਈ ਹੈ। ਸਹੀ scope ਵਾਲਾ ਇੱਕ OAuth token ਤੀਜੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਇਹ ਪਹਿਲੇ ਬਾਰੇ ਥੋੜ੍ਹਾ ਹੀ ਦੱਸਦਾ ਹੈ। ਇੱਕ ਉੱਚ-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);
}

ਕਿਸੇ favorable actor ਨਤੀਜੇ ਦੇ ਕਾਰਨ authorization ਕਦੇ ਵੀ ਢਿੱਲੀ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ। Actor context ਸਿਰਫ਼ ਲੋੜਾਂ ਵਧਾਉਂਦਾ ਹੈ ਜਾਂ ਬਰਾਬਰ ਸੁਰੱਖਿਅਤ ਰਾਹਾਂ ਵਿੱਚੋਂ ਚੋਣ ਕਰਦਾ ਹੈ।

Step 3: ਲੋਕਾਂ ਦੀ ਥਾਂ agents ਕੰਮ ਕਰਨ ਲਈ delegated authority ਵਰਤੋ

ਜਦੋਂ ਇੱਕ agent ਕਿਸੇ user ਦੀ ਥਾਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ user ਦੇ session ਨੂੰ ਮੁੜ ਵਰਤਣ ਦੇ ਬਜਾਏ ਆਪਣਾ ਹੀ credential ਦਿਓ ਜਿਸਦੀ authority ਸੀਮਿਤ ਹੋਵੇ। OAuth 2.0 ਮਿਆਰੀ tool ਹੈ: user ਕਿਸੇ ਖਾਸ client ਲਈ ਖਾਸ scopes ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਅਤੇ token ਉਸ client ਨੂੰ ਦਰਜ ਕਰਦਾ ਹੈ। RFC 9700, OAuth 2.0 Security Best Current Practice, ਦੱਸਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਤਾਇਨਾਤ ਕਰਨਾ ਹੈ। MCP servers ਵੀ ਇਹੀ pattern ਅਪਣਾਉਂਦੇ ਹਨ: MCP authorization specification ਇੱਕ protected MCP server ਨੂੰ OAuth 2.1 resource server ਵਜੋਂ ਲੈਂਦੀ ਹੈ। ਸਾਡਾ post ਤੁਹਾਡੇ MCP server ਨੂੰ ਕੌਣ ਕਾਲ ਕਰ ਰਿਹਾ ਹੈ? ਇਸਨੂੰ tool calls 'ਤੇ ਲਾਗੂ ਕਰਦਾ ਹੈ।

ਇਹ ਉਹੀ ਚੀਜ਼ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ ਲਈ ਚਾਹੀਦੀ ਹੈ:

Token ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜਾ client ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਕਿਸ ਦੀ ਥਾਂ 'ਤੇ।
Scopes ਇਹ ਸੀਮਤ ਕਰਦੇ ਹਨ ਕਿ ਇਹ ਕੀ ਕਰ ਸਕਦਾ ਹੈ। calendar:write ਵਾਲਾ scheduling agent password ਨਹੀਂ ਬਦਲ ਸਕਦਾ।
User ਆਪਣੀ credential ਬਦਲੇ ਬਿਨਾਂ grant revoke ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ OAuth 2.0 Token Revocation (RFC 7009) ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ client authorization server ਨੂੰ ਕਿਵੇਂ ਦੱਸਦਾ ਹੈ ਕਿ token ਹੁਣ valid ਨਹੀਂ ਰਹਿਣਾ ਚਾਹੀਦਾ।
Audit logs ਦਿਖਾਉਂਦੀਆਂ ਹਨ ਕਿ action agent ਨੇ ਕੀਤਾ, user ਨੇ ਨਹੀਂ।

ਜੇ ਤੁਹਾਡਾ app ਹਜੇ delegated credentials support ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਉਹਨਾਂ ਕਾਰਵਾਈਆਂ ਲਈ ਇਸਨੂੰ ਪਹਿਲ ਦੇਵੋ ਜਿਨ੍ਹਾਂ ਦੀ agents ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਲੋੜ ਹੁੰਦੀ ਹੈ। Automated access ਲਈ ਇਹ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ control ਹੈ।

Step 4: ਤੁਹਾਨੂੰ step-up check ਕਦੋਂ ਮੰਗਣੀ ਚਾਹੀਦੀ ਹੈ?

Step-up ਦਾ ਮਤਲਬ ਹੈ ਸੰਵੇਦਨਸ਼ੀਲ action ਦੇ ਸਮੇਂ ਵਾਧੂ assurance ਮੰਗਣਾ। OAuth-protected APIs ਲਈ, RFC 9470 ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ resource server client ਨੂੰ ਕਿਵੇਂ ਦੱਸਦਾ ਹੈ ਕਿ current token ਦੀ authentication ਕਾਫ਼ੀ ਮਜ਼ਬੂਤ ਜਾਂ ਹਾਲੀਆ ਨਹੀਂ ਹੈ। ਸਹੀ 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 ਲਈ dedicated scope, ਜੋ user ਨੇ explicit ਤੌਰ 'ਤੇ ਦਿੱਤਾ ਹੋਵੇ, ਜਾਂ user ਨੂੰ 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 ਨੂੰ skip ਨਹੀਂ ਕਰਦਾ। ਇਹ ਉਸ step-up ਨੂੰ ਚੁਣਦਾ ਹੈ ਜੋ ਇੱਕ interactive person ਲਈ ਠੀਕ ਹੈ। Inferences ਗਲਤ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਉਹਨਾਂ ਨੂੰ check ਦਾ ਰੂਪ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਉਸਨੂੰ ਹਟਾਉਣਾ।

Step 5: ਜਿੱਥੇ judgment ਦੀ ਲੋੜ ਹੈ, ਉੱਥੇ human review ਵੱਲ route ਕਰੋ

ਕੁਝ ਕਾਰਵਾਈਆਂ ਦੁਰਲੱਭ, ਉੱਚ-ਅਸਰ ਵਾਲੀਆਂ ਅਤੇ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ automate ਕਰਨੀ ਔਖੀਆਂ ਹੁੰਦੀਆਂ ਹਨ: 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"));
}

Step 6: ਹਰ tier ਲਈ failure behavior ਚੁਣੋ

Actor evaluation timeout ਹੋ ਸਕਦੀ ਹੈ ਜਾਂ evidence ਦੀ ਘਾਟ ਹੋ ਸਕਦੀ ਹੈ। ਪਹਿਲਾਂ ਤੋਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ।

ਘੱਟ tier: fail open. Request ਆਮ ਤੌਰ 'ਤੇ ਅੱਗੇ ਵੱਧਦੀ ਹੈ।
ਦਰਮਿਆਨਾ tier: fail open, ਨਾਲ ਹੀ normal authorization ਲਾਗੂ ਰਹਿੰਦੀ ਹੈ।
ਉੱਚ tier: ਮੌਜੂਦਾ strong check 'ਤੇ fail closed. Missing actor evidence ਕਦੇ ਵੀ protection ਨੂੰ ਕਮਜ਼ੋਰ ਨਹੀਂ ਕਰਦੀ, ਅਤੇ ਇਹ ਕਦੇ ਵੀ ਉਸ request ਨੂੰ ਨਹੀਂ ਰੋਕਦੀ ਜੋ ਹੋਰਥਾਂ ਤੁਹਾਡੀਆਂ ਆਮ checks ਵਿੱਚੋਂ ਪਾਰ ਹੋ ਜਾਂਦੀ।

ਮੁੱਖ ਗੁਣ symmetry ਹੈ। Actor evaluation ਵਿੱਚ failure ਕਾਰਵਾਈ ਨੂੰ ਠੀਕ ਉਸੇ ਤਰ੍ਹਾਂ ਸੁਰੱਖਿਅਤ, ਅਤੇ ਠੀਕ ਉਸੇ ਤਰ੍ਹਾਂ available, ਛੱਡ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਵੇਂ actor context ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਸੀ।

Step 7: inferences ਦੇ ਆਧਾਰ 'ਤੇ ਲੋਕਾਂ ਬਾਰੇ ਮਹੱਤਵਪੂਰਨ ਫੈਸਲੇ ਨਾ ਕਰੋ

ਇੱਕ inferred classification ਇੱਕ interaction ਬਾਰੇ evidence ਹੈ, ਕਿਸੇ person ਬਾਰੇ ਤੱਥ ਨਹੀਂ। ਕਿਸੇ ਨੂੰ job application, credit decision, exam result, housing ਜਾਂ essential service ਤੱਕ access ਇਸ ਲਈ ਨਾ ਰੱਦ ਕਰੋ ਕਿ ਕੋਈ session automated ਜਾਂ AI-assisted ਲੱਗਿਆ ਸੀ। ਐਸੇ flows ਵਿੱਚ, actor context ਨੂੰ process ਚੁਣਨ ਲਈ ਵਰਤੋ, ਜਿਵੇਂ human review ਜਾਂ ਕੋਈ ਵਿਕਲਪਿਕ verification path, ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ person ਇਹ ਪੂਰਾ ਕਰ ਸਕੇ।

ਇਹ fairness principle ਵੀ ਹੈ ਅਤੇ practical ਵੀ। Inferences ਵਿੱਚ false positives ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਹਨਾਂ flows ਵਿੱਚ false positive ਦੀ ਕੀਮਤ ਉਸ ਵਿਅਕਤੀ 'ਤੇ ਪੈਂਦੀ ਹੈ ਜਿਸ ਨੇ ਕੁਝ ਗਲਤ ਨਹੀਂ ਕੀਤਾ ਸੀ।

Step 8: ਪਹਿਲਾਂ observation ਨਾਲ rollout ਕਰੋ

ਇਹ ਸਭ ਕੁਝ ਅਸਲੀ requests ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ observation ਅਤੇ preview mode ਵਿੱਚ ਚਲਾਓ:

Tier, actor class, basis, credential type ਅਤੇ ਉਹ step-up record ਕਰੋ ਜੋ ਤੁਹਾਡੀ policy ਲੋੜੀਂਦੀ ਹੋਵੇਗੀ।
Class ਅਨੁਸਾਰ high-tier requests ਦੇ samples ਦੀ ਸਮੀਖਿਆ ਕਰੋ। ਕੀ legitimate agents delegated credentials ਵਰਤ ਰਹੇ ਹਨ, ਜਾਂ user sessions ਨੂੰ ਮੁੜ ਵਰਤ ਰਹੇ ਹਨ?
ਤੁਹਾਨੂੰ ਜੋ gaps ਮਿਲਦੇ ਹਨ ਉਹ ਠੀਕ ਕਰੋ, ਅਕਸਰ scoped credentials ਦੇ ਕੇ, enforcement ਤੋਂ ਪਹਿਲਾਂ।
ਇੱਕ ਹੀ route ਦੇ ਛੋਟੇ ਹਿੱਸੇ 'ਤੇ enforce ਕਰੋ, completion rates ਮਾਪੋ, ਫਿਰ ਵਧਾਓ।

Step 9: ਇੱਕ audit trail ਰੱਖੋ ਜੋ "ਕੌਣ ਅਤੇ ਕਿਸ ਦੀ ਥਾਂ" ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੋਵੇ

ਹਰ high-tier action ਲਈ, ਇੰਨਾ record ਕਰੋ ਕਿ ਬਾਅਦ ਵਿੱਚ ਜੋ ਹੋਇਆ ਸੀ ਉਸਨੂੰ ਦੁਬਾਰਾ ਬਣਾਇਆ ਜਾ ਸਕੇ:

request ਦੇ ਸਮੇਂ actor class ਅਤੇ basis,
credential type, ਜਿਸ client ਨੂੰ ਇਹ ਜਾਰੀ ਹੋਇਆ ਸੀ ਅਤੇ ਜਿਸ subject ਨੂੰ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ (OAuth 2.0 Token Exchange, RFC 8693, delegation ਲਈ ਇਸ ਕਿਸਮ ਦੇ "acting for" relationship ਨੂੰ ਦਰਜ ਕਰਨ ਲਈ ਇੱਕ act claim ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ),
action ਨੂੰ authorize ਕਰਨ ਵਾਲੇ 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 ਨੇ delete ਕੀਤਾ ਜਾਂ assistant ਨੇ, ਅਤੇ ਕਿਸ ਨੇ ਇਸਨੂੰ approve ਕੀਤਾ" ਵਰਗੇ ਸਵਾਲ ਦਾ ਸਪਸ਼ਟ ਜਵਾਬ ਮਿਲਦਾ ਹੈ। ਇਸ ਨਾਲ incident response ਤੇਜ਼ ਹੁੰਦਾ ਹੈ ਅਤੇ users ਨੂੰ ਇਹ ਭਰੋਸਾ ਮਿਲਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ app ਵਿੱਚ automated ਮਦਦ accountable ਹੈ।

ਇੱਕ worked example

ਇੱਕ project management app ਦੇਖਦਾ ਹੈ ਕਿ ਇੱਕ assistant users ਲਈ task due dates update ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਕਦੇ-ਕਦੇ ਪੂਰੇ projects export ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ।

Task update ਕਰਨਾ medium tier ਹੈ। Assistant tasks:write ਵਾਲੇ OAuth token ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। Authorized, no 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 ਨਹੀਂ ਕੀਤਾ ਗਿਆ। ਹਰ ਉੱਚ-ਅਸਰ ਵਾਲੀ action ਨਾਲ explicit authority ਸੀ।

Proof of Actor ਕਿੱਥੇ ਫਿੱਟ ਹੁੰਦਾ ਹੈ

Proof of Actor ਇਸ model ਦਾ actor ਪੱਖ ਦਿੰਦਾ ਹੈ: ਕੌਣ ਜਾਂ ਕੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਕਿਸ basis 'ਤੇ। ਤੁਹਾਡਾ application authentication, authorization ਅਤੇ ਅੰਤਿਮ ਫੈਸਲਾ ਆਪਣੇ ਕੋਲ ਰੱਖਦਾ ਹੈ। Actor ਨੂੰ Detect ਕਰੋ, Understand ਕਰੋ ਕਿ ਹਰ class ਤੁਹਾਡੇ ਸੰਵੇਦਨਸ਼ੀਲ routes ਨੂੰ ਕਿਵੇਂ ਵਰਤਦੀ ਹੈ, ਅਤੇ ਹਰ 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: MCP servers ਨੂੰ OAuth 2.1 resource servers ਵਜੋਂ
NIST SP 800-63B: Authentication and Authenticator Management: reauthentication guidance
W3C Web Authentication (WebAuthn) Level 3: passkey prompts ਦੇ ਪਿੱਛੇ ਮਿਆਰ
RFC 9421: HTTP Message Signatures: ਇੱਕ verified agent signature ਕੀ ਸਥਾਪਤ ਕਰਦੀ ਹੈ

ਇਸ ਨੂੰ ਸਾਡੇ ਨਾਲ ਬਣਾਓ।

Proof of Actor founding developer program ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੋ।

ਅਗਾਊਂ ਪਹੁੰਚ ਲਵੋ ਡਿਵੈਲਪਰ ਕੇਂਦਰ

ਪਹਿਲਾਂ ਗੱਲ ਕਰਨੀ ਪਸੰਦ ਕਰੋਗੇ? founders ਨਾਲ ਗੱਲ ਕਰੋ