சரிபார்க்கப்பட்ட தானியக்கம்

சரிபார்க்கப்பட்ட தானியங்கி கோரிக்கைகளை அடையாளம் காணுங்கள்

ஒரு தானியங்கி client தனது கோரிக்கைகளில் கையொப்பமிடும்போது, உங்கள் application அந்த கையொப்பத்தைச் சரிபார்த்து, caller-ஐ அதற்கு ஏற்ப கையாள முடியும். Proof of Actor அந்தச் சரிபார்ப்பை தெளிவான, route செய்யக்கூடிய முடிவாக மாற்றுகிறது.

முன்கூட்டிய அணுகலைப் பெறுக எப்படி செயல்படுகிறது என்பதை ஆராய்க

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

அனைத்து தானியங்கி traffic-உம் ஒன்றே அல்ல

தானியங்கி clients ஒவ்வொரு நிமிடமும் உங்கள் application-ஐ அடைகின்றன: search crawlers, monitoring tools, partner integrations, பயனருக்காக pages-ஐ பெறும் AI assistants, மற்றும் tasks-ஐ முடிக்கும் autonomous agents. பல ஆண்டுகளாக, பெரும்பாலான applications அவற்றை வேறுபடுத்த பயன்படுத்திய ஒரே வழி user-agent header தான், அதாவது எந்த client-உம் எதை வேண்டுமானாலும் அமைக்கக்கூடிய ஒரு string.

அது application teams-ஐ ஒரு சிக்கலில் ஆழ்த்துகிறது. எல்லா automation-ஐயும் சந்தேகத்துடன் கருதினால், உங்கள் customers சார்ந்திருக்கும் legitimate agents-இன் அனுபவத்தை நீங்கள் பாதிக்கிறீர்கள். Header-ஐ நம்பினால், யாரும் தன்னை ஒரு well-known crawler என்று கூறிக்கொள்ள வாய்ப்பு பெறுகிறார்கள்.

சரிபார்க்கப்பட்ட தானியங்கி கோரிக்கைகள் இந்த சமன்பாட்டை மாற்றுகின்றன. ஒரு automated client தன் published key-ஐப் பயன்படுத்தி தனது requests-ஐ கையொப்பமிடும்போது, உங்கள் application அந்த signature-ஐச் சரிபார்த்து, cryptographically, எந்த client request-இல் கையொப்பமிட்டது என்பதை அறிய முடியும். Proof of Actor அந்தச் சரிபார்ப்பை, உங்கள் code route செய்யக்கூடிய ஒரே, ஒருங்கிணைந்த actor result-இன் ஒரு பகுதியாக மாற்றுகிறது. அந்தச் சரிபார்ப்பு என்ன நிரூபிக்கிறது, என்ன நிரூபிக்கவில்லை என்பதை நெருக்கமாக அறிய, signed AI agent requests என்ன நிரூபிக்கின்றன என்பதைப் படியுங்கள்.

Request signing எப்படி செயல்படுகிறது

தானியங்கி traffic-க்கு உருவாகி வரும் அணுகுமுறை HTTP message signatures-ஐப் பயன்படுத்துகிறது, இது RFC 9421-இல் standard-ஆக்கப்பட்டுள்ளது. இது ஒரு HTTP message-இன் கூறுகளில் signatures-ஐ உருவாக்க, encode செய்ய, verify செய்யும் முறையை வரையறுக்கிறது. Client, ஒவ்வொரு request-இன் தேர்ந்தெடுக்கப்பட்ட பகுதிகளை private key-ஆல் sign செய்து, signature-யையும் அதன் parameters-ஐயும் headers-இல் சேர்க்கிறது. அது தன் கட்டுப்பாட்டிலுள்ள ஒரு identifier-க்கு, பொதுவாக அதன் domain-க்கு இணைக்கப்பட்ட location-இல், தொடர்புடைய public key-ஐ வெளியிடுகிறது.

