ஒப்பீடு

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-மும் எந்தப் பெயரையும் type செய்ய முடியும். Reverse DNS மற்றும் published IP ranges சில operators-க்கு உண்மையான ஆதாரத்தை சேர்க்கின்றன, ஆனால் அவற்றை வெளியிடும் operators-க்கு மட்டுமே. Proof of Actor அந்த header-ஐ ஒரு declaration ஆகக் கருதி, agents தங்கள் requests-ஐ sign செய்யும் இடங்களில் signatures-ஐ சரிபார்க்கிறது, மேலும் ஆதாரம் குறைவாக இருக்கும்போது Unknown-ஐ report செய்கிறது, அதனால் facts கண்ணில் இருக்கும்போதே உங்கள் code முடிவெடுக்கிறது.

User agent allowlist என்பது web-இன் மிகப் பழைய patterns-இல் ஒன்று. நீங்கள் நம்பும் crawler மற்றும் client names பட்டியலை வைத்திருக்கிறீர்கள். ஒரு request matching User-Agent header-உடன் வந்தால், அதை pass செய்யலாம், ஒரு challenge-ஐ skip செய்யலாம், அல்லது அதற்கு lighter page-ஐ serve செய்யலாம். இதை அமைக்க சில நிமிடங்கள் போதும், மேலும் குழுவில் உள்ள அனைவருக்கும் இது புரியும்.

இந்த pattern, முக்கியமான automated visitors சில search crawlers மற்றும் சில monitoring tools மட்டுமே இருந்த காலத்தில் அதிக அர்த்தம் கொண்டது. இன்று, AI agents, assistants மற்றும் automated clients applications-ஐ அதிக எண்ணிக்கையில் அணுகுகின்றன, மேலும் அவற்றில் பல தங்களை ஒரு பெயருடன் அறிவிக்கின்றன. அந்த பெயர்களில் சில உண்மையானவை. சில நகலெடுக்கப்பட்டவை. header மட்டும் அவற்றில் எது என்பதை சொல்லாது.

Proof of Actor வேறு அணுகுமுறையை எடுக்கிறது. அது ஒரு User-Agent string-ஐ அது என்னவோ அதேபடி, அதாவது ஒரு declaration ஆகக் கருதி, வலுவான evidence இருந்தால் அதனுடன் சேர்த்து report செய்கிறது. இந்த பக்கம், பெயர் அடிப்படையிலான allowlisting-ன் வரம்புகள், network-level checks எங்கு உதவுகின்றன, மேலும் verified signatures மற்றும் வெளிப்படையான Unknown வகுப்பு எவ்வாறு சூழலை மாற்றுகின்றன என்பதைக் விளக்குகிறது.

சுருக்கமான பதிப்பு

	User agent allowlist	Proof of Actor
முக்கிய ஆதாரம்	User-Agent header-இல் ஒரு பெயர்	Signatures, declarations மற்றும் signals, ஒவ்வொன்றும் அதன் basis-உடன் label செய்யப்பட்டவை
Client போலியாக உருவாக்க முடியுமா?	ஆம், அதே string-ஐ அனுப்புவதன் மூலம்	ஒரு declared basis-ஐ கூறிக்கொள்ளலாம்; ஒரு verified basis-க்கு signing key தேவை
வெளியீடு	பட்டியலில் உள்ளதா இல்லையா	Human, Human + AI, Agent அல்லது Unknown, மேலும் ஒரு basis
தெளிவில்லாத traffic	allowlist-இல் இல்லை எனக் கருதப்படும், அல்லது default-ஆக அனுமதிக்கப்படும்	Unknown, route ஒன்றுக்கு நீங்கள் தேர்வு செய்யும் fallback-உடன்
AI உதவியுடன் செயல்படும் மக்கள்	தெரியாது; அவர்கள் சாதாரண browsers-ஐ பயன்படுத்துகிறார்கள்	distinct வகுப்பு, Human + AI, declared அல்லது observed ஆக இருந்தால்
பராமரிப்பு	பெயர்கள் மாறும்போது manual list updates	agent operators வெளியிடும் keys; உங்கள் code-இல் policies
Install செய்யும் போது default	list அனுமதிப்பது எதுவோ அது	Observation; நீங்கள் policy சேர்க்கும் வரை எதுவும் மாறாது
சிறந்தது	நன்றாக நடந்துகொள்ளும், தெரிந்த clients-ஐ குறைந்த செலவில் route செய்வது	product மற்றும் policy decisions-க்கு evidence அடிப்படையிலான actor context

