अॅक्टर-जाणिवा धोरणे सुरक्षितपणे कशी राबवायची

तुम्ही actor-aware policies राबवताना काय चुकू शकते?

अॅक्टर-जाणिवा धोरण application कसा प्रतिसाद देतो हे, कोण किंवा काय कृती करत आहे यावर आधारित बदलते. योग्य प्रकारे केल्यास, ते लोकांना सुरळीत अनुभव देते, वैध agents साठी संरचित मार्ग देते, आणि फक्त जिथे गरज आहे तिथेच अडथळा आणते. चुकीच्या प्रकारे केल्यास, ते खरे users बाहेर ठेवते, तुमचे customers अवलंबून असलेली integrations मोडते, आणि असा support ticket निर्माण करते ज्याचे कोणीही स्पष्टीकरण देऊ शकत नाही.

फरक बहुतेक वेळा policy logic मध्ये नसतो. तो rollout मध्ये असतो. (स्वतःच्या policy model साठी, मानव आणि AI agents साठी app-level policies डिझाइन करणे पहा.) हा मार्गदर्शक teams अनुसरू शकतील असा टप्प्याटप्प्याचा process सांगतो: observe करा, preview करा, एका slice साठी enforce करा, मग विस्तार करा. प्रत्येक टप्प्याला स्पष्ट exit criterion आणि मागे परतण्याचा जलद मार्ग असतो.

तीन mode

प्रत्येक route साठी प्रत्येक policy ही तीन mode पैकी एका mode मध्ये चालते असे समजा:

• Observe. वर्गीकरणे नोंदवली जातात. application त्याशिवाय जसा प्रतिसाद देईल तसाच देतो.
• Preview. policy चे मूल्यांकन केले जाते आणि तिचा निर्णय नोंदवला जातो, पण लागू केला जात नाही. काय झाले असते ते तुम्ही पाहू शकता.
• Enforce. निर्णय प्रत्यक्ष 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) आणि त्याचा आधार (verified, declared, inferred किंवा unknown), जसे application traffic साठी आमच्या taxonomy मध्ये परिभाषित केले आहे,
• response status आणि route साठी एक साधा outcome marker, उदा. "account तयार झाले" किंवा "search ने results परत केले".

सामान्य weekly cycles आणि त्या कालावधीत तुम्ही ship केलेला कोणताही release कव्हर होईल इतका वेळ चालवा. मग ज्या प्रत्येक route बद्दल तुम्हाला काळजी आहे त्यासाठी तुमचा baseline लिहा: class mix, Unknown rate, आणि प्रत्येक class साठी outcome rate. पुढे जे काही होईल त्याची तुलना तुम्ही या संख्यांशी कराल.

Exit criterion: प्रत्येक candidate route साठी तो कोण वापरतो आणि outcome class नुसार कसे बदलतात हे तुम्ही वर्णन करू शकता.

पायरी 2: policy ला data म्हणून लिहा

Policies scatter झालेल्या 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, timeout आणि कोणत्याही rule ने न कव्हर केलेल्या case साठी वापरले जाणारे action आहे. ते जाणीवपूर्वक निवडणे हा संपूर्ण process मधील सर्वात महत्त्वाचा safety निर्णय आहे.

पायरी 3: एका ठिकाणी evaluate करा

एकच evaluation function mode भरात वर्तन सुसंगत ठेवतो.

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 दरम्यान वर्तन उलटसुलट होताना दिसत नाही.

पायरी 4: enforce करण्यापूर्वी false positives कसे मोजता?

एक route preview मध्ये हलवा. आता प्रत्येक request त्या निर्णयाची नोंद करते जो त्याला मिळाला असता. याच ठिकाणी policy योग्य आहे की नाही हे समजते.

false positive म्हणजे अशी request ज्यावर policy निर्बंध आणला असता, पण प्रत्यक्षात तिला allow केले गेले पाहिजे होते. केवळ वर्गीकरणांमधून तुम्ही ते मोजू शकत नाही, कारण वर्गीकरणच तुम्ही तपासत आहात. स्वतंत्र signals विरुद्ध मोजा जे वैध वापर दाखवतात:

• request ने सामान्य यशस्वी flow पूर्ण केला, उदा. signed-in user ने काम जतन केले,
• client हा ज्ञात partner integration आहे किंवा तुम्ही सेवा देण्यास सहमती दिलेला verified operator आहे,
• support tickets किंवा user reports मध्ये प्रभावित route चा उल्लेख आहे,
• restricted होऊ शकलेल्या requests च्या sample चे manual review.

नमुना हाताने तपासा. policy ने ज्यांना challenge केले असते अशा वीस प्रत्यक्ष requests वाचणे हा खूप व्यापक rule शोधण्याचा सर्वात जलद मार्ग आहे.

Exit criterion: restricted होऊ शकलेला set खरोखरच तुम्हाला restrict करायचा आहे अशा traffic ने प्रामुख्याने भरलेला आहे, आणि तुम्हाला सापडलेल्या प्रत्येक false positive category साठी तुमच्याकडे स्पष्टीकरण आहे.

पायरी 5: एका slice साठी enforce करा

लहान enforcePercent सह route ला enforce वर स्विच करा. slice इतका लहान ठेवा की चुक झाल्यास कमी requests प्रभावित होतील आणि इतका मोठा की एक किंवा दोन दिवसांत मोजण्याजोगा signal मिळेल.