Request வந்ததும், receiver வெளியிடப்பட்ட key-ஐ fetch அல்லது look up செய்து, signed content-ஐ மீண்டும் அமைத்து, signature-ஐச் சரிபார்க்கிறது. அது validate ஆனால், அந்த request அந்த key-யை வைத்திருந்தவரால் sign செய்யப்பட்டது. தானியங்கி traffic-ஐ sign செய்வதற்கான வேலை IETF-இன் Web Bot Auth working group-இல் தொடர்ந்து நடைபெறுகிறது; அதன் charter, crawlers மற்றும் end users-க்காக செயல்படும் AI agents போன்ற automated clients-ஐ cryptographically authenticate செய்வதை உள்ளடக்கியது; Web Bot Auth glossary entry இதைச் சுருக்கமாக விளக்குகிறது. signed AI agent requests என்ன நிரூபிக்கின்றன என்ற blog post, verified request-ஐ end to end-ஆக விளக்குகிறது, மேலும் APIs use case verification முதலில் எங்கு பலன் அளிக்கிறது என்பதை காட்டுகிறது.

verifying signed agent requests என்ற guide, timestamps, replay windows மற்றும் key caching உட்பட mechanics-ஐ விரிவாகக் கூறுகிறது.

சரிபார்க்கப்பட்ட signature என்ன நிரூபிக்கிறது, என்ன நிரூபிக்கவில்லை

Verified automated requests-ஐ நன்றாக கையாள்வதில் இந்த வேறுபாடு தான் மிக முக்கியமான பகுதி.

ஒரு valid signature, request வெளியிடப்பட்ட identifier-உடன் தொடர்புடைய key-ஆல் sign செய்யப்பட்டது என்பதை நிரூபிக்கிறது. அந்த key ஒரு operator-இன் domain-க்கு சொந்தமானதாக இருந்தால், request அந்த operator-இன் key-ஐ வைத்திருந்த ஒரு client-இடமிருந்து வந்தது.

ஒரு valid signature இவற்றை நிரூபிக்காது:

agent-ஐ யார் இயக்கினார், அல்லது இந்த action-ஐச் செய்ய யாராவது ஒருவர் கேட்டார்களா என்பதை;
ஒரு person, agent-க்கு authority-ஐ delegated செய்தாரா என்பதை;
operator-க்கு பின்னால் உள்ள நிஜ உலக legal identity-ஐ;
கேட்ட action உங்கள் application-இல் safe ஆகவோ permitted ஆகவோ இருக்கிறதா என்பதை.

அவை தனித்த கேள்விகள். உங்கள் application அவற்றை தன் own credentials, authorization model மற்றும் policy-யால் பதிலளிக்கிறது. Proof of Actor அவற்றை திட்டமிட்டு தனியாக வைத்திருக்கிறது, மேலும் Detection & Limitations பக்கம் ஒவ்வொரு evidence வகையும் என்ன establish செய்ய முடியும் என்பதைத் துல்லியமாக விளக்குகிறது.

சரிபார்க்கப்பட்ட தானியங்கி requests-ஐ Proof of Actor எப்படி கையாளுகிறது

Detect

உங்கள் integration, signature headers உட்பட request context-ஐ Proof of Actor-க்கு அனுப்புகிறது. Signatures published keys-க்கு எதிராகச் சரிபார்க்கப்படுகின்றன. Validate ஆன requests verified basis-உடன் பதிவு செய்யப்படுகின்றன. தங்களை மட்டுமே அடையாளப்படுத்தும் clients declared ஆக பதிவு செய்யப்படுகின்றன. நடத்தை முறைப்படிகள் inferred ஆக பதிவு செய்யப்படுகின்றன. போதுமான ஆதாரம் இல்லாதபோது, result Unknown ஆகும். Cryptographic check வெற்றி பெற்றாலன்றி எதுவும் verified ஆக உயர்த்தப்படாது.

Understand

