முக்கிய உள்ளடக்கத்திற்கு தவிர்க்கவும்
அகராதி

பயனர்-ஏஜென்ட் போலிமைப்பு

Toshendra Sharma

ஆசிரியர் Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

கிளையண்டை தவறாகக் காட்டும் User-Agent header-ஐ அனுப்புவது. உதாரணமாக, ஒரு script தன்னை browser என்று கூறுவது அல்லது ஒரு scraper தன்னை அறியப்பட்ட crawler என்று கூறுவது.

பயனர்-ஏஜென்ட் போலிமைப்பு என்றால் என்ன

ஒவ்வொரு HTTP client-மும் தன்னை விவரிக்கும் ஒரு User-Agent header-ஐ அனுப்ப முடியும்: browser பெயர் மற்றும் version, crawler பெயர், library identifier. இந்த header self-reported ஆகும். அது உண்மை என்பதை HTTP-ல் எதுவும் சரிபார்க்காது, ஆகவே எந்த client-மும் எந்த value-யையும் அனுப்பலாம். பயனர்-ஏஜென்ட் போலிமைப்பு என்பது client-ஐ தவறாகக் காட்டும் value-ஐ அனுப்பும் நடைமுறை, உதாரணமாக:

  • ஒரு automation script தன்னை தற்போதைய desktop browser ஆகக் காட்டுவது,
  • ஒரு scraper தன்னை நன்கு அறியப்பட்ட search crawler என்று கூறி சிறந்த treatment பெற முயல்வது,
  • ஒரு AI agent பொதுவான browser string-ஐ பயன்படுத்தி, அதை ஒரு நபர் போலக் கருதப்படுவது.

இது ஏன் முக்கியம்

பல systems இன்னும் user-agent string-இல் இருந்து முடிவுகள் எடுக்கின்றன: அறியப்பட்ட crawlers-ஐ allowlisting செய்வது, bots-க்கு வேறு content வழங்குவது, அல்லது analytics-இல் இருந்து automation-ஐ நீக்குவது. இப்படிப்பட்ட ஒவ்வொரு முடிவும் இந்த header-இன் பலவீனத்தை மரபாக ஏற்கிறது. ஒரு policy "crawler X என்று கூறும் எதையும் allow செய்யுங்கள்" என்று சொன்னால், crawler X-இன் string-ஐ நகலெடுக்கும் அனைவருக்கும் அது அனுமதி தரும்.

AI agent traffic பெறும் applications-க்கு, காலப்போக்கில் இது இன்னும் முக்கியமாகிறது. Agents increasingly உண்மை browsers-இல் அல்லது headless browser frameworks-இல் இயங்குகின்றன, ஆகவே அவற்றின் user-agent strings மனித browser-களைப் போலவே தெரியும். சிலர் நேர்மையாக அடையாளம் தெரிவிக்கின்றனர். இந்த header மட்டுமே வைத்து எது எது என்று சொல்ல முடியாது. website traffic AI agents-இலிருந்து வருகிறதா என்பதை எப்படித் தெரிந்துகொள்வது என்ற எங்கள் பதிவில், சிறப்பாக வேலை செய்யும் signals பற்றி பார்க்கலாம்.

header-ஐ விட நல்ல evidence

  • Cryptographic signatures. HTTP Message Signatures மற்றும் Web Bot Auth பணியுடன், ஒரு client தன் பெயரில் operator வெளியிட்ட key-ஐ தன்னிடம் வைத்திருக்கிறது என்பதை நிரூபிக்கிறது. நகலெடுக்கப்பட்ட user-agent string signature-ஐ மீண்டும் உருவாக்க முடியாது.
  • Operator வெளியிட்ட verification. சில crawler operators IP ranges-ஐ வெளியிடுகிறார்கள் அல்லது reverse DNS checks-ஐ ஆதரிக்கிறார்கள், இது header மட்டும் இருந்தால் விட impersonation-ஐ கடினமாக்குகிறது. Google அதன் crawlers-க்கு reverse DNS மற்றும் IP range check-ஐ ஆவணப்படுத்துகிறது, Microsoft ஒரு Verify Bingbot tool-ஐ வழங்குகிறது, மேலும் OpenAI அதன் bot-களுக்கான IP address files-ஐ வெளியிடுகிறது. Anthropic-இன் அதன் hosted browser agent-க்கான வழிகாட்டுதல் தெளிவாக, யாரும் அதே User-Agent header-ஐ அனுப்ப முடியும் என்று கூறுகிறது, மேலும் அதன் வெளியிடப்பட்ட IP addresses-ஐ சரிபார்க்க பரிந்துரைக்கிறது.
  • Consistency checks. கூறப்பட்ட client-ஐ protocol details மற்றும் interaction signals-உடன் ஒப்பிடுவது, ஒரு claim பொருந்தாதபோது காட்ட முடியும், ஆனால் இது inference-ஐ உருவாக்கும், proof-ஐ அல்ல.
  • Credentials. APIs-க்கு, ஒரு API key அல்லது token header என்ன சொன்னாலும் எந்த account அழைக்கிறது என்பதை உங்களுக்கு சொல்கிறது.

பொதுவான தவறான புரிதல்கள்

  • "ஒரு browser user-agent என்றால் அது ஒரு human." Headless browsers மற்றும் agent frameworks முறையாக browser strings-ஐ அனுப்புகின்றன.
  • "ஒரு crawler user-agent என்றால் அது crawler தான்." Signature அல்லது operator verification check இல்லாமல், அது ஒரு claim மட்டுமே.
  • "Spoofing எப்போதும் malicious தான்." சில legitimate tools உடைந்த pages வழங்கப்படாமல் இருக்க பொதுவான strings-ஐ அனுப்புகின்றன. Spoofing என்பது header-ஐ குறைவாக நம்ப வேண்டிய காரணம், bad intent-க்கு proof அல்ல.

Proof of Actor user-agent string-ஐ எப்படி கையாளுகிறது

Proof of Actor ஒரு user-agent claim-ஐ declared evidence ஆக பதிவு செய்கிறது: client கூறியது, அது உண்மை ஆகவும் இருக்கலாம், இல்லாமலும் இருக்கலாம். அது ஒரு declaration-ஐ தனக்கே தனியாக verified ஆக உயர்த்தாது. ஒரே identifying evidence ஒரு crawler user-agent string மட்டுமே உள்ள request அதற்கேற்றவாறு label செய்யப்படுகிறது, மேலும் evidence போதுமானதாக இல்லாதபோது முடிவு Unknown ஆக இருக்கும், நம்பிக்கையுள்ள ஊகம் அல்ல. பின்னர் Route-இல் உள்ள உங்கள் policies, ஒரு verified signed agent மற்றும் ஒரு self-declared one-ஐ வேறுபடையாகக் கருதலாம், உதாரணமாக இரண்டையும் read-only routes-இல் allow செய்வது, ஆனால் declared ஒன்றுக்கு கடுமையான limits-ஐப் பயன்படுத்துவது.

evidence bases எப்படி செயல்படுகின்றன என்பதைப் பார்க்கவும் அல்லது early access-க்கு விண்ணப்பிக்கவும்.

Sources

உங்கள் சொந்த app இல் actor intelligence ஐப் பாருங்கள்.

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