ଅଭିକର୍ତ୍ତା-ସଚେତନ ନୀତିଗୁଡ଼ିକୁ ସୁରକ୍ଷିତ ଭାବେ କିପରି ରୋଲ୍ ଆଉଟ୍ କରିବେ

actor-aware policies ରୋଲ୍ ଆଉଟ୍ କରିବାବେଳେ କ'ଣ ଭୁଲ୍ ହୋଇପାରେ?

ଏକ actor-aware policy କେ ଅନୁସାରେ ଆପଣଙ୍କର application କିପରି respond କରେ, ସେଥିରେ ପରିବର୍ତ୍ତନ ଆଣେ। ଭଲ ଭାବେ କରାଗଲେ, ଏହା ଲୋକମାନଙ୍କୁ ସୁଗମ experience ଦିଏ, legitimate agents କୁ ଏକ structured path ଦିଏ, ଏବଂ ଯେଉଁଠାରେ ଆବଶ୍ୟକ ସେଠି ମାତ୍ର friction ଯୋଗ କରେ। ଭୁଲ୍ ଭାବେ କରାଗଲେ, ଏହା real users କୁ ବାହାରେ ରଖିଦିଏ, ଆପଣଙ୍କର customers ଯେଉଁ integrations ଉପରେ ଭରସା କରନ୍ତି ସେଗୁଡ଼ିକୁ ଭଙ୍ଗାଇଦିଏ, ଏବଂ support tickets ସୃଷ୍ଟି କରେ ଯାହାକୁ କେହି ବ୍ୟାଖ୍ୟା କରିପାରେନି।

ପାର୍ଥକ୍ୟଟି ସାଧାରଣତଃ policy logic ରେ ନୁହେଁ। ଏହା rollout ରେ ଥାଏ। (policy model ନିଜେ ପାଇଁ, humans and AI agents ପାଇଁ app-level policies କିପରି design କରିବେ ଦେଖନ୍ତୁ।) ଏହି guide ଏକ staged process ବର୍ଣ୍ଣନା କରେ ଯାହାକୁ team ମାନେ କୌଣସି route ପାଇଁ follow କରିପାରିବେ: observe, preview, ଛୋଟ slice ପାଇଁ enforce, ତାପରେ expand। ପ୍ରତ୍ୟେକ stage ରେ ଏକ ସ୍ପଷ୍ଟ exit criterion ଏବଂ ଫେରିବାର ଦ୍ରୁତ ଉପାୟ ରହେ।

the three modes

ପ୍ରତ୍ୟେକ policy କୁ route ଅନୁସାରେ ତିନୋଟି mode ମଧ୍ୟରୁ ଗୋଟିଏରେ ଚାଲୁଛି ବୋଲି ଭାବନ୍ତୁ:

• Observe. Classifications record କରାଯାଏ। Application ସେଗୁଡ଼ିକ ନଥିଲେ ଯେପରି respond କରୁଥାନ୍ତା, ସେହିପରି ଠିକ୍ ସେହିଭଳି respond କରେ।
• Preview. Policy evaluate କରାଯାଏ ଏବଂ ତାହାର decision record ହୁଏ, କିନ୍ତୁ apply ହୁଏନାହିଁ। କ'ଣ ହୋଇଥାନ୍ତା ଆପଣ ଦେଖିପାରିବେ।
• Enforce. Decision କୁ real requests ଉପରେ apply କରାଯାଏ।

Modeଟି route ଏବଂ policy pair ସହିତ ସମ୍ବନ୍ଧିତ, ସମଗ୍ର application ସହିତ ନୁହେଁ। ଆପଣଙ୍କର documentation pages enforce ହୋଇପାରେ, ଯେତେବେଳେ ଆପଣଙ୍କର checkout ଏପର୍ଯ୍ୟନ୍ତ observe ହେଉଥାଏ।

Step 1: ଆପଣଙ୍କର baseline ଜାଣିବା ପର୍ଯ୍ୟନ୍ତ observe କରନ୍ତୁ