எந்த verified operators உங்கள் application-ஐ அழைக்கிறார்கள், அவர்கள் எந்த routes-ஐப் பயன்படுத்துகிறார்கள், எவ்வளவு அடிக்கடி, அது declared மற்றும் unknown automation-உடன் எப்படி ஒப்பிடப்படுகிறது என்பதைக் காணலாம். ஒவ்வொரு result-இலும் உள்ள evidence summary எந்த key மற்றும் identifier சேர்க்கப்பட்டிருந்தன என்பதைத் தெரிவிக்கிறது, எனவே உங்கள் team எந்த request-ஐயும் விரைவாக ஆராய முடியும்.

Route

உங்கள் policies-இல் basis-ஐப் பயன்படுத்துங்கள். பொதுவான patterns இவற்றைக் கொண்டுள்ளன:

read-only routes-இல், உதாரணமாக ஒரு API அல்லது ஒரு page-இன் Markdown version போன்றவற்றில், verified agents-க்கு structured response கொடுக்கவும்.
verified operators-க்கு rate limits-ஐ உயர்த்துங்கள், அதே நேரத்தில் declared clients-க்கு standard limits-ஐ வைத்திருங்கள்.
signature என்ன சொன்னாலும், ஒவ்வொரு write route-இலும் உங்கள் existing authorization-ஐ வைத்திருங்கள்.
ஒவ்வொரு route-இலும் unsigned மற்றும் Unknown callers-க்கு ஒரு explicit fallback-ஐ வரையறுக்கவும்.

உங்கள் policies முடிவெடுக்கின்றன; Proof of Actor evidence-ஐ வழங்குகிறது.

User-agent header மட்டும் போதாது ஏன்

User-agent strings declarations தான். எந்த client-உம் எந்த மதிப்பையும் அனுப்ப முடியும், மேலும் user-agent spoofing செய்வதற்கு திறமை தேவையில்லை. அதனால்தான் crawler operators தங்கள் own checks-ஐ வெளியிடுகிறார்கள்: Google, verifying Googlebot-க்காக reverse மற்றும் forward DNS lookups, மேலும் வெளியிடப்பட்ட IP ranges-ஐ ஆவணப்படுத்துகிறது; Bing, verifying Bingbot-க்காக ஒரு DNS check-ஐ ஆவணப்படுத்துகிறது; மேலும் OpenAI, தன் crawlers and user agents ஒவ்வொன்றுக்கும் IP range files-ஐ வெளியிடுகிறது. Proof of Actor, ஒரு user-agent claim-ஐ declared evidence ஆகவே கருதுகிறது, ஒருபோதும் verification ஆக அல்ல. அதாவது, valid signature இல்லாமல் தன்னை ஒரு well-known crawler என்று கூறிக்கொள்ளும் client declared அல்லது inferred basis-உடன் அறிக்கையிடப்படும், மேலும் உங்கள் policy, தன் identity-ஐ நிரூபித்த client-இருந்து அதை வேறுபட்டு நடத்த முடியும்.

இதுவே verified automated requests-ஐ மதிப்புமிக்கதாக மாற்றுகிறது: அவர்களுக்குத் தகுதி வரும் clients-க்கு trust-ஐ நீட்டிக்க ஒரு நம்பகமான வழியை இது தருகிறது, ஆனால் அவர்களின் header-ஐ நகலெடுக்கும் அனைவருக்கும் அதை விரிவாக்காது.

Identity evidence, credentials மற்றும் authorization

Automated clients-ஐ சேவை செய்யும் எந்த application-இலும் மூன்று layers ஒன்றாகச் செயல்படுகின்றன:

Identity evidence: இந்த request-இல் எந்த client கையொப்பமிட்டது? இதற்கு verified signature பதில் தருகிறது.
Credentials: எந்த account பொறுப்பு வகிக்கிறது? இதற்கு உங்கள் API key, token அல்லது session பதில் தருகிறது.
Authorization: இந்த caller இதைச் செய்ய முடியுமா? இதற்கு உங்கள் permission model பதில் தருகிறது.

