actor-aware విధానాలను సురక్షితంగా ఎలా ప్రవేశపెట్టాలి

మీరు actor-aware policies ను ప్రవేశపెట్టినప్పుడు ఏమి తప్పు జరగవచ్చు?

ఒక actor-aware policy మీ application ఎలా స్పందించాలో, ఎవరు లేదా ఏమి acting చేస్తున్నారో ఆధారంగా మారుస్తుంది. బాగా చేస్తే, అది people కు smooth experience ఇస్తుంది, legitimate agents కు structured path ఇస్తుంది, మరియు అవసరమైన చోట మాత్రమే friction ను జోడిస్తుంది. చెడుగా చేస్తే, అది real users ను lock out చేస్తుంది, customers ఆధారపడే integrations ను break చేస్తుంది, మరియు ఎవరూ వివరించలేని support tickets ను సృష్టిస్తుంది.

తేడా చాలా అరుదుగా policy logic లో ఉంటుంది. అది rollout లో ఉంటుంది. (Policy model కోసం, చూడండి designing app-level policies for humans and AI agents.) ఈ guide ఏ route అయినా teams అనుసరించగల staged process ను వివరిస్తుంది: observe చేయండి, preview చేయండి, ఒక slice పై enforce చేయండి, తర్వాత expand చేయండి. ప్రతి stage కి స్పష్టమైన exit criterion మరియు తిరిగి వెళ్లడానికి వేగవంతమైన మార్గం ఉంటుంది.

మూడు modes

ప్రతి policy ని ప్రతి route లో మూడు modes లో ఒకటిగా నడుస్తున్నట్లు భావించండి:

• Observe. Classifications రికార్డ్ అవుతాయి. Application వాటి లేకుండా ఉన్నట్లే exactly స్పందిస్తుంది.
• Preview. Policy evaluate అవుతుంది మరియు దాని decision రికార్డ్ అవుతుంది, కానీ apply కాదు. ఏమి జరిగి ఉండేదో మీరు చూడగలరు.
• Enforce. Decision నిజమైన requests కు apply అవుతుంది.

Mode whole application కు కాదు, route మరియు policy pair కు చెందుతుంది. మీ 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), our taxonomy for application traffic లో నిర్వచించినట్టు,
• response status మరియు route కోసం ఒక సరళమైన outcome marker, ఉదాహరణకు "account created" లేదా "search returned results".

సాధారణ weekly cycles ను మరియు ఆ కాలంలో మీరు ship చేసే ఏ release ను cover చేయగలిగేంత సమయం run చేయండి. తర్వాత మీరు care చేసే ప్రతి route కోసం మీ baseline ను నమోదు చేయండి: class mix, Unknown rate, మరియు ప్రతి class కు outcome rate. ఆ తర్వాతి అన్నిటినీ ఈ numbers తో compare చేస్తారు.

Exit criterion: candidate route ప్రతి దానికి, ఎవరు దాన్ని ఉపయోగిస్తున్నారు మరియు class ప్రకారం outcomes ఎలా భిన్నంగా ఉన్నాయి అనేది మీరు వివరించగలరు.

Step 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 కి స్పష్టమైన fallback ఉంటుంది. అది Unknown results, timeouts, మరియు ఏ rule కూడా cover చేయని ప్రతి case కోసం ఉపయోగించే action. దీన్ని deliberately ఎంచుకోవడం మొత్తం 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 ను 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 అంటే అదే session లేదా client enforced slice లోకి లేదా బయటకు ఇలాగే ఉండటం, కాబట్టి people requests మధ్య behavior flip అవడాన్ని చూడరు.

Step 4: enforce చేయడానికి ముందు false positives ను ఎలా measure చేయాలి?

ఒక route ను preview కు move చేయండి. ఇప్పుడు ప్రతి request అది పొందేదని policy నిర్ణయాన్ని record చేస్తుంది. policy సరైందో లేదో నేర్చుకునే స్థలం ఇదే.