மீதமுள்ள பக்கம் ஒவ்வொரு வரியையும் விளக்குகிறது.

User-Agent அடிப்படையில் allowlisting ஏன் spoof செய்யக்கூடியது

User-Agent header client-ஆல் அமைக்கப்படுகிறது. ஒரு browser அதை அமைக்கிறது, ஒரு script அதை அமைக்கிறது, ஒரு agent framework அதை அமைக்கிறது. HTTP-இல் அந்த value உண்மைதானா என்பதைச் சரிபார்க்க எதுவும் இல்லை. உங்கள் allowlist ஒரு string-ஐ நம்பினால், அந்த string-ஐ நகலெடுப்பவர் யாராக இருந்தாலும் அதே treatment-ஐ பெறுவார்.

இதையே user agent spoofing என்று அழைக்கிறார்கள், மேலும் இது ஒரு எளிய காரணத்தால் பொதுவானது: இதற்கு எந்தச் செலவும் இல்லை. நீங்கள் நம்பும் crawler-ன் பெயரை கடன் வாங்கினால் போதும், ஒரு scraper ஒரு challenge-ஐத் தவிர்க்க முடியும். நடத்தை தவறான client ஒரு பிரபல assistant என்று கூறிக்கொள்ள முடியும். ஒரு library default காரணமாக ஒரு legitimate tool கூட generic browser string-ஐ அனுப்பலாம்.

இதன் விளைவு, ஒரு user agent allowlist-க்கு இரண்டு failure modes இருப்பதாகும்:

False trust: நம்பப்படாத client ஒரு trusted பெயரை கூறி pass ஆகிறது.
False doubt: ஒரு legitimate client எதிர்பாராத அல்லது generic string-ஐ அனுப்பி fail ஆகிறது.

இந்த failure-களில் எதுவும் header மட்டும் பார்த்து தெரியாது. அதுதான் முக்கியமான வரம்பு, மேலும் list maintenance-ன் எந்த அளவும் அதை நீக்காது.

இதனால் User-Agent strings-ஐ புறக்கணிக்க வேண்டும் என்பதில்லை. நன்றாக நடந்துகொள்ளும் crawlers மற்றும் agents தங்களை நேர்மையாக அறிவிக்கின்றன, மேலும் அந்தப் பெயர் routing, analytics மற்றும் debugging-க்கு ஒரு பயனுள்ள hint ஆகும். ஒரு client அது என்ன எனக் கூறுகிறது என்பதை அது சொல்கிறது.

அந்த தகவலை பயன்படுத்த வேண்டிய சரியான இடம், access-ஐ தனித்து திறக்கும் key ஆக அல்ல, பிற ஆதாரங்களுடன் சேர்த்து மதிப்பிடப்படும் ஒரு declaration ஆகும். Proof of Actor அதை exactly அதேபடி பதிவு செய்கிறது.

Reverse DNS மற்றும் IP lists: பகுதி அளவிலான measures

பல teams network checks-ஐ பயன்படுத்தி ஒரு allowlist-ஐ வலுப்படுத்துகின்றன. அவை உதவுகின்றன, மேலும் அவற்றை துல்லியமாகப் புரிந்துகொள்வது மதிப்புடையது.

Reverse DNS verification

சில crawler operators ஒரு verification process-ஐ ஆவணப்படுத்துகிறார்கள்: request-இன் IP address-க்கு hostname-ஐ lookup செய்யுங்கள், அது operator-ன் domain-க்கு சேர்ந்ததா எனச் சரிபாருங்கள், பின்னர் அந்த hostname-ஐ lookup செய்து அது அதே IP-க்கு மீண்டும் resolve ஆகிறதா என உறுதிசெய்யுங்கள். இந்த round trip வெற்றி பெற்றால், request operator-ன் infrastructure-இலிருந்தே வந்தது என்பதற்கான உண்மையான ஆதாரம் உங்களிடம் இருக்கும்.

இதன் வரம்புகள் நடைமுறையானவை. இது documentation செய்து support செய்யும் operators-க்கு மட்டுமே வேலை செய்யும். நீங்கள் cache செய்ய வேண்டிய DNS lookups-ஐ இது சேர்க்கிறது. மேலும் இது network பற்றி சொல்கிறது, அந்த network-இல் request-ஐ எந்த product அல்லது agent உருவாக்கியது என்பதைப் பற்றி அல்ல.

Published IP ranges