Proof of Actor முதல் layer-ஐ வலுப்படுத்தி அதை வெளிப்படையாகக் காட்டுகிறது. அது identity அல்லது delegation credentials-ஐ issue செய்யாது, மேலும் உங்கள் authorization-ஐ மாற்றாது. Layers-ஐ தனித்தனியாக வைத்திருப்பதே, குறைந்த ஆபத்து உள்ள routes-இல் verified agents-க்கு தாராளமாகவும், அதிக தாக்கம் உள்ளவற்றில் எச்சரிக்கையுடனும் இருக்க உதவுகிறது.

இது எங்கு பொருந்துகிறது

Proof of Actor, உங்கள் gateway, authentication மற்றும் rate limiting-க்கு இணையாக அமர்கிறது. Integrations server-side middleware-ஆக, edge-இல், உங்கள் MCP server-இல் அல்லது generic HTTP integration மூலமாக செயல்படுகின்றன; founding team ஒவ்வொன்றுடனும் hands-on delivery வழங்கப்படுகிறது. உங்கள் traffic பெரும்பாலும் APIs மற்றும் tools ஆக இருந்தால், APIs மற்றும் MCP Servers use cases மிக முக்கியமான patterns-ஐக் காட்டுகின்றன.

Observation mode-இல் தொடங்குங்கள்

ஒவ்வொரு integration-உம் observation mode-இல் தொடங்குகிறது. Results உங்கள் application எப்படி respond செய்கிறது என்பதை மாற்றாமல் பதிவு செய்யப்படுகின்றன, இதனால் உங்கள் தானியங்கி traffic-இன் எவ்வளவு பகுதி verified என்பது, எந்த operators sign செய்கிறார்கள், மேலும் unknown rate எங்கு அதிகமாக உள்ளது என்பதைக் காணலாம். Policies பிறகு, route by route, evidence அவற்றை support செய்யும் போது வரும். How It Works முழு flow-ஐ விளக்குகிறது.

Verification-ஐ நம்பகமாக ஆக்கும் நடைமுறை விவரங்கள்

Signature checking, அதைச் சுற்றியுள்ள விவரங்கள் எவ்வளவு துல்லியமாக உள்ளன என்பதற்கேற்ப தான் சிறப்பாகும். சில நடைமுறைகள் verified automated requests-ஐ production-இல் நம்பகமாக்குகின்றன.

Freshness-ஐச் சரிபார்க்கவும்

RFC 9421 created மற்றும் expires signature parameters-ஐ வரையறுக்கிறது, மேலும் signed requests அவற்றை பொதுவாகக் கொண்டிருக்கும். குறுகிய window-க்கு வெளியிலான signatures-ஐ நிராகரிக்கவும், இதனால் பிடிக்கப்பட்ட request பின்னர் replay செய்யப்பட முடியாது.

Keys-ஐ சீராக cache செய்யவும்

ஒவ்வொரு request-இலும் operator-இன் வெளியிடப்பட்ட keys-ஐ fetch செய்வது latency-ஐ அதிகரிக்கிறது. அவற்றை நியாயமான காலத்திற்குக் cache செய்து, unknown key identifier உடன் signature தோல்வியடையும் போது refresh செய்யவும், இதனால் key rotation false failures-க்கு காரணமாகாது.

Request-இன் சரியான பகுதிகளை sign செய்யவும்

Timestamp-ஐ மட்டும் cover செய்யும் ஒரு signature மிகக் குறைவையே நிரூபிக்கிறது. Signed components-இல் method, path மற்றும் host சேர்க்கப்பட்டுள்ளதா என்பதை உறுதிசெய்யவும், இதனால் signature உங்கள் application உண்மையில் பெற்ற request-உடன் இணைக்கப்படும்.

Evidence-ஐ பதிவு செய்யவும்

