Actor-aware ನೀತಿಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಹೇಗೆ ಹಂಚಿಕೆ ಮಾಡುವುದು

ನೀವು actor-aware ನೀತಿಗಳನ್ನು ಹಂಚಿಕೆ ಮಾಡುವಾಗ ಏನು ತಪ್ಪಾಗಬಹುದು?

Actor-aware policy ಯು ನಿಮ್ಮ application ಹೇಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನು, ಯಾರಿಂದ ಅಥವಾ ಏನಿಂದ action ನಡೆಯುತ್ತಿದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಬದಲಿಸುತ್ತದೆ. ಸರಿಯಾಗಿ ಮಾಡಿದರೆ, ಇದು ಜನರಿಗೆ ಸುಗಮ ಅನುಭವವನ್ನು ನೀಡುತ್ತದೆ, ಮಾನ್ಯ agent ಗಳಿಗೆ ಸಂರಚಿತ ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತದೆ, ಮತ್ತು ಅಗತ್ಯವಿರುವ ಜಾಗದಲ್ಲಿ ಮಾತ್ರ friction ಅನ್ನು ಸೇರಿಸುತ್ತದೆ. ತಪ್ಪಾಗಿ ಮಾಡಿದರೆ, ಇದು ನಿಜವಾದ ಬಳಕೆದಾರರನ್ನು ಹೊರಗಿಡುತ್ತದೆ, ನಿಮ್ಮ customers ಅವಲಂಬಿಸಿರುವ integrations ಅನ್ನು ಮುರಿಯುತ್ತದೆ, ಮತ್ತು ಯಾರೂ ವಿವರಿಸಲಾರದ support ticket ಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ವ್ಯತ್ಯಾಸವು ಅಪರೂಪವಾಗಿ policy logic ನಲ್ಲಿ ಇರುತ್ತದೆ. ಅದು rollout ನಲ್ಲಿ ಇರುತ್ತದೆ. (policy model ಸ್ವತಃ ಕುರಿತು, humans and AI agents ಗಾಗಿ app-level policies ವಿನ್ಯಾಸಗೊಳಿಸುವುದು ನೋಡಿ.) ಈ guide ಯಾವುದೇ route ಗಾಗಿ ತಂಡಗಳು ಅನುಸರಿಸಬಹುದಾದ ಹಂತಬದ್ಧ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ: observe, preview, ಒಂದು slice ಗೆ enforce, ನಂತರ ವಿಸ್ತರಿಸಿ. ಪ್ರತಿ stage ಗೆ ಸ್ಪಷ್ಟವಾದ exit criterion ಮತ್ತು ವೇಗವಾದ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಇರುತ್ತದೆ.

ಮೂರು modes

ಪ್ರತಿ policy ಯನ್ನು route ಪ್ರತಿ ಮೂರು modes ಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ನಡೆಯುತ್ತಿರುವಂತೆ ಕಲ್ಪಿಸಿ:

• Observe. Classifications ದಾಖಲಿಸಲಾಗುತ್ತವೆ. application ಅವು ಇಲ್ಲದಿದ್ದಂತೆ ನಿಖರವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ.
• Preview. Policy ಮೌಲ್ಯಮಾಪನವಾಗುತ್ತದೆ ಮತ್ತು ಅದರ decision ದಾಖಲಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಅನ್ವಯಿಸಲಾಗುವುದಿಲ್ಲ. ಏನಾಗುತ್ತಿತ್ತು ಎಂಬುದನ್ನು ನೀವು ನೋಡಬಹುದು.
• Enforce. Decision ನಿಜವಾದ requests ಗಳಿಗೆ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ.

Mode ಯು route ಮತ್ತು policy ಜೋಡಿಗೆ ಸೇರಿದೆ, ಸಂಪೂರ್ಣ application ಗೆ ಅಲ್ಲ. ನಿಮ್ಮ documentation pages enforce ಆಗಿರಬಹುದು, ಅಷ್ಟರಲ್ಲಿ ನಿಮ್ಮ checkout ಇನ್ನೂ observe ಆಗುತ್ತಿರಬಹುದು.

