పోలిక

Proof of Actor vs user agent allowlists: పేరు ఒక దావా, proof కాదు

User-Agent string ద్వారా allowlisting చేయడం త్వరగా సెటప్ అవుతుంది, అర్థం చేసుకోవడం కూడా సులభం. కానీ header అనేది client పంపాలని ఎంచుకున్నదే కాబట్టి దాన్ని మోసం చేయడమూ సులభమే. user agent allowlist నిజంగా మీకు ఏమి చెబుతుందో, network checks ఎక్కడ సహాయపడతాయో, మరియు Proof of Actor declarations ను verified evidence నుండి ఎలా వేరు చేస్తుందో ఇక్కడ చూడండి.

తొందరగా యాక్సెస్ పొందండి ఇది ఎలా పనిచేస్తుందో అన్వేషించండి

రచన Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

చిన్న సమాధానం

ఒక user agent allowlist client తన User-Agent header లో పెట్టిన పేరునే నమ్ముతుంది, మరియు ఏ client అయినా ఏ పేరు అయినా టైప్ చేయగలదు. Reverse DNS మరియు published IP ranges కొంతమంది operators కోసం నిజమైన ఆధారాన్ని జోడిస్తాయి, కానీ వాటిని publish చేసే operatorsకే అది పరిమితం. Proof of Actor header ను ఒక declaration గా పరిగణిస్తుంది, agents తమ requests ను sign చేసిన చోట signatures ను తనిఖీ చేస్తుంది, మరియు ఆధారం తక్కువగా ఉన్నప్పుడు Unknown ను నివేదిస్తుంది, అందువల్ల మీ code ముందున్న facts ఆధారంగా నిర్ణయిస్తుంది.

user agent allowlist అనేది web లోని అత్యంత పాత patterns లో ఒకటి. మీరు నమ్మే crawler మరియు client పేర్ల జాబితాను ఉంచుతారు. ఒక request సరిపోలే User-Agent header తో వచ్చినప్పుడు, మీరు దాన్ని అనుమతిస్తారు, challenge ను దాటవేస్తారు, లేదా దానికి తేలికపాటి page ను అందిస్తారు. దీనిని సెటప్ చేయడానికి నిమిషాలే పడతాయి, మరియు team లోని అందరికీ ఇది అర్థమవుతుంది.

ప్రధాన automated visitors కొన్ని search crawlers మరియు కొన్ని monitoring tools మాత్రమే ఉన్నప్పుడు ఈ pattern మరింత అర్థవంతంగా ఉండేది. ఈరోజు AI agents, assistants, మరియు automated clients పెరుగుతున్న సంఖ్యలో applications కు చేరుతున్నాయి, మరియు వాటిలో చాలా తమ పేరు తామే ప్రకటిస్తాయి. ఆ పేర్లలో కొన్ని నిజమైనవి. కొన్ని కాపీలు. header ఏది నిజమో చెప్పలదు.

Proof of Actor వేరే విధంగా పనిచేస్తుంది. ఇది User-Agent string ను అది ఏదో అదే విధంగా, అంటే ఒక declaration గా, పరిగణించి, stronger evidence ఉన్నప్పుడు దానితో పాటు నివేదిస్తుంది. పేరు ఆధారంగా allowlisting చేయడంలో ఉన్న పరిమితులు ఏమిటో, network-level checks ఎక్కడ సహాయపడతాయో, మరియు verified signatures మరియు explicit Unknown class picture ను ఎలా మార్చుతాయో ఈ page వివరిస్తుంది.

సంక్షిప్తంగా

	User agent allowlist	Proof of Actor
