Actor-aware policies को सुरक्षित तरीके से कैसे लागू करें

Actor-aware policies लागू करते समय क्या गलत हो सकता है?

एक actor-aware policy इस आधार पर बदलती है कि आपकी application पर कौन या क्या act कर रहा है। सही तरीके से लागू करने पर यह लोगों को सहज अनुभव देती है, legitimate agents को एक structured path देती है, और friction केवल वहीं जोड़ती है जहां वह मायने रखती है। गलत तरीके से लागू करने पर यह real users को बाहर कर देती है, उन integrations को तोड़ देती है जिन पर आपके customers निर्भर करते हैं, और ऐसे support tickets पैदा करती है जिनका कोई स्पष्ट जवाब नहीं होता।

अंतर अक्सर policy logic में नहीं होता। अंतर rollout में होता है। (Policy model के लिए, humans और AI agents के लिए app-level policies design करना देखें।) यह guide एक staged process बताती है जिसे teams किसी भी route पर follow कर सकती हैं: observe करें, preview करें, एक slice पर enforce करें, फिर विस्तार करें। हर stage का एक clear exit criterion और वापस जाने का तेज तरीका है।

तीन modes

हर policy को हर route पर इन तीन modes में से किसी एक में चलने वाला मानें:

• Observe. Classifications record की जाती हैं। Application ठीक वैसे ही respond करती है जैसे उनके बिना करती।
• Preview. Policy evaluate होती है और उसका decision record होता है, लेकिन लागू नहीं होता। आप देख सकते हैं कि क्या होता।
• Enforce. Decision real requests पर लागू होता है।

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 में परिभाषित है,
• response status और route के लिए एक सरल outcome marker, जैसे "account created" या "search returned results"।

इतना समय चलाएं कि सामान्य weekly cycles और उस अवधि में ship किए गए किसी भी release को cover किया जा सके। फिर जिन routes की आपको चिंता है, उनमें से हर एक के लिए अपना baseline लिखें: class mix, Unknown rate, और class के अनुसार outcome rate। आगे जो भी होगा, आप इन numbers से compare करेंगे।

Exit criterion: आप हर candidate route के लिए बता सकते हैं कि उसे कौन use करता है और class के अनुसार outcomes कैसे अलग हैं।

Step 2: Policy को data के रूप में लिखें

Policies को review, test और roll back करना तब आसान होता है जब वे data हों, न कि बिखरे हुए if statements।

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 और उन सभी cases के लिए उपयोग होने वाला action है जिन्हें कोई rule cover नहीं करता। इसे सोच-समझकर चुनना पूरे process का सबसे महत्वपूर्ण safety decision है।

Step 3: एक ही जगह evaluate करें

एक single evaluation function modes के बीच 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 लागू करें:

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 के अंदर या बाहर बना रहता है, ताकि लोगों को requests के बीच behavior बदलता हुआ न दिखे।

Step 4: Enforce करने से पहले false positives कैसे मापें?

एक route को preview पर ले जाएं। अब हर request उस decision को record करती है जो उसे मिलता। यहीं आप सीखते हैं कि policy सही है या नहीं।

False positive वह request है जिसे policy restrict करती, लेकिन उसे allow किया जाना चाहिए था। आप इसे classification से अकेले नहीं माप सकते, क्योंकि classification ही वह चीज़ है जिसे आप test कर रहे हैं। इसे legitimate use के independent signals के against मापें:

• request ने एक normal successful flow पूरा किया, जैसे signed-in user का काम save करना,
• client एक known partner integration या verified operator है जिसे आपने serve करने पर सहमति दी है,
• support tickets या user reports प्रभावित route का reference देती हैं,
• उन requests के sample की manual review जो restricted हो सकती थीं।

एक sample को हाथ से review करें। बीस real requests पढ़ना जिन्हें policy challenge करती, यह जानने का सबसे तेज़ तरीका है कि कोई rule जरूरत से ज्यादा व्यापक है या नहीं।

Exit criterion: restricted हो सकने वाले requests का सेट वास्तव में restrict करने योग्य traffic से dominate हो, और आपको मिले हर false positive category के लिए आपके पास explanation हो।

Step 5: एक slice पर enforce करें

Route को छोटे enforcePercent के साथ enforce पर switch करें। Slice इतना छोटा रखें कि गलती से कुछ ही requests प्रभावित हों, और इतना बड़ा कि एक या दो दिन के भीतर measurable signal मिले।