ପ୍ରତ୍ୟେକ route କୁ observe mode ରେ ରଖି ଆରମ୍ଭ କରନ୍ତୁ। କମ୍ ସେ କମ୍ ଏଗୁଡ଼ିକ collect କରନ୍ତୁ:

• route ଏବଂ method,
• actor class (Human, Human + AI, Agent କିମ୍ବା Unknown) ଏବଂ ତାହାର basis (verified, declared, inferred କିମ୍ବା unknown), application traffic ପାଇଁ ଆମ taxonomy ରେ ଯେପରି define କରାଯାଇଛି,
• response status ଏବଂ route ପାଇଁ ଗୋଟିଏ simple outcome marker, ଯେପରି "account created" କିମ୍ବା "search returned results"।

ସାଧାରଣ weekly cycles ଏବଂ ସେଇ ସମୟରେ ship କରୁଥିବା କୌଣସି release କୁ cover କରିବା ପର୍ଯ୍ୟନ୍ତ long enough run କରନ୍ତୁ। ତାପରେ ଆପଣ ଯେ route ଗୁଡ଼ିକ ଉପରେ ଧ୍ୟାନ ଦେଉଛନ୍ତି, ସେଗୁଡ଼ିକ ପାଇଁ baseline ଲେଖି ରଖନ୍ତୁ: class mix, Unknown rate, ଏବଂ class ପ୍ରତି outcome rate। ପରେ ଯାହା କିଛି ହେବ, ସବୁକୁ ଏହି numbers ସହିତ compare କରିବେ।

Exit criterion: ଆପଣ ପ୍ରତ୍ୟେକ candidate route ପାଇଁ ବର୍ଣ୍ଣନା କରିପାରିବେ, କେ ଏହା ବ୍ୟବହାର କରେ ଏବଂ class ଅନୁସାରେ outcomes କିପରି ଭିନ୍ନ ହୁଏ।

Step 2: Policy କୁ data ଭାବେ ଲେଖନ୍ତୁ

Policies କୁ review, test ଏବଂ rollback କରିବା ସହଜ ହୁଏ ଯେତେବେଳେ ସେଗୁଡ଼ିକ scattered if statements ର ବଦଳରେ data ହୁଏ।

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 ରେ ଏକ explicit fallback ରହେ। ଏହା Unknown results, timeout ଏବଂ କୌଣସି rule ଯାହାକୁ cover କରେନି ସେହି case ପାଇଁ ବ୍ୟବହୃତ action। ଏହାକୁ deliberate ଭାବେ ଚୟନ କରିବା ସମଗ୍ର process ରେ ସବୁଠାରୁ important safety decision ଅଟେ।

Step 3: ଗୋଟିଏ ସ୍ଥାନରେ evaluate କରନ୍ତୁ

ଗୋଟିଏ single evaluation function mode ସବୁଠାରେ behavior କୁ consistent ରଖେ।

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 କୁ apply କରନ୍ତୁ:

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 ର ଅର୍ଥ ହେଉଛି ସେଇ same session କିମ୍ବା client enforced slice ଭିତରେ ରହେ କିମ୍ବା ବାହାରେ ରହେ, ଯାହା ଫଳରେ requests ମଧ୍ୟରେ behavior flip ହୋଇନଥାଏ।

Step 4: enforce କରିବା ପୂର୍ବରୁ false positives କିପରି measure କରିବେ?

ଗୋଟିଏ route କୁ preview କୁ move କରନ୍ତୁ। ବର୍ତ୍ତମାନ ପ୍ରତ୍ୟେକ request ସେ decision record କରେ ଯାହା ଏହାକୁ ମିଳିଥାନ୍ତା। ଏହିଠାରେ ଆପଣ policy ଠିକ୍ କି ନୁହେଁ ସେଥି ଶିଖନ୍ତି।

False positive ହେଉଛି ସେ request ଯାହାକୁ policy restrict କରିଥାନ୍ତା, କିନ୍ତୁ allowed ହେବା ଉଚିତ୍ ଥିଲା। କେବଳ classifications ଦେଖି ଆପଣ ଏହା measure କରିପାରିବେନି, କାରଣ classification ନିଜେ ହିଁ ଆପଣ test କରୁଛନ୍ତି। ଏହାକୁ legitimate use ର independent signals ସହିତ measure କରନ୍ତୁ:

• request ଏକ normal successful flow ସମାପ୍ତ କଲା, ଯେପରି signed-in user ତାଙ୍କର କାମ save କଲେ,
• client ହେଉଛି ଜଣାଶୁଣା partner integration କିମ୍ବା ଏକ verified operator ଯାହାକୁ serve କରିବାକୁ ଆପଣ ସମ୍ମତ ହୋଇଛନ୍ତି,
• support tickets କିମ୍ବା user reports ପ୍ରଭାବିତ route କୁ reference କରେ,
• would-be restricted requests ର ଏକ sample ର manual review।

ହାତେ ଏକ sample review କରନ୍ତୁ। policy ଯାହାକୁ challenge କରିଥାନ୍ତା ସେହି twenty real requests ପଢ଼ିବା ହେଉଛି rule ଟି ବହୁତ broad କି ନୁହେଁ ଖୋଜିବାର ସବୁଠାରୁ ଦ୍ରୁତ ଉପାୟ।

Exit criterion: would-be restricted set ରେ ସତରେ ଯାହାକୁ restrict କରିବା ଉଦ୍ଦେଶ୍ୟ ଅଛି ସେହି traffic ପ୍ରାଧାନ୍ୟ ପାଏ, ଏବଂ ଆପଣ ପାଇଥିବା ପ୍ରତ୍ୟେକ false positive category ପାଇଁ ଏକ explanation ରହିଛି।

Step 5: ଛୋଟ slice ପାଇଁ enforce କରନ୍ତୁ

ଗୋଟିଏ small enforcePercent ସହ route କୁ enforce କୁ switch କରନ୍ତୁ। Slice କୁ ଯଥେଷ୍ଟ ଛୋଟ ରଖନ୍ତୁ, ଯେପରି ଗୋଟିଏ mistake ଅଳ୍ପ requests ଉପରେ ପ୍ରଭାବ ପକାଏ, ଏବଂ ଯଥେଷ୍ଟ ବଡ଼ ରଖନ୍ତୁ, ଯାହାରେ ଏକ କିମ୍ବା ଦୁଇ ଦିନ ମଧ୍ୟରେ measurable signal ମିଳିବ।

ଆପଣ baseline ଭାବେ set କରିଥିବା ସେଇ same metrics ଦେଖନ୍ତୁ:

• route ରେ class ପ୍ରତି outcome rate,
• error ଏବଂ challenge completion rates,
• route mention କରୁଥିବା support volume,
• latency, କାରଣ evaluation request path ଉପରେ ବସେ।

ଯଦି enforced slice ରେ Human traffic ପାଇଁ outcomes, rest ସହିତ compare କରିବାକାଳେ, drop ହୁଏ, ତେବେ expanding ପୂର୍ବରୁ stop କରନ୍ତୁ ଏବଂ investigate କରନ୍ତୁ।

Step 6: ଧୀରେ ଧୀରେ expand କରନ୍ତୁ

Steps ରେ slice ବୃଦ୍ଧି କରନ୍ତୁ, ଉଦାହରଣ ସ୍ୱରୂପ small share ରୁ quarter, ତାପରେ half, ତାପରେ ସମସ୍ତ traffic, ପ୍ରତ୍ୟେକ step ରେ ଏକ normal cycle ଦେଖିବା ପର୍ଯ୍ୟନ୍ତ hold କରନ୍ତୁ। ପୂର୍ବରୁ stages ଠିକ୍ ଭାବେ କରାଯାଇଥିଲେ expansion boring ଲାଗେ। ସେଇଟା ହିଁ goal।

Fallback ଏବଂ failure behavior ଚୟନ କରିବା

Evidence missing ହେଲେ କିମ୍ବା evaluation run ହୋଇପାରିବ ନାହିଁ, ପୂର୍ବରୁ ନିଷ୍ପତ୍ତି ନିଅନ୍ତୁ କ'ଣ ହେବ।