ప్రధాన evidence	User-Agent header లోని పేరు	Signatures, declarations and signals, each labeled with its basis
client దీన్ని fake చేయగలదా?	అవును, అదే string పంపడం ద్వారా	declared basis ను claim చేయవచ్చు; verified basis కు signing key కావాలి
అవుట్‌పుట్	జాబితాలో ఉందా లేదా	Human, Human + AI, Agent or Unknown, plus a basis
స్పష్టంగా లేని traffic	allowlisted గా పరిగణించరు, లేదా default గా అనుమతిస్తారు	Unknown, ప్రతి route కి మీరు ఎంచుకునే fallback తో
AI సహాయంతో పనిచేసే people	కనిపించరు; వారు సాధారణ browsers వాడతారు	declared లేదా observed అయినప్పుడు ప్రత్యేక class, Human + AI
నిర్వహణ	పేర్లు మారినప్పుడు manual list updates	agent operators ప్రచురించే keys; మీ code లో policies
install చేసినప్పుడు default	జాబితా అనుమతించినది ఏదైతే అది	Observation; మీరు policy జోడించే వరకు ఏమీ మారదు
ఏ విషయంలో ఉత్తమం	well-behaved, తెలిసిన clients కు చౌక routing	product మరియు policy నిర్ణయాల కోసం evidence-based actor context

మిగతా page లో ప్రతి row ను వివరించాం.

User-Agent ద్వారా allowlisting ఎందుకు spoof చేయవచ్చు

User-Agent header ను client సెట్ చేస్తుంది. ఒక browser దాన్ని సెట్ చేస్తుంది, ఒక script దాన్ని సెట్ చేస్తుంది, ఒక agent framework దాన్ని సెట్ చేస్తుంది. HTTP లో ఆ value నిజమా కాదా అని తనిఖీ చేసే ఏదీ లేదు. మీ allowlist ఒక string ను నమ్మితే, అదే string ను కాపీ చేసే ఎవరికైనా అదే treatment లభిస్తుంది.

దీనిని user agent spoofing అంటారు, మరియు ఇది ఒక సరళమైన కారణం వల్ల సాధారణం: దీనికి ఖర్చు లేదు. ఒక challenge ను తప్పించుకోవాలనుకునే scraper, మీరు నమ్మే crawler పేరు మాత్రమే borrow చేయాలి. చెడు ప్రవర్తన గల client తాను ఒక popular assistant అని చెప్పుకోవచ్చు. ఒక legitimate tool కూడా ఒక generic browser string పంపవచ్చు, ఎందుకంటే library default అలా చేసింది.

ఫలితంగా user agent allowlist కు రెండు failure modes ఉంటాయి:

False trust: నమ్మదగని client trusted పేరు claim చేసి pass అవుతుంది.
False doubt: legitimate client unexpected లేదా generic string పంపి fail అవుతుంది.

Header ఒక్కటే చూసి ఈ రెండు failure modes ఏవీ కనిపించవు. ఇదే ప్రధాన పరిమితి, మరియు list maintenance ఎంత చేసినా దాన్ని తొలగించలేరు.

ఇది User-Agent strings ను పట్టించుకోకూడదని అర్థం కాదు. మంచి ప్రవర్తన ఉన్న crawlers మరియు agents నిజాయితీగా తమను తాము ప్రకటిస్తాయి, మరియు ఆ పేరు routing, analytics, debugging కోసం ఉపయోగకరమైన సంకేతం. client తాను ఏమిటని చెబుతోందో అది మీకు చెబుతుంది.

ఆ సమాచారానికి సరైన స్థానం declaration గా, ఇతర evidence తో పాటు weigh చేయబడే విధంగా ఉండాలి, access ను తానే unlock చేసే key గా కాదు. Proof of Actor దాన్ని exactly ఆ విధంగానే నమోదు చేస్తుంది.

Reverse DNS మరియు IP జాబితాలు: భాగిక చర్యలు

చాలా teams తమ allowlist ను network checks తో బలోపేతం చేస్తాయి. అవి సహాయపడతాయి, మరియు వాటిని ఖచ్చితంగా అర్థం చేసుకోవడం విలువైనది.

Reverse DNS verification

కొన్ని crawler operators ఒక verification process ను document చేస్తారు: request యొక్క IP address కోసం hostname lookup చేయండి, అది operator domain కు చెందిందని check చేయండి, తరువాత ఆ hostname ను lookup చేసి అదే IP కి తిరిగి resolve అవుతుందో లేదో నిర్ధారించండి. ఈ round trip విజయవంతమైతే, request operator infrastructure నుంచే వచ్చిందని మీకు నిజమైన ఆధారం ఉంటుంది.