ಹಂತ 1: ನಿಮ್ಮ baseline ಗೊತ್ತಾಗುವವರೆಗೆ observe ಮಾಡಿ

ಪ್ರತಿ route ಅನ್ನು observe mode ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿ. ಕನಿಷ್ಠ ಈ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಿ:

• route ಮತ್ತು method,
• actor class (Human, Human + AI, Agent ಅಥವಾ Unknown) ಮತ್ತು ಅದರ basis (verified, declared, inferred ಅಥವಾ unknown), application traffic ಗಾಗಿ ನಮ್ಮ taxonomy ಯಲ್ಲಿ ವಿವರಿಸಿದಂತೆ,
• response status ಮತ್ತು route ಗಾಗಿ ಸರಳ outcome ಗುರುತು, ಉದಾಹರಣೆಗೆ "account created" ಅಥವಾ "search returned results".

ಸಾಮಾನ್ಯ ಸಾಪ್ತಾಹಿಕ ಚಕ್ರಗಳನ್ನು ಮತ್ತು ಆ ಅವಧಿಯಲ್ಲಿ ನೀವು ship ಮಾಡುವ ಯಾವುದೇ release ಅನ್ನು ಒಳಗೊಳ್ಳುವಷ್ಟು ಕಾಲ run ಮಾಡಿ. ನಂತರ ನೀವು ಕಾಳಜಿ ವಹಿಸುವ ಪ್ರತಿಯೊಂದು route ಗಾಗಿ ನಿಮ್ಮ baseline ಅನ್ನು ದಾಖಲಿಸಿ: class mix, Unknown ದರ, ಮತ್ತು ಪ್ರತಿ class ಗಾಗಿ outcome rate. ಮುಂದೆ ಬರುವ ಎಲ್ಲವನ್ನೂ ನೀವು ಈ ಸಂಖ್ಯೆಗಳ ವಿರುದ್ಧ ಹೋಲಿಸುತ್ತೀರಿ.

Exit criterion: ಪ್ರತಿ candidate route ಗಾಗಿ, ಅದನ್ನು ಯಾರು ಬಳಸುತ್ತಾರೆ ಮತ್ತು class ಪ್ರಕಾರ outcomes ಹೇಗೆ ಬದಲಾಗುತ್ತವೆ ಎಂಬುದನ್ನು ನೀವು ವಿವರಿಸಬಹುದು.

ಹಂತ 2: policy ಯನ್ನು data ಆಗಿ ಬರೆಯಿರಿ

Policy ಗಳು if statements ಗಳು ಚದುರಿಕೊಂಡಿರುವುದಕ್ಕಿಂತ data ಆಗಿರುವಾಗ review, test ಮತ್ತು rollback ಮಾಡಲು ಸುಲಭವಾಗುತ್ತವೆ.

type ActorClass = "human" | "human_ai" | "agent" | "unknown";
type Basis = "verified" | "declared" | "inferred" | "unknown";
type Action = "allow" | "adapt" | "challenge" | "review" | "limit";
type Mode = "observe" | "preview" | "enforce";

interface Rule {
  actor: ActorClass | "*";
  basis?: Basis[];
  action: Action;
}

interface RoutePolicy {
  route: string;
  mode: Mode;
  enforcePercent: number;
  rules: Rule[];
  fallback: Action;
}

export const policies: RoutePolicy[] = [
  {
    route: "GET /api/catalog",
    mode: "preview",
    enforcePercent: 0,
    rules: [
      { actor: "agent", basis: ["verified"], action: "allow" },
      { actor: "agent", basis: ["declared", "inferred"], action: "limit" },
    ],
    fallback: "allow",
  },
];

ಪ್ರತಿ policy ಗೆ ಸ್ಪಷ್ಟವಾದ fallback ಇರುತ್ತದೆ. ಅದು Unknown results, timeouts ಮತ್ತು ಯಾವುದೇ rule ಒಳಗೊಂಡಿರದ ಪ್ರಕರಣಗಳಿಗೆ ಬಳಸುವ action. ಅದನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆಯ್ಕೆ ಮಾಡುವುದು ಸಂಪೂರ್ಣ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅತ್ಯಂತ ಮುಖ್ಯವಾದ safety decision.

