Actor-aware கொள்கைகளை பாதுகாப்பாக எப்படி வெளியிடுவது

Actor-aware கொள்கைகளை வெளியிடும் போது என்ன தவறு நடக்கலாம்?

ஒரு actor-aware policy, யார் அல்லது எது செயல்படுகிறது என்பதன் அடிப்படையில் உங்கள் application எப்படி பதிலளிக்கிறது என்பதை மாற்றுகிறது. சரியாக செய்தால், அது மக்களுக்கு மென்மையான அனுபவத்தை தருகிறது, சட்டபூர்வமான agents-க்கு கட்டமைக்கப்பட்ட பாதையை தருகிறது, மற்றும் முக்கியமான இடங்களில் மட்டுமே friction-ஐ சேர்க்கிறது. தவறாக செய்தால், அது உண்மையான பயனர்களைத் தடுக்கிறது, உங்கள் வாடிக்கையாளர்கள் நம்பும் integrations-ஐ உடைக்கிறது, மற்றும் யாரும் விளக்க முடியாத support tickets-ஐ உருவாக்குகிறது.

வித்தியாசம் பெரும்பாலும் policy logic-இல் இல்லை. அது rollout-இல் உள்ளது. (Policy model தானாக இருக்க, humans and AI agents-க்கான app-level policies-ஐ வடிவமைத்தல் என்பதைப் பார்க்கவும்.) இந்த வழிகாட்டி எந்த route-க்கும் team-கள் பின்பற்றக்கூடிய staged process-ஐ விவரிக்கிறது: observe, preview, ஒரு slice-க்கு enforce, பின்னர் விரிவுபடுத்து. ஒவ்வொரு நிலைக்கும் தெளிவான exit criterion மற்றும் விரைவாகத் திரும்பும் வழி உள்ளது.

மூன்று modes

ஒவ்வொரு policy-யையும் route ஒன்றுக்கு மூன்று modes-இல் ஒன்றில் இயங்குகிறது என்று நினைத்துக் கொள்ளுங்கள்:

• Observe. வகைப்பாடுகள் பதிவு செய்யப்படுகின்றன. அவை இல்லாதபோது application எப்படி பதிலளிக்குமோ அதேபோலவே பதிலளிக்கிறது.
• Preview. Policy மதிப்பாய்வு செய்யப்படுகிறது, அதன் decision பதிவு செய்யப்படுகிறது, ஆனால் apply செய்யப்படவில்லை. என்ன நடந்திருக்கும் என்பதை நீங்கள் பார்க்கலாம்.
• Enforce. Decision உண்மையான requests-க்கு apply செய்யப்படுகிறது.

Mode, முழு application-க்கு அல்ல, route மற்றும் policy ஜோடிக்கு உட்பட்டது. உங்கள் documentation pages enforce செய்யப்படலாம், ஆனால் உங்கள் checkout இன்னும் observe நிலையில் இருக்கலாம்.

படி 1: உங்கள் baseline தெரியும்வரை observe செய்யுங்கள்

ஒவ்வொரு route-உம் observe mode-இல் தொடங்குங்கள். குறைந்தபட்சமாக இதை சேகரிக்கவும்:

• route மற்றும் method,
• actor class (Human, Human + AI, Agent or Unknown) மற்றும் அதன் basis (verified, declared, inferred or unknown), application traffic-க்கான எங்கள் taxonomy-இல் வரையறுக்கப்பட்டபடி,
• response status மற்றும் route-க்கான ஒரு எளிய outcome marker, உதாரணமாக "account created" அல்லது "search returned results".

சாதாரண வாராந்திர சுழற்சிகள் மற்றும் அந்த காலத்தில் நீங்கள் வெளியிடும் எந்த release-உம் அடங்கும்வரை போதுமான அளவு நேரம் இயக்குங்கள். பின்னர் நீங்கள் கவனிக்கும் ஒவ்வொரு route-க்கும் உங்கள் baseline-ஐ எழுதிவையுங்கள்: class mix, Unknown rate, மற்றும் class ஒன்றுக்கு outcome rate. பின்னர் வரும் அனைத்தையும் இந்த எண்ணுகளுடன் ஒப்பிடுவீர்கள்.

Exit criterion: candidate route ஒவ்வொன்றிற்கும், அதை யார் பயன்படுத்துகிறார் மற்றும் class-ன் அடிப்படையில் outcomes எப்படி மாறுகின்றன என்பதை நீங்கள் விவரிக்க முடியும்.

படி 2: கொள்கையை data ஆக எழுதுங்கள்

Policies data ஆக இருக்கும் போது, if statements சிதறியிருப்பதை விட 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, timeouts, மற்றும் எந்த rule-ம் cover செய்யாத ஒவ்வொரு சூழலுக்கும் பயன்படுத்தப்படும் action. அதை deliberate-ஆக தேர்வு செய்வது முழு செயல்முறையிலேயே மிக முக்கியமான safety முடிவு.

படி 3: ஒரே இடத்தில் evaluate செய்யுங்கள்