• Fail open ର ଅର୍ଥ request actor context ନଥିଲେ ଯେପରି ପ୍ରବାହିତ ହେବ, ସେହିପରି ପ୍ରବାହିତ ହୁଏ। ଏହାକୁ public pages, documentation ଏବଂ read-only catalog endpoints ପରି low-risk routes ପାଇଁ use କରନ୍ତୁ।
• Fail closed ର ଅର୍ଥ ଆପଣଙ୍କର existing stronger check apply ହୁଏ, ଯେପରି re-authentication କିମ୍ବା review queue। ଏହାକୁ high-impact actions ପାଇଁ use କରନ୍ତୁ ଯେଉଁଠାରେ ଆପଣଙ୍କ ପାଖରେ ସେଇପରି check ପୂର୍ବରୁ ଅଛି।

Timeout କିମ୍ବା error କେବେ ମଧ୍ୟ Human result ସୃଷ୍ଟି କରିବାକୁ ଦିଅନ୍ତୁନି। Missing evidence ହେଉଛି Unknown, ଏବଂ Unknown route ର fallback ନେଇଥାଏ। AI traffic classify କରିବାବେଳେ Unknown କାହିଁକି ଏକ valid result ବିଷୟରେ ଆମ post ଏହି rule କାହିଁକି important ସେଥି explain କରେ।

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 deploy ନୁହେଁ, configuration change ହେବା ଉଚିତ୍। Policies କୁ ଏକ store ରେ ରଖନ୍ତୁ ଯାହାକୁ ଆପଣଙ୍କର team ଦ୍ରୁତ edit କରିପାରିବ, ଏବଂ ଏହି actions instant କରନ୍ତୁ:

1. ଗୋଟିଏ route କୁ ପୁଣି preview କୁ set କରନ୍ତୁ, ଯାହା measurement ରଖିଥିବା ସମୟରେ enforcement ବନ୍ଦ କରେ।
2. enforcePercent କୁ zero କରନ୍ତୁ।
3. ଅନ୍ୟଗୁଡ଼ିକୁ ଛୁଆନାହାଁତୁ, ଗୋଟିଏ single rule disable କରନ୍ତୁ।

ପ୍ରତ୍ୟେକ policy change କେ ଏବଂ କେବେ କଲା, ସେଥି record କରନ୍ତୁ। Outcomes move ହେଲେ, ପ୍ରଥମ ପ୍ରଶ୍ନ ସବୁବେଳେ ହେଉଛି କ'ଣ ପରିବର୍ତ୍ତନ ହେଲା।

ଲୋକମାନଙ୍କ ବିଷୟରେ consequential decisions ଏଡ଼ାନ୍ତୁ

Actor classifications ଗୋଟିଏ interaction ବିଷୟରେ evidence ବର୍ଣ୍ଣନା କରେ। ସେଗୁଡ଼ିକ ଜଣେ ବ୍ୟକ୍ତି ବିଷୟରେ judgment ନୁହେଁ। ଯେଉଁ decisions someone's employment, credit, education, housing କିମ୍ବା essential services ପ୍ରବେଶକୁ ପ୍ରଭାବିତ କରେ, ସେଥିର sole basis ଭାବରେ inferred class ବ୍ୟବହାର କରନ୍ତୁନି। ସେଇ flows ପାଇଁ, outcome ନିଷ୍ପତ୍ତି କରିବା ପାଇଁ ନୁହେଁ, human review କୁ route କରିବା ପରି actor context କୁ process ବାଛିବାରେ use କରନ୍ତୁ।

enforce କରିବା ପୂର୍ବରୁ communicate କରନ୍ତୁ

Automated clients କୁ ପ୍ରଭାବିତ କରୁଥିବା policies ସେମାନଙ୍କୁ ଚଳାଉଥିବା ଲୋକ ଏବଂ companies କୁ ମଧ୍ୟ ପ୍ରଭାବିତ କରେ। କିଛି communication support work ବହୁତ କମ୍ କରିଦିଏ:

1. Automated access ପାଇଁ ଆପଣଙ୍କର rules publish କରନ୍ତୁ। କେଉଁ routes open, କେଉଁ limits apply, ଏବଂ clients କିପରି signed requests ବ୍ୟବହାର କରି HTTP Message Signatures (RFC 9421) ଏବଂ IETF Web Bot Auth protocol draft ସହିତ ନିଜକୁ identify କରିପାରିବେ, ସେଥି state କରନ୍ତୁ।
2. Partners ଏବଂ integrators କୁ ପୂର୍ବରୁ କୁହନ୍ତୁ। ଯଦି ଗୋଟିଏ known integration preview ସମୟରେ restricted slice ଭିତରେ ପଡ଼େ, enforce କରିବା ପୂର୍ବରୁ ତାହାର owner ସହ contact କରନ୍ତୁ।
3. Useful responses ଫେରାନ୍ତୁ। ଯେତେବେଳେ policy request କୁ limit କରେ କିମ୍ବା challenge କରେ, 429 Too Many Requests ସହ Retry-After ପରି clear status code ଏବଂ ଆପଣଙ୍କର documentation କୁ link ସହ respond କରନ୍ତୁ। Problem Details format ରେ machine-readable body automated clients କୁ structured reason ଦିଏ। Well-built agents କାହିଁକି ବୁଝିଲେ adapt କରନ୍ତି।
4. ଆପଣଙ୍କର support team କୁ evidence ଦିଅନ୍ତୁ। ଯେତେବେଳେ blocked request ବିଷୟରେ ticket ଆସେ, support engineering କୁ ପଚାରିବା ଛଡ଼ା route, class, basis ଏବଂ policy decision lookup କରିପାରିବା ଉଚିତ୍।

ଯେ team ମାନେ changes ଘୋଷଣା କରନ୍ତି ଏବଂ ସେଗୁଡ଼ିକ explain କରନ୍ତି, ସେମାନେ rules quietly switch କରୁଥିବା team ଠାରୁ ବହୁତ କମ୍ surprises ଦେଖନ୍ତି, ଏବଂ adapt କରୁଥିବା clients ସମୟ ସହିତ ଚିହ୍ନିବା ସହଜ ହୁଏ।

ପ୍ରତ୍ୟେକ route ପାଇଁ ଏକ checklist

• Class mix, Unknown rate ଏବଂ outcomes ପାଇଁ baseline record କରାଯାଇଛି।
• Explicit fallback ସହିତ policy data ଭାବେ ଲେଖାଯାଇଛି।
• Preview run କରାଯାଇଛି, sample review କରାଯାଇଛି, false positive categories explain କରାଯାଇଛି।
• Metrics ଉପରେ ନଜର ରଖି ଛୋଟ slice ଉପରେ enforcement ଆରମ୍ଭ କରାଯାଇଛି।
• Failure behavior ଚୟନ କରାଯାଇଛି: fail open କିମ୍ବା fail closed।
• Expansion ପୂର୍ବରୁ rollback test କରାଯାଇଛି।

Proof of Actor କେଉଁଠି fit ହୁଏ

Proof of Actor ଏହି process ର ଚାରିପାଖରେ design କରାଯାଇଛି। Observation default, ପ୍ରତ୍ୟେକ result ତାହାର basis ବହନ କରେ, ଏବଂ Route policies route by route ଆପଣଙ୍କର own code ରେ define ଏବଂ enforce କରିବା ଆପଣଙ୍କର। Detect, Understand, Route: ସେହି କ୍ରମରେ।

ଆପଣଙ୍କର own application ଉପରେ ଆମ team ସହିତ ଗୋଟିଏ rollout ରେ କାମ କରିବା ପାଇଁ, early access ପାଇଁ apply କରନ୍ତୁ। End to end decision flow ପାଇଁ, How Proof of Actor works ପଢ଼ନ୍ତୁ।

Sources

• 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 ଅବଧି ପର୍ଯ୍ୟନ୍ତ work in progress)