तुम्ही baseline म्हणून ठरवलेली तीच 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, मग सर्व traffic पर्यंत, आणि प्रत्येक टप्प्यावर इतका वेळ थांबा की सामान्य cycle दिसेल. आधीचे टप्पे नीट झाले असतील तर विस्तार कंटाळवाणा वाटतो. तेच उद्दिष्ट आहे.

fallback आणि failure वर्तन निवडणे

evidence हरवला किंवा evaluation चालू शकला नाही तर काय होईल हे आधीच ठरवा.

• Fail open म्हणजे request actor context शिवाय जशी गेली असती तशीच पुढे जाते. सार्वजनिक pages, documentation आणि read-only catalog endpoints सारख्या कमी-जोखमीच्या routes साठी ते वापरा.
• Fail closed म्हणजे re-authentication किंवा review queue सारखी तुमची विद्यमान कडक तपासणी लागू होते. जिथे अशी तपासणी आधीच आहे अशा उच्च-प्रभावाच्या actions साठी ते वापरा.

timeout किंवा error कधीही Human result निर्माण करू देऊ नका. Missing evidence हे Unknown आहे, आणि Unknown route च्या fallback ला जाते. AI traffic वर्गीकरणात Unknown हा वैध result का आहे यावरील आमची पोस्ट हा नियम का महत्त्वाचा आहे ते स्पष्ट करते.

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 असावा. तुमच्या team ला पटकन edit करता येईल अशा store मध्ये policies ठेवा, आणि या actions तत्काळ करा:

1. route पुन्हा preview वर सेट करा, ज्यामुळे measurement सुरू ठेवून enforcement थांबते.
2. enforcePercent शून्यावर सेट करा.
3. इतरांना न हात लावता एकच rule disable करा.

प्रत्येक policy change कोणी केला आणि केव्हा केला हे नोंदवा. Outcome बदलले की पहिला प्रश्न नेहमी काय बदलले हा असतो.

लोकांविषयी परिणामकारक निर्णय टाळा

Actor classifications interaction बद्दलचा evidence सांगतात. त्या व्यक्तीबद्दलचा निर्णय नाहीत. एखाद्या inferred class चा एकमेव आधार म्हणून वापर करून एखाद्याच्या रोजगार, credit, शिक्षण, निवास किंवा अत्यावश्यक सेवांपर्यंतच्या प्रवेशावर परिणाम करणारे निर्णय घेऊ नका. अशा flows साठी actor context वापरून प्रक्रिया निवडा, उदाहरणार्थ outcome ठरवण्याऐवजी human review कडे route करा.

enforce करण्यापूर्वी संवाद साधा

Automated clients वर परिणाम करणाऱ्या policies त्या चालवणाऱ्या लोकांवर आणि कंपन्यांवरही परिणाम करतात. थोडा संवाद खूप support work वाचवतो:

1. Automated access साठी तुमचे rules प्रकाशित करा. कोणते routes open आहेत, कोणत्या limits लागू होतात, आणि HTTP Message Signatures (RFC 9421) आणि IETF Web Bot Auth protocol draft वापरून signed requests द्वारे clients स्वतःची ओळख कशी देऊ शकतात हे सांगा.
2. Partners आणि integrators ना आधीच कळवा. preview दरम्यान एखादी ज्ञात integration restricted slice मध्ये आली, तर enforce करण्यापूर्वी तिच्या owner शी संपर्क करा.
3. उपयुक्त responses द्या. जेव्हा policy request वर limit लावते किंवा challenge करते, तेव्हा 429 Too Many Requests with Retry-After सारखा स्पष्ट status code आणि तुमच्या documentation ची link द्या. Problem Details format मधील machine-readable body automated clients ला structured reason देते. चांगले बांधलेले agents कारण समजल्यावर adapt होतात.
4. तुमच्या support team ला evidence द्या. Blocked request बद्दल ticket आला की engineering ला विचारण्याशिवाय support ने route, class, basis आणि policy decision शोधता आले पाहिजे.

बदल जाहीर करणाऱ्या आणि समजावून सांगणाऱ्या teams ना शांतपणे rules बदलणाऱ्या teams पेक्षा खूपच कमी आश्चर्यांचा सामना करावा लागतो, आणि adapt होणाऱ्या clients ना कालांतराने ओळखणे सोपे होते.

प्रत्येक route साठी checklist

• class mix, Unknown rate आणि outcomes साठी baseline नोंदवलेला आहे.
• Policy स्पष्ट fallback सह data म्हणून लिहिलेली आहे.
• Preview चालवला, sample तपासला, false positive categories समजावून सांगितल्या.
• metrics पाहत लहान slice वर enforcement सुरू केले.
• Failure वर्तन निवडले: fail open किंवा fail closed.
• विस्तारापूर्वी rollback तपासला.

Proof of Actor कुठे बसते

Proof of Actor ही प्रक्रिया लक्षात घेऊन डिझाइन केले आहे. Observation हे default आहे, प्रत्येक result सोबत त्याचा basis असतो, आणि Route policies तुमच्या स्वतःच्या code मध्ये, route-by-route define आणि enforce करण्यासाठी तुमच्या आहेत. Detect, Understand, Route: या क्रमाने.

तुमच्या स्वतःच्या application वर आमच्या team सोबत rollout वर काम करण्यासाठी, early access साठी apply करा. निर्णय प्रवाह end to end पाहण्यासाठी, 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: 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)