False positive అంటే policy restrict చేయగల request, కానీ అది allow చేయబడి ఉండాలి. Classifications మాత్రమే చూసి దీన్ని measure చేయలేరు, ఎందుకంటే మీరు test చేస్తున్నది classification నే. Independent signals of legitimate use తో దీనిని measure చేయండి:

• request సాధారణ successful flow ను complete చేసింది, ఉదాహరణకు signed-in user పని save చేయడం,
• client ఒక known partner integration లేదా మీరు serve చేయడానికి agree చేసిన verified operator,
• support tickets లేదా user reports affected route ను reference చేస్తాయి,
• would-be restricted requests లోని sample పై manual review.

ఒక sample ను చేతితో review చేయండి. policy challenge చేసి ఉండే twenty real requests ను చదవడం, చాలా broad గా ఉన్న rule ను కనుగొనడానికి అత్యంత వేగవంతమైన మార్గం.

Exit criterion: would-be restricted set నిజంగా మీరు restrict చేయాలనుకుంటున్న traffic చేత dominated గా ఉంటుంది, మరియు మీరు కనుగొన్న ప్రతి category of false positive కు explanation మీ వద్ద ఉంటుంది.

Step 5: ఒక slice కోసం enforce చేయండి

Route ను చిన్న enforcePercent తో enforce కు switch చేయండి. mistake few requests ను ప్రభావితం చేసేంత చిన్నగా, మరియు ఒకటి లేదా రెండు days లో measurable signal ఇవ్వడానికి సరిపడా పెద్దగా slice ను ఉంచండి.

మీ baseline గా set చేసిన అదే metrics ను watch చేయండి:

• route లో class per outcome rate,
• error మరియు challenge completion rates,
• route ను mention చేసే support volume,
• latency, ఎందుకంటే evaluation request path మీద ఉంటుంది.

Enforced slice లో Human traffic outcomes మిగతా వాటితో పోలిస్తే drop అయితే, expand చేయడానికి ముందు ఆపి investigate చేయండి.

Step 6: క్రమంగా expand చేయండి

Slice ను steps లో పెంచండి, ఉదాహరణకు చిన్న share నుండి quarter కు, తర్వాత half కు, తర్వాత all traffic కు, ప్రతి step లో ఒక normal cycle కనిపించేంత సమయం hold చేయండి. ముందటి stages సరిగా చేసినప్పుడు expansion boring గా ఉంటుంది. అదే goal.

fallbackలు మరియు failure behavior ను ఎలా ఎంచుకోవాలి

Evidence missing అయినప్పుడు లేదా evaluation run కాలేనప్పుడు ఏమి జరుగుతుందో ముందే నిర్ణయించండి.

• Fail open అంటే actor context లేకుండా request ఎలా proceed అవుతుందో అలాగే proceeds. Public pages, documentation మరియు read-only catalog endpoints వంటి low-risk routes కోసం దీన్ని use చేయండి.
• Fail closed అంటే మీ existing stronger check apply అవుతుంది, ఉదాహరణకు re-authentication లేదా review queue. మీరు అలాంటి check ఇప్పటికే ఉన్న high-impact actions కోసం దీన్ని use చేయండి.

Timeout లేదా error వల్ల ఎప్పుడూ Human result రావడానికి అనుమతించవద్దు. Missing evidence అంటే Unknown, మరియు Unknown route's fallback ను తీసుకుంటుంది. why Unknown is a valid result when classifying AI traffic పై మా 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 గా ఉండాలి. మీ team త్వరగా edit చేయగల store లో policies ను ఉంచండి, మరియు ఈ actions instant గా చేయండి:

1. Route ను తిరిగి preview కు set చేయండి, ఇది measurement ను కొనసాగిస్తూ enforcement ను ఆపుతుంది.
2. enforcePercent ను zero కు set చేయండి.
3. మిగతావాటిని తాకకుండా single rule ను disable చేయండి.