ಹಂತ 3: ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ evaluate ಮಾಡಿ

ಒಂದೇ evaluation function mode ಗಳಾದ್ಯಂತ behavior ಸ್ಥಿರವಾಗಿರುವಂತೆ ಮಾಡುತ್ತದೆ.

export function decide(policy: RoutePolicy, actor: ActorClass, basis: Basis): Action {
  for (const rule of policy.rules) {
    const actorMatch = rule.actor === "*" || rule.actor === actor;
    const basisMatch = !rule.basis || rule.basis.includes(basis);
    if (actorMatch && basisMatch) return rule.action;
  }
  return policy.fallback;
}

ನಂತರ mode ಅನ್ನು ಅನ್ವಯಿಸಿ:

export function applyPolicy(policy: RoutePolicy, actor: ActorClass, basis: Basis, requestKey: string) {
  const decision = decide(policy, actor, basis);
  const inSlice = bucket(requestKey) < policy.enforcePercent;
  const enforced = policy.mode === "enforce" && inSlice;
  record({ route: policy.route, mode: policy.mode, actor, basis, decision, enforced });
  return enforced ? decision : "allow";
}

function bucket(key: string): number {
  let h = 0;
  for (const c of key) h = (h * 31 + c.charCodeAt(0)) >>> 0;
  return h % 100;
}

Stable bucket ಎಂದರೆ ಒಂದೇ session ಅಥವಾ client enforced slice ಒಳಗೆ ಅಥವಾ ಹೊರಗೆ ಉಳಿಯುತ್ತದೆ, ಹೀಗಾಗಿ people ಗಳು requests ಗಳ ನಡುವೆ behavior ಹಠಾತ್ತಾಗಿ ಬದಲಾಗುವುದನ್ನು ನೋಡುವುದಿಲ್ಲ.

ಹಂತ 4: enforce ಮಾಡುವ ಮೊದಲು false positive ಗಳನ್ನು ಹೇಗೆ ಅಳೆಯಬೇಕು?

ಒಂದು route ಅನ್ನು preview ಗೆ ತೆಗೆದುಕೊಂಡು ಹೋಗಿ. ಈಗ ಪ್ರತಿಯೊಂದು request ಅದಕ್ಕೆ ಸಿಗಬೇಕಾಗಿದ್ದ decision ಅನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಇಲ್ಲಿ policy ಸರಿಯಿದೆಯೇ ಎಂಬುದನ್ನು ನೀವು ಕಲಿಯುತ್ತೀರಿ.

False positive ಎಂದರೆ policy ನಿರ್ಬಂಧಿಸುತ್ತಿದ್ದ request, ಆದರೆ ಅದನ್ನು allow ಮಾಡಬೇಕಾಗಿತ್ತು. ಇದನ್ನು classifications ಮಾತ್ರದಿಂದ ಅಳೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ನೀವು ಪರೀಕ್ಷಿಸುತ್ತಿರುವುದು classification ಸ್ವತಃ. ಅದನ್ನು ಮಾನ್ಯ ಬಳಕೆಯ independent signals ಗಳ ವಿರುದ್ಧ ಅಳೆಯಿರಿ:

• request ಸಾಮಾನ್ಯ ಯಶಸ್ವಿ flow ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದೆ, ಉದಾಹರಣೆಗೆ signed-in ಬಳಕೆದಾರನು ತನ್ನ ಕೆಲಸವನ್ನು ಉಳಿಸಿದ್ದಾನೆ,
• client ಒಂದು known partner integration ಅಥವಾ ನೀವು ಸೇವಿಸಲು ಒಪ್ಪಿಕೊಂಡ verified operator ಆಗಿದೆ,
• support ticket ಗಳು ಅಥವಾ user reports ಗಳು ಪರಿಣಾಮಿತ route ಅನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತವೆ,
• would-be restricted requests ಗಳ ಮಾದರಿಯ ಕೈಯಾರೆ review.