దీనికి పరిమితులు practical గా ఉంటాయి. దీనిని document చేసి support చేసే operators కోసం మాత్రమే ఇది పనిచేస్తుంది. Cache చేయాల్సిన DNS lookups ను ఇది జోడిస్తుంది. ఇంకా, ఆ network మీద ఏ product లేదా agent request చేసింది అన్నది కాదు, network గురించి మాత్రమే ఇది చెబుతుంది.

Published IP ranges

ఇతర operators తమ automated clients ఉపయోగించే IP ranges ను publish చేస్తారు. ఒక request ను ఆ ranges తో match చేయడం వేగంగా ఉంటుంది, మరియు reverse DNS కు సమానమైన evidence ఇస్తుంది. ఈ ranges ను publish చేయడానికి standard format పై IETF లో ongoing discussion ఉంది, కానీ November 2026 నాటికి settled standard లేదు, మరియు coverage ప్రతి operator publish చేయాలని ఎంచుకోవడంపై ఆధారపడి ఉంటుంది.

ఇంకా ఎక్కువ agents shared cloud infrastructure మీద, proxies వెనుక, లేదా user యొక్క own device నుండి నడుస్తున్న కొద్దీ IP evidence బలహీనమవుతుంది. ఒక cloud address అనేక unrelated clients ను host చేయగలదు, మరియు ఒక person browser నుండి పనిచేస్తున్న agent ఆ person network లానే కనిపిస్తుంది.

network checks మొత్తం ఏమి ఇస్తాయి

Reverse DNS మరియు IP lists కొంతమంది well-known operators కోసం కొన్ని declarations ను మరింత బలమైనదిగా మార్చుతాయి. అవి agents మరియు tools యొక్క long tail ను కవర్ చేయవు, మరియు AI తో కలిసి పనిచేసే people విషయంలో ఏమాత్రం సహాయపడవు. అవి భాగిక చర్యలు: ఉపయోగించదగినవి, కానీ ఒక్కటే సరిపోవు.

Signatures versus declarations

Evidence యొక్క మరింత బలమైన రూపం ఒక cryptographic signature. HTTP Message Signatures తో, RFC 9421 లో నిర్వచించినట్లుగా, ఒక client ప్రతి request లోని ఎంచుకున్న భాగాలను private key తో sign చేస్తుంది. verifier operator యొక్క published public key ను fetch చేసి signature ను తనిఖీ చేస్తుంది. అది verify అయితే, request ఆ key holder చేత sign చేయబడింది, మరియు signed parts మారలేదు.

IETF Web Bot Auth working group automated clients ఈ signatures ను ఎలా use చేస్తారో, మరియు వారు తమ keys ను ఎలా publish చేస్తారో standardize చేస్తోంది. మా Web Bot Auth for product teams explainer ప్రస్తుత స్థితిని కవర్ చేస్తుంది.

Proof of Actor సరైన signature ను verified evidence గా ఉపయోగిస్తుంది. User-Agent string, client hint, లేదా request body లోని self-description declared గా పరిగణించబడుతుంది. behavioral మరియు contextual signals inferred గా పరిగణించబడతాయి, మరియు అలాగే label చేయబడతాయి. ప్రతి result ఏ basis మీద నిలిచిందో చెబుతుంది, కాబట్టి మీ team claim ను check తో ఎప్పుడూ గందరగోళం చేయదు. పూర్తిస్థాయి నిర్వచనాల కోసం evidence basis entry చూడండి.

verified evidence కి కూడా ఒక పరిమితి ఉంటుంది. సరైన signature request ను ఏ key sign చేసిందో నిరూపిస్తుంది. అది agent అడుగుతున్న పని చేయడానికి అనుమతి ఉందని నిరూపించదు. అది ఒక agent authorization ప్రశ్న, మరియు అది మీ application లోనే ఉంటుంది.

ఊహించకుండా Unknown ను నిర్వహించడం

Allowlist ప్రతి request ను రెండు bucket లలో ఒకదానిలోకి నెట్టేస్తుంది: list లో ఉంది లేదా లేదు. ప్రాక్టీస్‌లో దీని అర్థం స్పష్టంగా లేని traffic కి మీ default ఏదైతే అది వర్తిస్తుంది, మరియు default సాధారణంగా మొత్తం site కు ఒకసారే ఎంచుకుంటారు.