மற்ற operators, தங்கள் automated clients பயன்படுத்தும் IP ranges-ஐ வெளியிடுகிறார்கள். ஒரு request-ஐ அந்த ranges-உடன் பொருத்துவது வேகமானது, மேலும் reverse DNS-க்கு ஒத்த evidence-ஐ வழங்குகிறது. published IP ranges-ஐ standard format-இல் வெளியிடுவது குறித்து IETF-இல் தொடர்ந்து விவாதம் நடக்கிறது, ஆனால் November 2026 நிலவரப்படி நிலையான standard எதுவும் இல்லை, மேலும் coverage ஒவ்வொரு operator-மும் வெளியிடத் தேர்வு செய்வதில்தான் சார்ந்திருக்கிறது.

மேலும் agents shared cloud infrastructure-இல், proxies-க்கு பின்னால், அல்லது ஒரு user-ன் சொந்த சாதனத்திலிருந்து இயங்கும் போது IP evidence பலவீனமாகிறது. ஒரு cloud address பல unrelated clients-ஐ நடத்த முடியும், மேலும் ஒரு person-ன் browser-இலிருந்து செயல்படும் ஒரு agent அந்த person-ன் network போலவே தெரியும்.

Network checks சேர்ந்து என்ன அளிக்கின்றன

Reverse DNS மற்றும் IP lists, சில declarations-ஐ, தெரிந்த operators-ன் ஒரு subset-க்கு stronger ஒன்றாக மாற்றுகின்றன. அவை agents மற்றும் tools-ன் நீண்ட tail-ஐ cover செய்யாது, மேலும் AI உடன் வேலை செய்யும் மக்களுக்கு அவை முற்றிலும் உதவாது. அவை பகுதி அளவிலான measures: பயன்படுத்தத் தகுந்தவை, ஆனால் தனித்தனியாக போதாது.

Signatures versus declarations

ஆதாரத்தின் வலுவான வடிவம் ஒரு cryptographic signature. HTTP Message Signatures, RFC 9421-இல் வரையறுக்கப்பட்டவை, மூலம் ஒரு client ஒவ்வொரு request-இன் தேர்ந்தெடுக்கப்பட்ட பகுதிகளை private key-யுடன் sign செய்கிறது. Verifier operator-ன் published public key-ஐ fetch செய்து signature-ஐச் சரிபார்க்கிறது. அது verify ஆனால், request-ஐ அந்த key-ஐ வைத்திருக்கும் நபர் sign செய்துள்ளார், மேலும் வழியில் signed பகுதிகள் மாற்றப்படவில்லை.

IETF Web Bot Auth working group, automated clients இந்த signatures-ஐ எவ்வாறு பயன்படுத்துகின்றன மற்றும் தங்கள் keys-ஐ எவ்வாறு publish செய்கின்றன என்பதைக் standardize செய்து வருகிறது. product teams-க்கான Web Bot Auth பற்றிய எங்கள் விளக்கக்குறிப்பு தற்போதைய நிலையைக் கூறுகிறது.

Proof of Actor, செல்லுபடியாகும் signature-ஐ verified evidence ஆகப் பயன்படுத்துகிறது. User-Agent string, client hint, அல்லது request body-இல் உள்ள self-description ஆகியவை declared ஆகக் கருதப்படும். நடத்தை சார்ந்த மற்றும் சூழல் சார்ந்த signals inferred ஆகக் கருதப்படும், மேலும் அதேபடி label செய்யப்படும். ஒவ்வொரு result-மும் அது எந்த basis-ஐ அடிப்படையாகக் கொண்டது என்பதைத் தெரிவிக்கும், அதனால் உங்கள் team ஒரு கோரிக்கையையும் ஒரு சரிபார்ப்பையும் குழப்பாது. முழு வரையறைகளுக்கு evidence basis entry-ஐப் பார்க்கவும்.

Verified evidence-க்குக்கூட ஒரு வரம்பு உண்டு. செல்லுபடியாகும் signature request-ஐ எந்த key sign செய்தது என்பதை proof செய்கிறது. கேட்கும் செயலை செய்ய அந்த agent-க்கு அனுமதி உள்ளதா என்பதை அது proof செய்யாது. அது ஒரு agent authorization கேள்வி, மேலும் அது உங்கள் application-இலேயே இருக்கும்.

ஊகிப்பதற்குப் பதிலாக Unknown-ஐ கையாளுதல்

ஒரு allowlist ஒவ்வொரு request-ஐயும் இரண்டு bucket-களில் ஒன்றில் வைக்கிறது: பட்டியலில் உள்ளதா அல்லது இல்லையா. நடைமுறையில் இதன் பொருள், தெளிவில்லாத traffic-க்கு உங்கள் default என்னவோ அதுவே பொருந்தும், மேலும் அந்த default பொதுவாக முழு site-க்காக ஒருமுறை தேர்வு செய்யப்படுகிறது.