ప్రతి policy change ను ఎవరు చేశారు మరియు ఎప్పుడు చేశారో record చేయండి. Outcomes మారినప్పుడు, మొదటి ప్రశ్న ఎప్పుడూ ఏమి మారింది అనేదే.

మనుషుల గురించి consequential decisions ను నివారించండి

Actor classifications ఒక interaction గురించి ఉన్న evidence ను describe చేస్తాయి. అవి ఒక person గురించి judgment కాదు. ఎవరి employment, credit, education, housing లేదా essential services access ను ప్రభావితం చేసే decisions కోసం inferred class ను sole basis గా use చేయవద్దు. అలాంటి flows కోసం, outcome ను decide చేయడం కన్నా, ఉదాహరణకు human review కు routing చేయడం వంటి process ను ఎంచుకోవడానికి actor context ను use చేయండి.

enforce చేయడానికి ముందు communicate చేయండి

Automated clients ను ప్రభావితం చేసే policies వాటిని run చేసే people మరియు companies ను కూడా ప్రభావితం చేస్తాయి. కొద్దిపాటి communication చాలా support work ను నివారిస్తుంది:

1. Automated access కోసం మీ rules ను publish చేయండి. ఏ routes open గా ఉన్నాయో, ఏ limits వర్తిస్తాయో, మరియు signed requests ఉపయోగించి HTTP Message Signatures (RFC 9421) మరియు IETF Web Bot Auth protocol draft తో clients తమను తాము ఎలా identify చేసుకోవచ్చో state చేయండి.
2. Partners మరియు integrators కు ముందుగానే చెప్పండి. తెలిసిన integration preview సమయంలో restricted slice లోకి వస్తే, మీరు enforce చేసే ముందు దాని owner ను contact చేయండి.
3. ఉపయోగకరమైన responses ఇవ్వండి. Policy ఒక request ను limit లేదా challenge చేసినప్పుడు, స్పష్టమైన 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 ఇవ్వండి. Block అయిన request గురించి ticket వచ్చినప్పుడు, support engineering ను అడగకుండా route, class, basis మరియు policy decision ను lookup చేయగలగాలి.

Changes ను announce చేసి వాటిని explain చేసే teams quiet గా rules switch చేసిన teams కంటే చాలా తక్కువ surprises ను చూస్తాయి, మరియు adapt అయ్యే clients కాలక్రమంలో గుర్తించడం సులభమవుతాయి.

ప్రతి route కోసం ఒక checklist

• Class mix, Unknown rate మరియు outcomes కోసం baseline recorded.
• Explicit fallback తో data గా policy రాసారు.
• Preview run చేయబడింది, sample review చేయబడింది, false positive categories explain చేయబడ్డాయి.
• Metrics watch చేస్తూ చిన్న slice లో enforcement ప్రారంభించారు.
• Failure behavior ఎంచుకున్నారు: fail open లేదా fail closed.
• Expansion ముందు rollback పరీక్షించారు.

Proof of Actor ఎక్కడ సరిపోతుంది

Proof of Actor ఈ process చుట్టూ రూపకల్పన చేయబడింది. Observation default, ప్రతి result తన basis ను carry చేస్తుంది, మరియు Route policies ను మీరు మీ own code లో, route by route గా define చేసి enforce చేయవచ్చు. Detect, Understand, Route: అదే క్రమంలో.

మా team తో మీ own application పై rollout ను work through చేయడానికి, apply for early access. Decision flow ని end to end గా చూడడానికి, How Proof of Actor works చదవండి.

Sources

• RFC 6585: Additional HTTP Status Codes, Section 4: the 429 Too Many Requests status code
• RFC 9110: HTTP Semantics, Retry-After: క్లయింట్లకు మళ్లీ ఎప్పుడు ప్రయత్నించాలో చెప్పడం
• 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)