ಒಂದು sample ಅನ್ನು ಕೈಯಾರೆ ಪರಿಶೀಲಿಸಿ. policy ನಿರ್ಬಂಧಿಸಬೇಕಾಗಿದ್ದ ಇಪ್ಪತ್ತು ನಿಜವಾದ requests ಗಳನ್ನು ಓದುವುದು ಅತಿಯಾಗಿ ವ್ಯಾಪಕವಾದ rule ಅನ್ನು ಕಂಡುಹಿಡಿಯುವ ಅತ್ಯಂತ ವೇಗವಾದ ಮಾರ್ಗ.

Exit criterion: would-be restricted set ನೀವು ನಿಜವಾಗಿ ನಿರ್ಬಂಧಿಸಲು ಉದ್ದೇಶಿಸಿರುವ traffic ನಿಂದ ಬಹುಮಟ್ಟಿಗೆ ನಿರ್ಮಿತವಾಗಿದೆ, ಮತ್ತು ನೀವು ಕಂಡುಕೊಂಡ ಪ್ರತಿಯೊಂದು false positive ವರ್ಗಕ್ಕೂ ವಿವರಣೆ ಇದೆ.

ಹಂತ 5: ಒಂದು slice ಗಾಗಿ enforce ಮಾಡಿ

Route ಅನ್ನು ಸಣ್ಣ enforcePercent ಜೊತೆಗೆ enforce ಗೆ ಬದಲಿಸಿ. Mistake ಕೆಲವೇ requests ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವಷ್ಟು ಚಿಕ್ಕದಾಗಿಯೂ, ಒಂದು ಅಥವಾ ಎರಡು ದಿನಗಳ ಒಳಗೆ measurable signal ನೀಡುವಷ್ಟು ದೊಡ್ಡದಾಗಿಯೂ slice ಇರಲಿ.

ನಿಮ್ಮ baseline ಆಗಿ ನೀವು ಹೊಂದಿಸಿದ ಅದೇ metrics ಗಳನ್ನು ಗಮನಿಸಿ:

• route ನಲ್ಲಿ ಪ್ರತಿ class ಗಾಗಿ outcome rate,
• error ಮತ್ತು challenge ಪೂರ್ಣಗೊಳಿಸುವ ದರಗಳು,
• route ಅನ್ನು ಉಲ್ಲೇಖಿಸುವ support ಪ್ರಮಾಣ,
• latency, ಏಕೆಂದರೆ evaluation request path ಮೇಲೆ ಇರುತ್ತದೆ.

Enforced slice ನಲ್ಲಿ Human traffic ಗಾಗಿ outcomes ಉಳಿದ ಭಾಗದೊಂದಿಗೆ ಹೋಲಿಸಿದಾಗ ಕುಸಿದರೆ, ವಿಸ್ತರಿಸುವ ಮೊದಲು ನಿಲ್ಲಿಸಿ ಮತ್ತು ಪರಿಶೀಲಿಸಿ.

ಹಂತ 6: ಕ್ರಮೇಣ ವಿಸ್ತರಿಸಿ

Slice ಅನ್ನು ಹಂತಗಳಲ್ಲಿ ಹೆಚ್ಚಿಸಿ, ಉದಾಹರಣೆಗೆ ಸಣ್ಣ share ನಿಂದ quarter ಗೆ, ನಂತರ half ಗೆ, ನಂತರ ಎಲ್ಲಾ traffic ಗೆ, ಪ್ರತಿಯೊಂದು ಹಂತದಲ್ಲೂ ಸಾಮಾನ್ಯ cycle ಕಾಣುವಷ್ಟು ಕಾಲ ನಿಲ್ಲಿಸಿ. ಹಿಂದಿನ stages ಚೆನ್ನಾಗಿ ನಡೆದಿದ್ದರೆ expansion ನಿರ್ಸಾದಕರವಾಗಿರುತ್ತದೆ. ಅದೇ ಗುರಿ.

fallback ಗಳನ್ನು ಮತ್ತು failure behavior ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು

Evidence ಕಾಣೆಯಾಗಿರುವಾಗ ಅಥವಾ evaluation run ಆಗಲಾಗದಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಮುಂಚಿತವಾಗಿ ನಿರ್ಧರಿಸಿ.

• Fail open ಎಂದರೆ request actor context ಇಲ್ಲದಿದ್ದರೆ ಹೇಗಿರುತ್ತಿತ್ತೋ ಹಾಗೆಯೇ ಮುಂದುವರಿಯುತ್ತದೆ. ಸಾರ್ವಜನಿಕ pages, documentation ಮತ್ತು read-only catalog endpoints ಗಳಂತಹ ಕಡಿಮೆ-ಅಪಾಯದ routes ಗಳಿಗೆ ಇದನ್ನು ಬಳಸಿ.
• Fail closed ಎಂದರೆ re-authentication ಅಥವಾ review queue ನಂತಹ ನಿಮ್ಮ ಈಗಿನ ಬಲವಾದ check ಅನ್ವಯಿಸುತ್ತದೆ. ಈಗಾಗಲೇ ಇಂತಹ check ಇರುವ ಹೆಚ್ಚಿನ ಪರಿಣಾಮದ actions ಗಳಿಗೆ ಇದನ್ನು ಬಳಸಿ.

Timeout ಅಥವಾ error ಎಂದಿಗೂ Human result ಅನ್ನು ಉತ್ಪಾದಿಸಲು ಬಿಡಬೇಡಿ. ಕಾಣೆಯಾದ evidence Unknown ಆಗಿರುತ್ತದೆ, ಮತ್ತು Unknown route ನ fallback ಅನ್ನು ಪಡೆಯುತ್ತದೆ. AI traffic ಅನ್ನು ವರ್ಗೀಕರಿಸುವಾಗ Unknown ಏಕೆ ಮಾನ್ಯ result ಎಂಬುದರ ಕುರಿತು ನಮ್ಮ why Unknown is a valid result when classifying AI traffic ಲೇಖನ ಈ ನಿಯಮ ಏಕೆ ಮುಖ್ಯವೋ ವಿವರಿಸುತ್ತದೆ.

async function actorWithTimeout(evaluate: () => Promise<{ actor: ActorClass; basis: Basis }>) {
  const timeout = new Promise<{ actor: ActorClass; basis: Basis }>((resolve) =>
    setTimeout(() => resolve({ actor: "unknown", basis: "unknown" }), 150),
  );
  return Promise.race([evaluate(), timeout]);
}

policy ಯನ್ನು ವೇಗವಾಗಿ rollback ಮಾಡುವುದು ಹೇಗೆ?

Rollback ಒಂದು configuration change ಆಗಿರಬೇಕು, deploy ಅಲ್ಲ. ನಿಮ್ಮ ತಂಡ ವೇಗವಾಗಿ edit ಮಾಡಬಹುದಾದ store ನಲ್ಲಿ policies ಅನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ, ಮತ್ತು ಈ actions ಗಳನ್ನು ತಕ್ಷಣಗೊಳಿಸಿ:

1. Route ಅನ್ನು ಮತ್ತೆ preview ಗೆ ಸೆಟ್ ಮಾಡಿ, ಇದು measurement ಉಳಿಸಿಕೊಂಡೇ enforcement ನಿಲ್ಲಿಸುತ್ತದೆ.
2. enforcePercent ಅನ್ನು ಶೂನ್ಯಕ್ಕೆ ಸೆಟ್ ಮಾಡಿ.
3. ಇತರ rules ಗಳನ್ನು ಮುಟ್ಟದೆ ಒಂದೇ rule ಅನ್ನು disable ಮಾಡಿ.

ಪ್ರತಿ policy change ಅನ್ನು ಅದನ್ನು ಯಾರು ಮಾಡಿದರು ಮತ್ತು ಯಾವಾಗ ಎಂಬುದರೊಂದಿಗೆ ದಾಖಲಿಸಿ. Outcomes ಬದಲಾಗಿದಾಗ, ಮೊದಲ ಪ್ರಶ್ನೆ ಯಾವಾಗಲೂ ಏನು ಬದಲಾಯಿತು ಎಂಬುದೇ.