Proof of Actor, Unknown-ஐ முதல் தர முடிவாகக் கருதுகிறது. Evidence நம்பகமான determination-ஐ ஆதரிக்காதபோது, அது ஊகிப்பதற்குப் பதிலாக அதைக் கூறுகிறது. பின்னர் உங்கள் policies ஒவ்வொரு route-இலும் Unknown என்பதன் அர்த்தத்தைத் தீர்மானிக்கின்றன:

பொது documentation அல்லது marketing pages-இல், அதை அனுமதிக்கவும்.
search அல்லது listing endpoints-இல், உங்கள் சாதாரண rate limits-உடன் அதை அனுமதிக்கவும்.
account மாற்றங்களில், உங்கள் தற்போதைய checks-ஐ வைத்திருங்கள்.
அதிக தாக்கம் உள்ள actions-இல், அதை review-க்கு அனுப்பவும் அல்லது வலுவான signal-ஐ கோரவும்.

handling Unknown traffic பற்றிய guide மற்றும் unknown classification entry pattern-களை விளக்குகின்றன. காலப்போக்கில் உங்கள் Unknown rate-ஐ கண்காணிப்பது, உங்கள் traffic-இன் எவ்வளவு பகுதி இன்னும் பலவீனமான ஆதாரத்தில் தங்கியுள்ளது என்பதையும் சொல்கிறது.

AI உதவியுடன் செயல்படும் மக்கள் பற்றிச் சொல்லவேண்டுமா?

ஒரு user agent allowlist, சாதாரண browser-இல் AI assistant-ஐ பயன்படுத்தும் ஒரு person பற்றி எதையும் சொல்லாது. அவர்களின் User-Agent ஒரு சாதாரண browser string. ஆனாலும் பல products அந்த interaction-ஐ அடையாளம் காண விரும்புகின்றன, எடுத்துக்காட்டாக AI-யில் உருவாக்கப்பட்ட submissions-ஐ label செய்ய அல்லது onboarding-இல் AI உதவியுள்ள users எப்படிச் செல்கிறார்கள் என்பதைப் புரிந்துகொள்ள.

Supported integration மூலம் assistance declared அல்லது observed ஆக இருந்தால், Proof of Actor இந்த interactions-ஐ Human + AI ஆக report செய்கிறது. எழுத்து பாணி மட்டும் பார்த்து அது ஊகிக்காது. மேலும் விவரங்களுக்கு AI-assisted interaction-ஐப் பார்க்கவும்.

Allowlist-இலிருந்து evidence-based policies-க்கு நகர்தல்

Day one-இல் உங்கள் allowlist-ஐ நீக்க வேண்டிய அவசியமில்லை. பாதுகாப்பான வழி இதுபோல இருக்கும்:

Observation mode-இல் நிறுவுங்கள். 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 செய்யுங்கள். போலியாகக் கூறப்பட்ட பெயர் மிக அதிக முக்கியத்துவம் வாய்ந்த routes-இலிருந்து தொடங்குங்கள்.
Allowlist-ஐ ஒரு hint ஆக வைத்திருங்கள். பெயர்கள் routing மற்றும் analytics-க்கு இன்னும் பயனுள்ளதாகவே இருக்கும், இப்போது அவற்றின் basis தெரியும்.

actor-aware policies-ஐ பாதுகாப்பாக rollout செய்வது பற்றிய guide ஒவ்வொரு படியையும் cover செய்கிறது, மேலும் verified automated requests signed clients இதில் எப்படி பொருந்துகிறார்கள் என்பதை விளக்குகிறது.

Allowlist போதுமானதாக இருக்கும் போது

அடிக்கடி குறைந்த ஆபத்து உள்ள routing-க்கு, உதாரணமாக public content-இல் தெரிந்த crawler-க்கு lighter page-ஐ வழங்குவது போன்ற சூழலில், ஒரு user agent allowlist பெரும்பாலும் சரி. போலியாகக் கூறப்பட்ட பெயரின் செலவு குறைவு.