Proof of Actor Unknown ను first-class result గా పరిగణిస్తుంది. evidence నమ్మదగిన determination ను support చేయనప్పుడు, అది ఊహించకుండా అలా చెబుతుంది. తరువాత మీ policies ప్రతి route లో Unknown అంటే ఏమిటో నిర్ణయిస్తాయి:

public documentation లేదా marketing pages పై, దాన్ని allow చేయండి.
search లేదా listing endpoints పై, మీ సాధారణ rate limits తో allow చేయండి.
account changes పై, మీ existing checks ను కొనసాగించండి.
high-impact actions పై, దాన్ని review కు పంపండి లేదా stronger signal అడగండి.

handling Unknown traffic guide మరియు unknown classification entry patterns ను దశలవారీగా చూపిస్తాయి. కాలక్రమంలో మీ Unknown rate ను track చేయడం కూడా మీ traffic లో ఎంత భాగం ఇంకా బలహీనమైన evidence మీద ఆధారపడి ఉందో చెబుతుంది.

AI సహాయంతో పనిచేసే people గురించి ఏమిటి?

ఒక సాధారణ browser లో AI assistant ను ఉపయోగించే person గురించి చెప్పడానికి user agent allowlist వద్ద ఏమీ లేదు. వారి User-Agent సాధారణ browser string. అయినా అనేక products ఆ interaction ను గుర్తించాలని కోరుకుంటాయి, ఉదాహరణకు AI-drafted submissions ను label చేయడానికి లేదా AI-assisted users onboarding లో ఎలా కదులుతున్నారో అర్థం చేసుకోవడానికి.

Proof of Actor ఈ interactions ను Human + AI గా నివేదిస్తుంది, ఆ assistance declared గా లేదా supported integration ద్వారా observed అయినప్పుడు. ఇది writing style నుంచే ఊహించదు. మరింత తెలుసుకోవడానికి AI-assisted interaction చదవండి.

allowlist నుండి evidence-based policies వైపు వెళ్లడం

Day one లోనే మీ allowlist ను తొలగించాల్సిన అవసరం లేదు. సురక్షితమైన మార్గం ఇలా ఉంటుంది:

Observation mode లో install చేయండి. Proof of Actor ఏమీ మార్చదు. మీ allowlist పనిచేస్తూనే ఉంటుంది.
పోల్చండి. ప్రతి route కోసం, ఏ allowlisted requests verified evidence ను కలిగి ఉన్నాయో, ఏవి కేవలం declaration మాత్రమే కలిగి ఉన్నాయో, మరియు ఏవి చివరికి Unknown లో పడుతున్నాయో చూడండి.
Policies preview చేయండి. verified agents, declared agents, మరియు Unknown ను వేర్వేరుగా చూసే policy ని draft చేసి, నిజమైన traffic పై దాని ప్రభావాన్ని preview చేయండి.
Route by route గా enforce చేయండి. spoof చేసిన పేరు అత్యంత కీలకంగా ప్రభావితం చేసే routes తో ప్రారంభించండి.
Allowlist ను hint గా ఉంచండి. పేర్లు ఇంకా routing మరియు analytics కోసం ఉపయోగపడతాయి, ఇప్పుడు వాటి basis visible గా ఉంటుంది.

rolling out actor-aware policies safely guide ప్రతి దశను కవర్ చేస్తుంది, మరియు verified automated requests signed clients ఎలా fit అవుతారో వివరిస్తుంది.

allowlist ఎప్పుడు చాలుతుంది

Public content పై తెలిసిన crawler కు తేలికపాటి page అందించడం వంటి low-stakes routing కోసం, ఒక user agent allowlist చాలాసార్లు సరిపోతుంది. spoof చేసిన పేరు వల్ల వచ్చే ఖర్చు చిన్నదే.