ಜನರ ಕುರಿತು ಪರಿಣಾಮಕಾರಿ ನಿರ್ಧಾರಗಳನ್ನು ತಪ್ಪಿಸಿ

Actor classifications interaction ಕುರಿತು evidence ಅನ್ನು ವಿವರಿಸುತ್ತವೆ. ಅವು ವ್ಯಕ್ತಿಯ ಕುರಿತು ತೀರ್ಪಲ್ಲ. ಯಾರೊಬ್ಬರ employment, credit, education, housing ಅಥವಾ ಅಗತ್ಯ ಸೇವೆಗಳ ಪ್ರವೇಶದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ನಿರ್ಧಾರಗಳ ಏಕೈಕ ಆಧಾರವಾಗಿ inferred class ಅನ್ನು ಬಳಸಬೇಡಿ. ಅಂತಹ flows ಗಳಿಗೆ, outcome ಅನ್ನು ನಿರ್ಧರಿಸಲು ಅಲ್ಲ, ಉದಾಹರಣೆಗೆ human review ಗೆ routing ಮಾಡುವುದು, ಎಂಬ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡಲು actor context ಅನ್ನು ಬಳಸಿ.

enforce ಮಾಡುವ ಮೊದಲು ಸಂವಹನ ಮಾಡಿ

Automated clients ಗಳನ್ನು ಪ್ರಭಾವಿಸುವ ನೀತಿಗಳು ಅವುಗಳನ್ನು ನಡೆಸುವ ಜನರು ಮತ್ತು companies ಗಳನ್ನೂ ಪ್ರಭಾವಿಸುತ್ತವೆ. ಸ್ವಲ್ಪ ಸಂವಹನ ಬಹಳಷ್ಟು support ಕೆಲಸವನ್ನು ತಪ್ಪಿಸುತ್ತದೆ:

1. Automated access ಗಾಗಿ ನಿಮ್ಮ rules ಗಳನ್ನು ಪ್ರಕಟಿಸಿ. ಯಾವ routes ತೆರೆಯಲ್ಪಟ್ಟಿವೆ, ಯಾವ limits ಅನ್ವಯಿಸುತ್ತವೆ ಮತ್ತು HTTP Message Signatures (RFC 9421) ಹಾಗೂ IETF Web Bot Auth protocol draft ಬಳಸಿ signed requests ಗಳ ಮೂಲಕ clients ತಮ್ಮನ್ನು ಹೇಗೆ ಗುರುತಿಸಿಕೊಳ್ಳಬಹುದು ಎಂಬುದನ್ನು ತಿಳಿಸಿ.
2. Partners ಮತ್ತು integrators ಗಳಿಗೆ ಮುಂಚಿತವಾಗಿ ತಿಳಿಸಿ. Preview ಸಮಯದಲ್ಲಿ known integration restricted slice ಗೆ ಒಳಪಟ್ಟರೆ, enforce ಮಾಡುವ ಮೊದಲು ಅದರ owner ಅನ್ನು ಸಂಪರ್ಕಿಸಿ.
3. ಉಪಯುಕ್ತ responses ಅನ್ನು ಹಿಂತಿರುಗಿಸಿ. Policy request ಅನ್ನು ಮಿತಿಗೊಳಿಸಿದರೆ ಅಥವಾ challenge ಮಾಡಿದರೆ, 429 Too Many Requests with Retry-After ಹೀಗಿರುವ ಸ್ಪಷ್ಟ status code ಮತ್ತು ನಿಮ್ಮ documentation ಗೆ link ಜೊತೆ respond ಮಾಡಿ. Problem Details format ನಲ್ಲಿರುವ machine-readable body ಸ್ವಯಂಚಾಲಿತ clients ಗೆ ಸಂರಚಿತ ಕಾರಣವನ್ನು ನೀಡುತ್ತದೆ. ಚೆನ್ನಾಗಿ ನಿರ್ಮಿಸಿದ agent ಗಳು ಕಾರಣವನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಾಗ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ.
4. ನಿಮ್ಮ support team ಗೆ evidence ನೀಡಿ. Blocked request ಕುರಿತ ticket ಬಂದಾಗ, support engineering ಅನ್ನು ಕೇಳದೆ route, class, basis ಮತ್ತು policy decision ಅನ್ನು ಹುಡುಕಲು ಸಾಧ್ಯವಾಗಬೇಕು.