ஒவ்வொரு verified request-உடனும் key identifier, வெளியிடப்பட்ட identifier மற்றும் result-ஐ வைத்திருங்கள். ஏதேனும் அசாதாரணம் நடந்தால், உங்கள் team எந்த client எதை, எப்போது sign செய்தது என்பதைத் துல்லியமாகப் பார்க்க முடியும்.

Proof of Actor இந்தச் சரிபார்ப்புகளை Detect படியின் ஒரு பகுதியாகக் கையாளுகிறது, மேலும் policies படிக்கக்கூடிய basis ஆக outcome-ஐ அறிக்கையிடுகிறது, அதனால் உங்கள் application code எளிமையாக இருக்கும்.

Founding developer program-இல் சேருங்கள்

Proof of Actor private beta-இல் உள்ளது. தேர்ந்தெடுக்கப்பட்ட founding development teams agreed usage limits-க்குள் 12 மாதங்கள் வரை இலவச access-ஐப் பெறலாம், மேலும் எங்கள் engineers-இருந்து நேரடி integration support கிடைக்கும்.

தானியங்கி clients உங்கள் application-ஐ அடைந்து, சரிபார்க்கப்பட்டவற்றை வேறுபடக் கையாள விரும்பினால், early access-க்கு விண்ணப்பிக்கவும். உங்கள் application மற்றும் நீங்கள் காணும் automated callers பற்றி எங்களிடம் சொல்லுங்கள், Proof of Actor எவ்வாறு பொருந்துகிறது என்பதை நாங்கள் காட்டுவோம்.

Sources

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
Verifying Googlebot and other Google crawlers, Google Search Central.
How to verify that Bingbot is Bingbot, Bing Webmaster Blog.
Overview of OpenAI crawlers, OpenAI.

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

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-ஐப் படிக்கவும்

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

சரிபார்க்கப்பட்ட தானியங்கி கோரிக்கை என்றால் என்ன?

அது, operator-இன் domain போன்ற ஒரு அறியப்பட்ட identifier-க்கு வெளியிடப்பட்ட key-க்கு எதிராக சரிபார்க்கப்படும் cryptographic signature உடைய ஒரு automated client-இன் கோரிக்கை. எந்த client கோரிக்கையில் கையொப்பமிட்டது என்பதை இது காட்டுகிறது.

ஒரு சரிபார்க்கப்பட்ட signature இருப்பது agent-க்கு authorization உண்டு என்பதைக் குறிக்குமா?

இல்லை. ஒரு signature, ஒரு கோரிக்கையை ஒரு key-க்கும் அதன் வெளியிடப்பட்ட identifier-க்கும் தொடர்புபடுத்துகிறது. அந்த client ஒரு action-ஐ செய்ய முடியுமா என்பது, உங்கள் application மேற்கொள்ளும் தனித்த authorization முடிவு.

தங்கள் கோரிக்கைகளில் கையொப்பமிடாத automated clients பற்றி என்ன?

Proof of Actor அவற்றையும் still classify செய்கிறது, கிடைக்கும்போது declared மற்றும் inferred evidence-ஐப் பயன்படுத்தி, evidence போதுமானதாக இல்லாதபோது Unknown-ஐ அறிக்கையிடுகிறது. ஒவ்வொரு result-உம் அதன் basis-ஐக் குறிப்பிடுகிறது.

ஒரு user-agent string ஒரு client-ஐ சரிபார்க்க முடியுமா?

இல்லை. User-agent strings எளிதாக போலியாக உருவாக்கப்படலாம், ஆகவே அவை ஒரு declaration ஆகும், verification அல்ல. ஒரு கோரிக்கையை verifiable ஆக்கும் விஷயம் cryptographic signatures தான்.

நான் எப்படி தொடங்குவது?

Early access-க்கு விண்ணப்பிக்கவும். Founding teams observation mode-இல் தொடங்குகின்றன, மேலும் தேர்ந்தெடுக்கப்பட்ட teams agreed usage limits-க்குள் 12 மாதங்கள் வரை இலவசமாகப் பெறலாம்.

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

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

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

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