Decision కు consequences ఉన్నప్పుడు, ఉదాహరణకు challenge ను skip చేయడం, richer data ను expose చేయడం, లేదా write ను allow చేయడం వంటి సందర్భాల్లో, మీరు తనిఖీ చేయగల evidence కావాలి. ఇదే Proof of Actor స్థానం, మీరు ఇప్పటికే నడుపుతున్న network checks మరియు edge controls తో కలిసి పనిచేస్తూ.

ప్రారంభించండి

Proof of Actor private beta లో ఉంది. ఎంపికైన founding developer teams కి agreed usage limits లోపల, automatic billing లేకుండా, 12 months వరకు free access లభించవచ్చు. early access కోసం apply చేయండి మరియు మీరు ఈరోజు ఏ clients ను allowlist చేస్తున్నారో, అలాగే మరింత మంచి evidence తో ఏ routes ను protect చేయాలనుకుంటున్నారో మాకు చెప్పండి.

డెవలపర్ల కోసం

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent లేదా Unknown.
basis: evidence ఎంత బలంగా ఉందో: verified, declared, inferred లేదా unknown.
evidence: result వెనుక ఉన్న signals, అందువల్ల మీ team ఎందుకు అని చూడగలదు.

observation mode లో ప్రారంభించండి: results ను మీ logs పక్కనే నమోదు చేయండి మరియు మీరు ఒక policy ఎంచుకునే వరకు ఏమీ మార్చవద్దు. Node.js integration guide ను చదవండి

తరచుగా అడిగే ప్రశ్నలు

user agent allowlist ఉపయోగం లేనిదా?

లేదు. మంచి ప్రవర్తన ఉన్న clients నుండి వచ్చిన useful declaration అది, అలాగే తెలిసిన crawlers ను route చేయడానికి తక్కువ ఖర్చుతో కూడిన మార్గం. సమస్య దాన్ని proof గా భావించడంలో ఉంది. ఏ client అయినా ఏ User-Agent string అయినా పంపగలదు, కాబట్టి allowlist ఒక్కటే sensitive actions ను ఎప్పుడూ unlock చేయకూడదు.

Reverse DNS verification User-Agent spoofing ను సరిచేస్తుందా?

దాన్ని document చేసిన operators కోసం అది సహాయపడుతుంది. IP address కి reverse lookup చేసి, తరువాత matching forward lookup చేయడం ద్వారా ఆ IP address ను operator domain తో కలుపుతుంది. ఇది support చేసే operatorsకే పనిచేస్తుంది, అలాగే shared cloud లేదా residential addresses నుండి వచ్చే traffic గురించి ఏమి చెప్పదు.

Proof of Actor User-Agent header ను ఎలా పరిగణిస్తుంది?

ఒక declaration గా. అది result కు declared basis తో దోహదం చేస్తుంది, verified one గా కాదు. verified basis కు published key against checked చేసిన HTTP Message Signature వంటి evidence కావాలి.

verified signature ఏమి నిరూపిస్తుంది?

request ను ఏ key sign చేసిందో, అలాగే signed parts మారలేదో అది నిరూపిస్తుంది. ఆ agent ఆ action చేయడానికి authorized అని అది నిరూపించదు. authorization మీ application లోనే ఉంటుంది.

known agent అని చెప్పి verify చేయలేని clients కి ఏమవుతుంది?

Proof of Actor evidence support చేసేదాన్ని నివేదిస్తుంది, తరచుగా declared లేదా inferred result ను, లేక Unknown ను. claimed name మీద నమ్మకం పెట్టకుండా ఆ route కోసం fallback ఏదో మీ policy ఎంచుకుంటుంది.

Proof of Actor నా ప్రస్తుత allowlist behavior ను మారుస్తుందా?

లేదు. ఇది observation mode లో ప్రారంభమవుతుంది. ఏదైనా మార్చే ముందు నిజమైన traffic మీద మీ allowlist decisions తో దాని results ను పోల్చుకోవచ్చు.

మీ app ను ఎవరు ఉపయోగిస్తున్నారో తెలుసుకోండి.

founding developers యొక్క చిన్న group కోసం private beta.

తొందరగా యాక్సెస్ పొందండి ధరలను చూడండి

ముందుగా మాట్లాడాలనుకుంటున్నారా? foundersతో మాట్లాడండి