ಬದಲಾವಣೆಗಳನ್ನು ಘೋಷಿಸಿ ಮತ್ತು ವಿವರಿಸುವ teams ಗಳು ಶಾಂತವಾಗಿ rules ಬದಲಿಸುವ teams ಗಳಿಗಿಂತ ಬಹಳ ಕಡಿಮೆ ಅಚ್ಚರಿಗಳನ್ನು ನೋಡುತ್ತವೆ, ಮತ್ತು ಹೊಂದಿಕೊಳ್ಳುವ clients ಕಾಲಕ్రమೇಣ ಗುರುತಿಸಲು ಸುಲಭವಾಗುತ್ತವೆ.

ಪ್ರತಿಯೊಂದು route ಗಾಗಿ checklist

• Class mix, Unknown rate ಮತ್ತು outcomes ಗಳಿಗೆ baseline ದಾಖಲಿಸಲಾಗಿದೆ.
• ಸ್ಪಷ್ಟವಾದ fallback ಜೊತೆಗೆ policy data ಆಗಿ ಬರೆಯಲಾಗಿದೆ.
• Preview run, sample review, false positive ವರ್ಗಗಳ ವಿವರಣೆ.
• Metrics ಗಮನಿಸುತ್ತಾ ಸಣ್ಣ slice ನಲ್ಲಿ enforcement ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ.
• Failure behavior ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ: fail open ಅಥವಾ fail closed.
• Expansion ಮೊದಲು rollback ಪರೀಕ್ಷಿಸಲಾಗಿದೆ.

Proof of Actor ಎಲ್ಲಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ

Proof of Actor ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಆಧರಿಸಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. Observation ಅಚ್ಚುಕಟ್ಟಾದ default, ಪ್ರತಿಯೊಂದು result ಅದರ basis ಅನ್ನು ಹೊರುತ್ತದೆ, ಮತ್ತು Route policies ಗಳು ನಿಮ್ಮ own code ನಲ್ಲಿ route by route ನೀವು ವ್ಯಾಖ್ಯಾನಿಸಿ enforce ಮಾಡುವುದಕ್ಕೆ ಸೇರಿದವು. Detect, Understand, Route: ಆ ಕ್ರಮದಲ್ಲಿ.

ನಮ್ಮ ತಂಡದೊಂದಿಗೆ ನಿಮ್ಮ own application ನಲ್ಲಿ rollout ಅನ್ನು ಕೆಲಸ ಮಾಡುವುದಕ್ಕಾಗಿ, early access ಗಾಗಿ apply ಮಾಡಿ. Decision flow ಅನ್ನು ಅಂತ್ಯದಿಂದ ಅಂತ್ಯಕ್ಕೆ ತಿಳಿಯಲು, How Proof of Actor works ಅನ್ನು ಓದಿ.

ಮೂಲಗಳು

• RFC 6585: Additional HTTP Status Codes, Section 4: 429 Too Many Requests status code
• RFC 9110: HTTP Semantics, Retry-After: ಯಾವಾಗ retry ಮಾಡಬೇಕು ಎಂದು clients ಗಳಿಗೆ ತಿಳಿಸುವುದು
• RFC 9457: Problem Details for HTTP APIs: machine-readable error bodies
• RFC 9421: HTTP Message Signatures: automated clients requests ಗಳಿಗೆ ಹೇಗೆ sign ಮಾಡುತ್ತವೆ
• draft-ietf-webbotauth-httpsig-protocol: signed automated traffic ಗಾಗಿ IETF Web Bot Auth draft (November 2026 ರಂತೆ ಕೆಲಸ ನಡೆಯುತ್ತಿದೆ)