उन्हीं metrics पर नजर रखें जिन्हें आपने baseline के रूप में set किया था:

• route पर class के अनुसार outcome rate,
• error और challenge completion rates,
• route का उल्लेख करने वाला support volume,
• latency, क्योंकि evaluation request path पर बैठती है।

अगर enforced slice में Human traffic के outcomes बाकी हिस्से की तुलना में गिरते हैं, तो expansion से पहले रुकें और जांच करें।

Step 6: धीरे-धीरे विस्तार करें

Slice को चरणों में बढ़ाएं, उदाहरण के लिए छोटे हिस्से से quarter, फिर half, फिर सभी traffic तक, और हर चरण पर इतना रुकें कि एक normal cycle दिखाई दे सके। जब पहले के चरण अच्छी तरह किए गए हों, तो expansion boring होता है। यही लक्ष्य है।

Fallback और failure behavior चुनना

पहले से तय करें कि evidence missing होने या evaluation न चल पाने पर क्या होगा।

• Fail open का मतलब है कि request वैसे ही आगे बढ़ती है जैसे actor context के बिना बढ़ती। इसे public pages, documentation और read-only catalog endpoints जैसे low-risk routes के लिए उपयोग करें।
• Fail closed का मतलब है कि आपका मौजूदा stronger check लागू होता है, जैसे re-authentication या review queue। इसे high-impact actions के लिए उपयोग करें जहां आपके पास ऐसा check पहले से हो।

Timeout या error को कभी भी Human result न बनने दें। Missing evidence Unknown है, और Unknown route के fallback को अपनाता है। AI traffic classify करते समय Unknown एक valid 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 एक configuration change होना चाहिए, deploy नहीं। Policies को ऐसे store में रखें जिसे आपकी team जल्दी edit कर सके, और इन actions को instant बनाएं:

1. किसी route को वापस preview पर set करें, जिससे measurement बनी रहती है लेकिन enforcement रुक जाती है।
2. enforcePercent को zero पर set करें।
3. दूसरों को छुए बिना एक 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 करें

जो policies automated clients को प्रभावित करती हैं, वे उन लोगों और कंपनियों को भी प्रभावित करती हैं जो उन्हें चलाते हैं। थोड़ी communication बहुत सारे support work से बचाती है:

1. Automated access के लिए अपने rules publish करें। बताएं कि कौन से routes खुले हैं, कौन से limits लागू होते हैं, और clients HTTP Message Signatures (RFC 9421) और IETF Web Bot Auth protocol draft का उपयोग करके signed requests के साथ खुद को कैसे identify कर सकते हैं।
2. Partners और integrators को पहले से बताएं। अगर कोई known integration preview के दौरान restricted slice में आ जाता है, तो enforcement से पहले उसके owner से संपर्क करें।
3. उपयोगी responses लौटाएं। जब policy किसी request को limit या challenge करती है, तो एक clear status code के साथ respond करें, जैसे 429 Too Many Requests with Retry-After, और अपनी documentation का link दें। Problem Details format में machine-readable body automated clients को structured reason देता है। अच्छी तरह बने agents तब adapt करते हैं जब वे कारण समझते हैं।
4. अपनी support team को evidence दें। जब blocked request के बारे में ticket आए, support को engineering से पूछे बिना route, class, basis और policy decision ढूंढने में सक्षम होना चाहिए।

जो teams changes announce करती हैं और उन्हें समझाती हैं, उन्हें quietly rules बदलने वाली teams की तुलना में बहुत कम surprises मिलते हैं, और जो clients adapt करते हैं वे समय के साथ अधिक आसानी से पहचाने जाते हैं।

हर route के लिए एक checklist

• Class mix, Unknown rate और outcomes के लिए baseline record किया गया।
• Explicit fallback के साथ policy data के रूप में लिखी गई।
• Preview चलाया गया, sample review किया गया, false positive categories समझाई गईं।
• Metrics देखते हुए एक छोटे slice पर enforcement शुरू किया गया।
• Failure behavior चुना गया: fail open या fail closed।
• Expansion से पहले rollback test किया गया।

Proof of Actor कहाँ फिट होता है

Proof of Actor इसी process के आसपास designed है। Observation default है, हर result अपना basis carry करता है, और Route policies आपकी own code में route by route define और enforce करने के लिए आपकी हैं। Detect, Understand, Route: इसी क्रम में।

अपनी 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: 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)