தீர்மானத்துக்கு விளைவுகள் உள்ளபோது, உதாரணமாக ஒரு challenge-ஐத் தவிர்ப்பது, richer data-ஐ வெளிப்படுத்துவது, அல்லது ஒரு write-ஐ அனுமதிப்பது போன்ற சூழலில், நீங்கள் சரிபார்க்கக்கூடிய evidence-ஐ விரும்புவீர்கள். அங்குதான் Proof of Actor பொருந்துகிறது, நீங்கள் ஏற்கனவே இயக்கும் network checks மற்றும் edge controls-உடன் இணைந்து செயல்படுகிறது.

தொடங்குங்கள்

Proof of Actor private beta-இல் உள்ளது. தேர்ந்தெடுக்கப்பட்ட founding developer teams-க்கு ஒப்புக்கொள்ளப்பட்ட usage limits-இல், automatic billing இல்லாமல், 12 மாதங்கள் வரை இலவச access வழங்கப்படலாம். early access-க்கு விண்ணப்பிக்கவும் மற்றும் இன்று நீங்கள் எந்த clients-ஐ allowlist செய்கிறீர்கள், மேலும் எந்த routes-ஐ சிறந்த evidence-உடன் பாதுகாக்க விரும்புகிறீர்கள் என்பதையும் எங்களுக்குத் தெரிவிக்கவும்.

உருவாக்குநர்களுக்காக

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: முடிவுக்குப் பின்னுள்ள signals, அதனால் உங்கள் team ஏன் என்பதைப் பார்க்க முடியும்.

observation mode-இல் தொடங்கவும்: முடிவுகளை உங்கள் logs-க்கு அடுத்ததாக பதிவு செய்யவும், நீங்கள் ஒரு policy-ஐத் தேர்வு செய்யும் வரை எதையும் மாற்றாதீர்கள். Node.js integration guide-ஐப் படிக்கவும்

அடிக்கடி கேட்கப்படும் கேள்விகள்

ஒரு user agent allowlist பயனற்றதா?

இல்லை. அது நன்றாக நடந்துகொள்ளும் clients-இன் பயனுள்ள declaration, மேலும் தெரிந்த crawlers-ஐ route செய்யும் ஒரு குறைந்த செலவு வழி. பிரச்சினை அதை proof ஆகக் கருதுவதில்தான். எந்த client-மும் எந்த User-Agent string-யையும் அனுப்ப முடியும், ஆகவே ஒரு allowlist மட்டும் sensitive actions-ஐ ஒருபோதும் திறக்கக்கூடாது.

Reverse DNS verification User-Agent spoofing-ஐ சரி செய்கிறதா?

அதை விளக்கமாக ஆவணப்படுத்தும் operators-க்கு அது உதவுகிறது. IP address-க்கு ஒரு reverse lookup செய்து, பின்னர் அதே hostname-க்கு ஒரு 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 basis ஆக அல்ல. ஒரு verified basis-க்கு, published key-க்கு எதிராக சரிபார்க்கப்பட்ட HTTP Message Signature போன்ற evidence தேவை.

ஒரு verified signature எதை proof செய்கிறது?

Request-ஐ எந்த key sign செய்தது, மேலும் signed செய்யப்பட்ட பகுதிகள் மாற்றப்படவில்லை என்பதைக் proof செய்கிறது. அந்த agent அந்த action-ஐ செய்ய authorized ஆக இருக்கிறதா என்பதை அது proof செய்யாது. Authorization உங்கள் application-இல் தான் இருக்கும்.

தெரிந்த agent என்று கூறும், ஆனால் verify செய்ய முடியாத clients-க்கு என்ன நடக்கும்?

Proof of Actor evidence ஆதரிக்கும் ஒன்றை report செய்கிறது, பெரும்பாலும் declared அல்லது inferred result, அல்லது Unknown. கூறப்பட்ட பெயரை நம்புவதற்குப் பதிலாக, அந்த route-க்கு fallback என்ன என்பது உங்கள் policy-யால் தீர்மானிக்கப்படுகிறது.

Proof of Actor-ஐ சேர்ப்பது என் தற்போதைய allowlist நடத்தையை மாற்றுமா?

இல்லை. அது observation mode-இல் தொடங்குகிறது. எதையும் மாற்றுவதற்கு முன், உண்மையான traffic-இல் அதன் முடிவுகளை உங்கள் allowlist decisions-உடன் ஒப்பிடலாம்.

உங்கள் app-ஐ யார் பயன்படுத்துகிறார்கள் என்பதை அறிந்துகொள்ளுங்கள்.

founding developers-இன் சிறிய குழுவுக்கான private beta.

முன்கூட்டிய அணுகலைப் பெறுக விலை விவரங்களை காண்க

முதலில் பேச விரும்புகிறீர்களா? founders-உடன் பேசுங்கள்