ஒரே evaluation function, modes அனைத்திலும் behavior-ஐ ஒருமைப்படுத்துகிறது.

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 மாறுவதைப் பார்க்கவில்லை.

படி 4: enforce செய்வதற்கு முன் false positives-ஐ எப்படி அளவிடுவது?

ஒரு route-ஐ preview-க்கு மாற்றுங்கள். இப்போது ஒவ்வொரு request-மும் அதற்கு கிடைத்திருக்கக் கூடிய decision-ஐ பதிவு செய்கிறது. இங்கேயே policy சரியா என்பதை நீங்கள் கற்றுக்கொள்கிறீர்கள்.

False positive என்பது policy கட்டுப்படுத்தியிருக்கக் கூடிய ஆனால் அனுமதிக்கப்பட வேண்டிய request. Classification-களால் மட்டும் இதை அளவிட முடியாது, ஏனெனில் நீங்கள் சோதிப்பது classification தான். இது legitimate use-ன் independent signals-க்கு எதிராக அளவிடப்பட வேண்டும்:

• request ஒரு சாதாரண வெற்றிகரமான flow-ஐ முடித்தது, உதாரணமாக signed-in user வேலைகளைச் சேமித்தது,
• client ஒரு known partner integration அல்லது நீங்கள் சேவை செய்ய ஒப்புக்கொண்ட verified operator,
• support tickets அல்லது user reports பாதிக்கப்பட்ட route-ஐ குறிப்பிடுகின்றன,
• restrict செய்யப்படக்கூடிய requests மாதிரியின் manual review.

ஒரு sample-ஐ கைமுறையாக review செய்யுங்கள். Policy challenge செய்திருக்கும் இருபது உண்மையான requests-ஐப் படிப்பது, ஒரு rule மிக விரிவாக உள்ளதா என்பதை கண்டுபிடிக்கும் மிக வேகமான வழி.

Exit criterion: restriction பெற்றிருக்கக்கூடிய set-இல் நீங்கள் உண்மையாக restriction செய்ய விரும்பும் traffic ஆதிக்கம் செலுத்துகிறது, மேலும் நீங்கள் கண்டறிந்த false positive வகை ஒவ்வொன்றுக்கும் விளக்கம் உள்ளது.

படி 5: ஒரு slice-க்கு enforce செய்யுங்கள்

Route-ஐ ஒரு சிறிய enforcePercent உடன் 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-ஐ படிப்படியாக உயர்த்துங்கள், உதாரணமாக ஒரு சிறிய பங்கிலிருந்து quarter, பின்னர் half, பின்னர் அனைத்து traffic-உம் வரை, ஒவ்வொரு படியிலும் சாதாரண சுழற்சி தெரியும்வரை போதுமான நேரம் நிறுத்தி. முன் நிலைகள் நன்றாக செய்யப்பட்டிருந்தால் expansion சலிப்பானதாக இருக்கும். அதுவே இலக்கு.

Fallback-களையும் failure நடத்தையையும் தேர்வு செய்தல்

Evidence இல்லாதபோது அல்லது evaluation இயங்க முடியாதபோது என்ன நடக்கும் என்பதை முன்கூட்டியே முடிவு செய்யுங்கள்.

• Fail open என்பது request actor context இல்லாதபோது நடக்க வேண்டியபடி தொடர்வதை குறிக்கிறது. Public pages, documentation மற்றும் read-only catalog endpoints போன்ற குறைந்த ஆபத்து routes-க்கு இதைப் பயன்படுத்துங்கள்.
• Fail closed என்பது re-authentication அல்லது review queue போன்ற உங்கள் ஏற்கனவே உள்ள வலுவான check அமலுக்கு வருவதை குறிக்கிறது. அத்தகைய check ஏற்கனவே உள்ள உயர்ந்த தாக்கம் கொண்ட actions-க்கு இதைப் பயன்படுத்துங்கள்.

ஒரு timeout அல்லது error, Human result-ஐ உருவாக்க அனுமதிக்க வேண்டாம். Missing evidence என்பது Unknown, மேலும் Unknown route-ன் fallback-ஐ எடுத்துக்கொள்கிறது. AI traffic-ஐ வகைப்படுத்தும்போது Unknown ஏன் செல்லத்தக்க result என்பதைக் குறித்த எங்கள் பதிவு இந்த 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 மாற்றமாக இருக்க வேண்டும். உங்கள் team விரைவாகத் திருத்தக்கூடிய store-இல் policies-ஐ வைத்திருங்கள், மேலும் இந்த actions-ஐ உடனடியாக செய்யக்கூடியதாக மாற்றுங்கள்:

1. ஒரு route-ஐ மீண்டும் preview-க்கு அமைக்கவும், இது measurement-ஐ வைத்துக்கொண்டே enforcement-ஐ நிறுத்தும்.
2. enforcePercent-ஐ zero ஆக அமைக்கவும்.
3. மற்றவற்றைத் தொடாமல் ஒரே rule-ஐ disable செய்யவும்.

