એક્ચ્યુએટર-અવેર નીતિઓને સુરક્ષિત રીતે કેવી રીતે રોલ આઉટ કરવી

Actor-aware નીતિઓ રોલ આઉટ કરતી વખતે શું ખોટું થઈ શકે?

Actor-aware policy તમારી application કેવી રીતે respond કરે છે તે બદલે છે, તે કોણ અથવા શું act કરી રહ્યું છે તેના આધારે. યોગ્ય રીતે કરવામાં આવે તો, તે લોકોને સરળ અનુભવ આપે છે, legitimate agents ને structured માર્ગ આપે છે, અને જ્યાં જરૂરી હોય ત્યાં જ friction ઉમેરે છે. ખોટી રીતે કરવામાં આવે તો, તે real users ને બહાર રાખે છે, તમારા customers આધાર રાખે તે integrations તોડે છે, અને એવા support tickets ઊભા કરે છે જેને કોઈ સમજાવી શકતું નથી.

ફરક બહુ ઓછો policy logic માં હોય છે. ફરક rollout માં હોય છે. (Policy model પોતે જોવો હોય તો humans અને AI agents માટે app-level policies designing જુઓ.) આ guide એક staged process વર્ણવે છે જેને ટીમ કોઈપણ route માટે અનુસરી શકે: observe કરો, preview કરો, એક slice માટે enforce કરો, પછી વિસ્તારો. દરેક stageમાં સ્પષ્ટ exit criterion અને પાછા ફરવાનો ઝડપી રસ્તો હોય છે.

ત્રણ modes

દરેક policyને route પ્રમાણે ત્રણ modesમાંથી એકમાં ચાલતી તરીકે વિચારો:

• Observe. Classifications record થાય છે. Application તેમ જ respond કરે છે જેમ કે તે તે વગર કરતી હોત.
• Preview. Policy evaluate થાય છે અને તેનો decision record થાય છે, પરંતુ apply થતો નથી. તમે જોઈ શકો છો કે શું થયું હોત.
• Enforce. Decision વાસ્તવિક requests પર apply થાય છે.

Mode આખી application માટે નહીં, route અને policy ની pair માટે હોય છે. તમારી documentation pages enforce થઈ શકે છે જ્યારે તમારો checkout હજી observe કરી રહ્યો હોય.

પગલું 1: જ્યાં સુધી baseline ન સમજાય ત્યાં સુધી observe કરો

દરેક routeને observe modeમાં શરૂ કરો. ઓછામાં ઓછું આ collect કરો:

• route અને method,
• actor class (Human, Human + AI, Agent અથવા Unknown) અને તેનો આધાર (verified, declared, inferred અથવા unknown), જેમ કે application traffic માટેની અમારી taxonomyમાં વ્યાખ્યાયિત છે,
• response status અને route માટેનું એક સરળ outcome marker, જેમ કે "account created" અથવા "search returned results".

સામાન્ય weekly cycles અને તમે એ સમયગાળામાં ship કરો તે કોઈપણ releaseને cover થાય એટલો સમય ચાલવા દો. પછી તમે જે દરેક routeની care કરો છો તેના માટે તમારો baseline લખો: class mix, Unknown rate, અને દરેક class માટે outcome rate. તમે પછી આવનાર બધાને આ numbers સામે compare કરશો.

Exit criterion: તમે દરેક candidate route માટે વર્ણવી શકો છો કે તેનો ઉપયોગ કોણ કરે છે અને outcomes class પ્રમાણે કેવી રીતે બદલાય છે.

પગલું 2: policyને data તરીકે લખો

જ્યારે policies scattered if statements કરતાં data હોય ત્યારે તેમને review, test અને roll back કરવું વધુ સરળ હોય છે.

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, timeouts અને કોઈપણ એવા કેસ માટે વપરાતી action છે જેને કોઈ rule cover કરતું નથી. તેને જાણબૂઝીને પસંદ કરવું એ આખી પ્રક્રિયામાં સૌથી મહત્વપૂર્ણ safety decision છે.

પગલું 3: એક જ જગ્યાએ evaluate કરો

એક single evaluation function modes across 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 થતું ન દેખાય.

પગલું 4: enforce કરતાં પહેલાં false positives કેવી રીતે માપશો?

એક routeને preview પર ખસેડો. હવે દરેક request એ decision record કરે છે જે તેને મળવાનું હતું. અહીંથી તમને ખબર પડે છે કે policy સાચી છે કે નહીં.

False positive એ એવી request છે જેને policy restrict કરતી હોત, પરંતુ જે allow થવી જોઈએ હતી. તમે તેને classifications પરથી એકલા માપી શકતા નથી, કારણ કે classification જ તમે test કરી રહ્યા છો. તેને legitimate useના independent signals સામે માપો:

• requestએ સામાન્ય successful flow પૂર્ણ કર્યો, જેમ કે signed-in userનું કામ save કરવું,
• client જાણીતી partner integration છે અથવા verified operator છે જેને તમે serve કરવા agree કર્યા છે,
• support tickets અથવા user reports affected routeનો ઉલ્લેખ કરે છે,
• would-be restricted requestsના sampleનું manual review.

એક sample હાથથી review કરો. એવા વીસ real requests વાંચવી, જેને policy challenge કરત, એ વધુ પડતા broad rule શોધવાનો સૌથી ઝડપી રસ્તો છે.

Exit criterion: would-be restricted set ખરેખર restrict કરવા માંગો છો એવા trafficથી પ્રબળ છે, અને તમને મળેલા દરેક false positive category માટે તમારી પાસે explanation છે.

પગલું 5: એક slice માટે enforce કરો

Routeને નાના enforcePercent સાથે enforce પર બદલો. slice એટલો નાનો રાખો કે ભૂલ થોડા requestsને જ અસર કરે અને એટલો મોટો કે એક કે બે દિવસમાં measurable signal આપે.

તમે baseline તરીકે નક્કી કરેલા same metrics જુઓ:

• route પર class પ્રમાણે outcome rate,
• error અને challenge completion rates,
• routeનો ઉલ્લેખ કરતી support volume,
• latency, કારણ કે evaluation request path પર બેઠેલી છે.

જો enforced sliceમાં Human trafficના outcomes બાકીના ભાગની સરખામણીમાં ઘટે, તો વિસ્તારો પહેલાં રોકો અને તપાસો.

પગલું 6: ધીમે ધીમે વિસ્તારો

Sliceને પગલાંમાં વધારો, ઉદાહરણ તરીકે નાના shareથી quarter, પછી half, પછી all traffic સુધી, અને દરેક પગલે એટલો સમય રોકો કે સામાન્ય cycle જોવા મળે. અગાઉના stages સારી રીતે થયા હોય ત્યારે expansion નિરસ લાગે છે. એ જ લક્ષ્ય છે.

Fallbacks અને failure behavior પસંદ કરવું

Evidence missing હોય અથવા evaluation ચાલી ન શકે ત્યારે શું થાય તે પહેલેથી નક્કી કરો.

• Fail open નો અર્થ છે કે request actor context વગર જેમ ચાલતી હોત તેમ આગળ વધે છે. public pages, documentation અને read-only catalog endpoints જેવા low-risk routes માટે તેનો ઉપયોગ કરો.
• Fail closed નો અર્થ છે કે તમારી existing stronger check લાગુ પડે છે, જેમ કે re-authentication અથવા review queue. high-impact actions માટે તેનો ઉપયોગ કરો જ્યાં તમારી પાસે પહેલેથી આવો check હોય.

Timeout અથવા error ક્યારેય Human result ન આપે. Missing evidence એટલે Unknown, અને Unknown routeના fallbackને અનુસરે છે. અમારા Unknown AI trafficને classify કરતી વખતે માન્ય result કેમ છે વિષેના postમાં સમજાવવામાં આવ્યું છે કે આ rule કેમ મહત્વનું છે.

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માં રાખો જેને તમારી ટીમ ઝડપથી edit કરી શકે, અને આ actions તરત શક્ય બનાવો:

1. Routeને પાછું preview પર મૂકો, જે measurement ચાલુ રાખીને enforcement બંધ કરે છે.
2. enforcePercentને zero પર સેટ કરો.
3. અન્ય rulesને હાથ લગાવ્યા વિના એક single rule disable કરો.

દરેક policy change કોણે અને ક્યારે કર્યું તેનો record રાખો. જ્યારે outcomes બદલાય, ત્યારે પહેલો સવાલ હંમેશા એ જ હોય છે કે શું બદલાયું.

લોકો વિશે consequential decisions લેવાનું ટાળો

Actor classifications કોઈ interaction વિશેનું evidence વર્ણવે છે. તે વ્યક્તિ વિશેનો judgment નથી. inferred classને એવી decisions માટે sole basis ન બનાવો જે કોઈની employment, credit, education, housing અથવા essential services સુધીની પહોંચને અસર કરે. આવા flows માટે, actor contextનો ઉપયોગ process પસંદ કરવા માટે કરો, ઉદાહરણ તરીકે human review તરફ routing કરવા માટે, outcome નક્કી કરવા માટે નહીં.

enforce કરતાં પહેલાં communicate કરો

Automated clientsને અસર કરતી policies તેને ચલાવતા લોકોને અને કંપનીઓને પણ અસર કરે છે. થોડી communication બહુ support work બચાવે છે:

1. Automated access માટે તમારા rules પ્રકાશિત કરો. કયા routes ખુલ્લા છે, કયા limits લાગુ પડે છે અને signed requests સાથે clients પોતાને કેવી રીતે ઓળખાવી શકે તે જણાવો, HTTP Message Signatures (RFC 9421) અને IETF Web Bot Auth protocol draftનો ઉપયોગ કરીને.
2. Partners અને integratorsને અગાઉથી જાણ કરો. જો preview દરમિયાન કોઈ જાણીતી integration restricted sliceમાં આવે, તો enforce કરતાં પહેલાં તેના ownerનો સંપર્ક કરો.
3. ઉપયોગી responses આપો. જ્યારે policy requestને limit અથવા challenge કરે, ત્યારે સ્પષ્ટ status code સાથે respond કરો, જેમ કે 429 Too Many Requests સાથે Retry-After, અને તમારી documentationની link સાથે. Problem Details formatમાં machine-readable body automated clientsને structured કારણ આપે છે. સારી રીતે બનેલા agents સમજે છે કે કેમ, એટલે adapt થાય છે.
4. તમારી support teamને evidence આપો. જ્યારે blocked request વિશે ticket આવે, support engineeringને પૂછ્યા વિના route, class, basis અને policy decision lookup કરી શકે એવી હોવી જોઈએ.

જે ટીમો changes જાહેર કરે છે અને સમજાવે છે તેઓને quietly rules switch કરનારી ટીમોની તુલનામાં ઘણી ઓછી surprises મળે છે, અને જે clients adapt થાય છે તેમને સમય જતાં ઓળખવું સરળ બને છે.

દરેક route માટે checklist

• Class mix, Unknown rate અને outcomes માટે baseline record થયો છે.
• Explicit fallback સાથે policy data તરીકે લખાઈ છે.
• Preview run થયું, sample review થયું, false positive categories સમજાવાઈ.
• Metrics જોતા નાના slice પર enforcement શરૂ થયું.
• Failure behavior પસંદ કર્યું: fail open અથવા fail closed.
• Expansion પહેલાં rollback test થયું.

Proof of Actor ક્યાં ફિટ થાય છે

Proof of Actor આ પ્રક્રિયા આસપાસ ડિઝાઇન કરવામાં આવ્યું છે. Observation default છે, દરેક result તેના basis સાથે આવે છે, અને Route policies તમારી પોતાની codeમાં, route by route, define અને enforce કરવાની છે. Detect, Understand, Route: એ જ ક્રમમાં.

તમારી પોતાની application પર અમારી ટીમ સાથે rollout પર કામ કરવા માટે, early access માટે અરજી કરો. Decision flow end to end માટે, 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: clientsને ક્યારે retry કરવું તે કહેવું
• 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)