ஒவ்வொரு policy மாற்றத்தையும் அதை செய்தவர் யார், எப்போது என்று பதிவு செய்யுங்கள். Outcomes மாறும்போது, முதல் கேள்வி எப்போதும் என்ன மாறியது என்பதே.

மக்களைப் பற்றிய consequential decisions-ஐத் தவிர்க்கவும்

Actor classifications ஒரு interaction-ஐப் பற்றிய evidence-ஐ விவரிக்கின்றன. அவை ஒரு நபரைப் பற்றிய தீர்ப்பல்ல. ஒருவரின் வேலை, கடன், கல்வி, வீடு அல்லது அத்தியாவசிய சேவைகளுக்கான அணுகலை பாதிக்கும் முடிவுகளுக்கு inferred class-ஐ ஒரே அடிப்படையாகப் பயன்படுத்த வேண்டாம். அத்தகைய flows-க்கு, outcome-ஐ தீர்மானிப்பதற்குப் பதிலாக மனித review-க்கு route செய்வது போன்ற process-ஐத் தேர்வு செய்ய actor context-ஐப் பயன்படுத்துங்கள்.

enforce செய்வதற்கு முன் தொடர்பு கொள்ளுங்கள்

Automated clients-ஐ பாதிக்கும் policies, அவற்றை இயக்கும் people மற்றும் companies-ஐயும் பாதிக்கின்றன. கொஞ்சம் தொடர்பு கொண்டால் நிறைய support வேலை குறையும்:

1. Automated access-க்கான உங்கள் rules-ஐ வெளியிடுங்கள். எந்த routes open-ஆக உள்ளன, எந்த limits பொருந்துகின்றன, மற்றும் HTTP Message Signatures (RFC 9421) மற்றும் IETF Web Bot Auth protocol draft பயன்படுத்தி signed requests மூலம் clients தங்களை எப்படி அடையாளப்படுத்தலாம் என்பதைக் கூறுங்கள்.
2. Partners மற்றும் integrators-க்கு முன்கூட்டியே தெரிவியுங்கள். ஒரு known integration preview-இல் restricted slice-க்குள் விழுந்தால், நீங்கள் enforce செய்வதற்கு முன் அதன் owner-ஐத் தொடர்புகொள்ளுங்கள்.
3. பயனுள்ள responses-ஐத் திருப்பியுங்கள். ஒரு policy request-ஐ limit செய்யும் அல்லது challenge செய்யும் போது, 429 Too Many Requests with Retry-After போன்ற தெளிவான status code-உம், உங்கள் documentation-க்கு ஒரு link-உம் கொண்ட பதிலை வழங்குங்கள். Problem Details வடிவத்தில் இருக்கும் machine-readable body, automated clients-க்கு கட்டமைக்கப்பட்ட reason-ஐ அளிக்கிறது. நன்றாக கட்டமைக்கப்பட்ட agents ஏன் என்பதைப் புரிந்துகொள்ளும்போது தங்களை மாற்றிக்கொள்கின்றன.
4. உங்கள் support team-க்கு evidence-ஐ வழங்குங்கள். ஒரு blocked request பற்றிய ticket வந்தால், support-க்கு engineering-ஐக் கேட்காமல் route, class, basis மற்றும் policy decision-ஐப் பார்க்கும் திறன் இருக்க வேண்டும்.

மாற்றங்களை அறிவித்து, அவற்றை விளக்கும் teams, விதிகளை அமைதியாக மாற்றும் teams-ஐ விட மிகக் குறைந்த surprises-ஐப் பார்க்கின்றன, மேலும் adapt செய்யும் clients காலப்போக்கில் அடையாளம் காண எளிதாகின்றன.

ஒவ்வொரு route-க்கும் ஒரு checklist

• Class mix, Unknown rate மற்றும் outcomes-க்கு baseline பதிவு செய்யப்பட்டது.
• தெளிவான fallback உடன் policy data ஆக எழுதப்பட்டது.
• Preview இயக்கப்பட்டது, sample review செய்யப்பட்டது, false positive வகைகள் விளக்கப்பட்டன.
• Metrics கவனித்தபடி small slice-இல் enforcement தொடங்கப்பட்டது.
• Failure நடத்தை தேர்வு செய்யப்பட்டது: fail open அல்லது fail closed.
• Expansion-க்கு முன் rollback சோதிக்கப்பட்டது.

Proof of Actor எங்கு பொருந்துகிறது

Proof of Actor இந்த செயல்முறையை மையமாகக் கொண்டு வடிவமைக்கப்பட்டுள்ளது. Observation default, ஒவ்வொரு result-உம் அதன் basis-ஐ எடுத்துச் செல்கிறது, மேலும் Route policies-ஐ உங்கள் சொந்த code-இல் route-by-route வரையறுத்து enforce செய்வது உங்களுடையது. Detect, Understand, Route: அந்த வரிசையில்.

உங்கள் team-உடன் உங்கள் own application-இல் ஒரு rollout-ஐ செயல்படுத்த, early access-க்கு விண்ணப்பிக்கவும். Decision flow 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)