ਮੁੱਖ ਸਮੱਗਰੀ 'ਤੇ ਜਾਓ
ਵਿਆਖਿਆ

Product teams ਲਈ Web Bot Auth: signed agent requests ਦਾ ਤੁਹਾਡੀ roadmap ਲਈ ਕੀ ਅਰਥ ਹੈ

AI agents ਅਤੇ crawlers ਨੂੰ increasingly ਇੱਕ ਐਸਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਨਾਲ ਉਹ ਦੱਸ ਸਕਣ ਕਿ ਉਹ ਕੌਣ ਹਨ, ਬਿਨਾਂ ਇਸਦੇ ਕਿ ਕਿਸੇ ਵੀ User-Agent string 'ਤੇ ਨਿਰਭਰ ਕੀਤਾ ਜਾਵੇ ਜੋ ਕੋਈ ਵੀ copy ਕਰ ਸਕਦਾ ਹੈ। IETF ਦਾ Web Bot Auth ਕੰਮ ਇਸਨੂੰ standardize ਕਰਨ ਲਈ leading effort ਹੈ। ਇੱਥੇ product managers ਅਤੇ engineering leads ਲਈ ਇੱਕ ਸਧਾਰਣ ਵਿਆਖਿਆ ਹੈ: ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਹ ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ, November 2026 ਤੱਕ ਇਸ ਦੀ ਕੀ status ਹੈ, ਅਤੇ ਇਸ ਲਈ ਕਿਵੇਂ plan ਕਰਨਾ ਹੈ।

ਅਗਾਊਂ ਪਹੁੰਚ ਲਵੋਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਵੇਖੋ
Toshendra Sharma

ਦੁਆਰਾ Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

ਸਾਲਾਂ ਤੱਕ, ਇੱਕ automated client ਵੱਲੋਂ ਕਿਸੇ website ਨੂੰ ਇਹ ਦੱਸਣ ਦਾ ਇਕੱਲਾ ਤਰੀਕਾ ਕਿ ਉਹ ਕੌਣ ਹੈ, User-Agent header ਵਿੱਚ ਇੱਕ ਨਾਮ ਅਤੇ, ਕੁਝ ਵੱਡੇ operators ਲਈ, published IP addresses ਦੀ ਇੱਕ ਸੂਚੀ ਜਾਂ reverse DNS check ਰਿਹਾ ਹੈ। ਨਾਮ ਆਸਾਨੀ ਨਾਲ copy ਹੋ ਜਾਂਦੇ ਹਨ। Network lists ਸਿਰਫ਼ ਉਹਨਾਂ operators ਤੱਕ ਹੀ ਸੀਮਿਤ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਉਹਨਾਂ ਨੂੰ maintain ਕਰਦੇ ਹਨ। ਜਿਵੇਂ AI agents web across real people ਲਈ act ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹਨ, ਇਹ gap ਇੱਕ product problem ਬਣ ਗਿਆ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇੱਕ security problem।

Web Bot Auth ਇਸ ਨੂੰ ਬੰਦ ਕਰਨ ਲਈ leading effort ਹੈ। ਇਹ automated clients ਨੂੰ ਉਹਨਾਂ ਦੀ ਆਪਣੀ control ਅਤੇ publish ਕੀਤੀ key ਨਾਲ requests sign ਕਰਨ ਦਾ ਤਰੀਕਾ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਇੱਕ site ਨਾਮ 'ਤੇ trust ਕਰਨ ਦੀ ਬਜਾਇ signature check ਕਰ ਸਕੇ। ਇਹ explainer ਉਹਨਾਂ product managers ਅਤੇ engineering leads ਲਈ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਹ ਸਮਝਣਾ ਹੈ ਕਿ ਇਹ ਕੀ ਹੈ, ਇਹ ਕੀ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਇਹ ਕੀ ਨਹੀਂ ਬਦਲਦਾ, ਬਿਨਾਂ specifications ਨੂੰ end to end ਪੜ੍ਹੇ।

ਛੋਟਾ ਸੰਸਕਰਣ

  • ਇਹ ਕੀ ਹੈ: ਇੱਕ IETF working group, webbotauth, ਅਤੇ ਉਹ approach ਜਿਸਨੂੰ ਇਹ automated HTTP clients ਦੀ authentication ਲਈ standardize ਕਰ ਰਿਹਾ ਹੈ।
  • ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ: client request ਦੇ ਕੁਝ ਹਿੱਸੇ HTTP Message Signatures (RFC 9421) ਦੀ ਵਰਤੋਂ ਨਾਲ sign ਕਰਦਾ ਹੈ ਅਤੇ ਆਪਣੀਆਂ public keys ਦੀ ਇੱਕ directory ਵੱਲ point ਕਰਦਾ ਹੈ। Site key fetch ਕਰਦੀ ਹੈ ਅਤੇ signature verify ਕਰਦੀ ਹੈ।
  • ਇਹ ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ: ਕਿਹੜੀ key ਨੇ request sign ਕੀਤੀ, ਅਤੇ ਇਹ ਕਿ signed parts transit ਵਿੱਚ ਨਹੀਂ ਬਦਲੇ ਗਏ।
  • ਇਹ ਕੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ: ਕਿ agent ਨੂੰ ਜੋ ਉਹ ਮੰਗ ਰਿਹਾ ਹੈ ਉਹ ਕਰਨ ਦੀ authorization ਹੈ, ਕਿ ਇਹ ਕਿਸੇ ਖਾਸ user ਲਈ act ਕਰਦਾ ਹੈ, ਜਾਂ ਕਿ ਇਹ ਚੰਗਾ behave ਕਰੇਗਾ।
  • November 2026 ਤੱਕ status: RFC 9421 ਇੱਕ published Proposed Standard ਹੈ। Web Bot Auth protocol document ਇੱਕ working group Internet-Draft ਹੈ, ਹਾਲੇ RFC ਨਹੀਂ।
  • ਕੀ ਕਰਨਾ ਹੈ: valid signatures ਨੂੰ strong evidence ਵਜੋਂ treat ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਓ, unsigned traffic ਨੂੰ handle ਕਰਨਾ ਜਾਰੀ ਰੱਖੋ, ਅਤੇ authorization decisions ਆਪਣੇ code ਵਿੱਚ ਰੱਖੋ।

IETF Web Bot Auth ਦਾ ਕੰਮ ਕੀ ਹੈ

IETF ਨੇ Web Bot Auth working group ਨੂੰ cryptographically automated clients ਨੂੰ authenticate ਕਰਨ ਦੇ methods standardize ਕਰਨ ਲਈ ਅਤੇ websites ਨੂੰ ਉਹਨਾਂ ਦੇ ਪਿੱਛੇ ਵਾਲੇ operators ਬਾਰੇ ਵਧੇਰੇ ਜਾਣਕਾਰੀ ਦੇਣ ਲਈ charter ਕੀਤਾ। Charter ਉਹਨਾਂ sites 'ਤੇ focus ਕਰਦਾ ਹੈ ਜੋ ਮੁੱਖ ਤੌਰ 'ਤੇ ਲੋਕਾਂ ਦੀ service ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਇਹ scope ਵਿੱਚ clients ਦੀ ਇੱਕ ਵਿਆਪਕ list ਦਿੰਦਾ ਹੈ: crawlers, web archivers, link checkers, AI training crawlers ਅਤੇ end users ਲਈ act ਕਰਨ ਵਾਲੇ AI agents।

Charter ਵਿੱਚ ਦੋ exclusions product teams ਲਈ ਧਿਆਨ ਦੇ ਯੋਗ ਹਨ। End-user authentication scope ਤੋਂ ਬਾਹਰ ਹੈ, ਇਸ ਲਈ ਇਹ ਕਿਸੇ person ਨੂੰ log in ਕਰਨ ਦਾ ਤਰੀਕਾ ਨਹੀਂ ਹੈ। Bot reputation tracking ਵੀ scope ਤੋਂ ਬਾਹਰ ਹੈ, ਇਸ ਲਈ standard ਤੁਹਾਨੂੰ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ request ਕਿਸ ਨੇ sign ਕੀਤੀ, ਨਾ ਕਿ ਉਹ operator trustworthy ਹੈ ਜਾਂ ਨਹੀਂ।

Charter ਤਿੰਨ ਕਿਸਮ ਦੇ deliverables list ਕਰਦਾ ਹੈ:

  1. People ਲਈ ਬਣੀਆਂ websites ਨਾਲ automated clients ਨੂੰ authenticate ਕਰਨ ਲਈ techniques 'ਤੇ Standards track documents।
  2. Existing identifier ਜਿਵੇਂ ਕਿ domain name ਜਾਂ URL ਦੀ ਵਰਤੋਂ ਕਰਕੇ requesting bot ਬਾਰੇ ਵਧੇਰੇ ਜਾਣਕਾਰੀ convey ਕਰਨ ਲਈ Standards track documents।
  3. Key management, lifecycle ਅਤੇ deployment ਵਰਗੇ operational topics 'ਤੇ Best current practice ਜਾਂ informational documents।

November 2026 ਤੱਕ documents ਦੀ ਸਥਿਤੀ

November 2026 ਤੱਕ, working group ਕੋਲ ਇੱਕ adopted working group document ਹੈ: draft-ietf-webbotauth-httpsig-protocol, titled "HTTP Message Signatures for automated traffic", revision 01 'ਤੇ, date October 29, 2026। ਇਹ ਇੱਕ Internet-Draft ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਇੱਕ ਕੰਮ ਚੱਲ ਰਿਹਾ draft ਹੈ ਜੋ ਹਾਲੇ ਵੀ ਬਦਲ ਸਕਦਾ ਹੈ। ਇਹ RFC ਨਹੀਂ ਹੈ।

ਕਈ individual drafts ਵੀ ਇਸ group ਨਾਲ ਸੰਬੰਧਿਤ ਹਨ ਅਤੇ ਚਰਚਾ ਅਧੀਨ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ registry ਅਤੇ agent card format ਬਾਰੇ proposals, anonymous bot authentication, automated clients ਦੇ IP ranges publish ਕਰਨ ਲਈ ਇੱਕ JSON format, ਅਤੇ signed agent metadata ਲਈ ਇੱਕ header ਸ਼ਾਮਲ ਹਨ। Individual drafts proposals ਹਨ; ਇਸ date ਤੱਕ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਵੀ group ਨੇ adopt ਨਹੀਂ ਕੀਤਾ।

Charter ਨੇ 2026 ਦੌਰਾਨ specifications ਨੂੰ approval ਲਈ IESG ਨੂੰ ਭੇਜਣ ਲਈ milestones set ਕੀਤੇ ਸਨ। November 2026 ਤੱਕ, protocol document ਇੱਕ working group draft ਹੀ ਰਹਿੰਦਾ ਹੈ। ਤੁਸੀਂ IETF datatracker page for the working group ਅਤੇ protocol draft 'ਤੇ current state follow ਕਰ ਸਕਦੇ ਹੋ।

HTTP Message Signatures ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ

Web Bot Auth RFC 9421, HTTP Message Signatures 'ਤੇ ਬਣਦਾ ਹੈ, ਜੋ February 2024 ਵਿੱਚ ਇੱਕ Proposed Standard ਵਜੋਂ published ਹੋਇਆ ਸੀ। RFC 9421 ਇੱਕ general mechanism ਹੈ: ਇਹ define ਕਰਦਾ ਹੈ ਕਿ HTTP message ਦੇ selected parts ਨੂੰ ਕਿਵੇਂ sign ਕਰਨਾ ਹੈ ਅਤੇ signature ਨੂੰ headers ਵਿੱਚ ਕਿਵੇਂ carry ਕਰਨਾ ਹੈ। Web Bot Auth ਇਸਨੂੰ automated clients ਲਈ profile ਕਰਦਾ ਹੈ।

ਸਧਾਰਣ terms ਵਿੱਚ, ਇੱਕ signed agent request ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ:

  1. Operator ਇੱਕ key pair ਬਣਾਉਂਦਾ ਹੈ। ਇਹ private key ਨੂੰ secret ਰੱਖਦਾ ਹੈ ਅਤੇ public key publish ਕਰਦਾ ਹੈ।
  2. Client ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕੀ sign ਕਰਨਾ ਹੈ। ਇਹ request ਦੇ components ਚੁਣਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ target host ਜਾਂ URI ਅਤੇ creation time। Current draft authority ਜਾਂ target URI ਨੂੰ cover ਕਰਨ ਦੀ ਲੋੜ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਜੋ ਇੱਕ site ਲਈ ਬਣੀ signature ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਕਿਸੇ ਹੋਰ site ਲਈ replay ਨਾ ਕੀਤਾ ਜਾ ਸਕੇ।
  3. Client sign ਕਰਦਾ ਹੈ ਅਤੇ ਭੇਜਦਾ ਹੈ। Request ਵਿੱਚ ਇੱਕ Signature-Input header ਹੁੰਦਾ ਹੈ ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ sign ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਕਿਸ key ਨਾਲ, ਅਤੇ ਇੱਕ Signature header ਜਿਸ ਵਿੱਚ signature value ਹੁੰਦੀ ਹੈ। Draft ਇੱਕ web-bot-auth tag ਵਰਤਦਾ ਹੈ ਅਤੇ ਹਰ signature 'ਤੇ creation ਅਤੇ expiry times ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ।
  4. Site verify ਕਰਦੀ ਹੈ। ਇਹ public key ਲੱਭਦੀ ਹੈ, ਆਪਣੀ ਮਿਲੀ request ਤੋਂ signed components ਦੁਬਾਰਾ ਬਣਾਉਂਦੀ ਹੈ, ਅਤੇ signature check ਕਰਦੀ ਹੈ। ਜੇ check pass ਹੋ ਜਾਵੇ, ਤਾਂ request ਉਸ key ਦੇ holder ਦੁਆਰਾ sign ਕੀਤੀ ਗਈ ਸੀ ਅਤੇ covered parts alter ਨਹੀਂ ਕੀਤੇ ਗਏ ਸਨ।

Draft site ਨੂੰ signature ਮੰਗਣ ਦੀ ਆਗਿਆ ਵੀ ਦਿੰਦਾ ਹੈ। ਇੱਕ origin Accept-Signature header ਭੇਜ ਸਕਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ refusal ਦੇ ਨਾਲ, ਇਹ signal ਕਰਨ ਲਈ ਕਿ ਉਹ signed requests ਚਾਹੁੰਦਾ ਹੈ।

Key directory ਦਾ ਵਿਚਾਰ

ਜੇ site ਸਹੀ public key ਨਾ ਲੱਭ ਸਕੇ ਤਾਂ signature only useful ਹੈ। Web Bot Auth ਇਸਦਾ ਜਵਾਬ ਇੱਕ key directory ਨਾਲ ਦਿੰਦਾ ਹੈ।

Current working group draft ਵਿੱਚ, client ਇੱਕ Signature-Agent header ਜੋੜਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ HTTPS URL ਹੁੰਦਾ ਹੈ। ਉਹ URL operator ਦੀਆਂ public keys ਦੀ ਇੱਕ directory ਨੂੰ JSON Web Key Set ਵਜੋਂ serve ਕਰਦਾ ਹੈ। Site directory fetch ਕਰਦੀ ਹੈ, signature ਵਿੱਚ key identifier ਨਾਲ match ਹੋਣ ਵਾਲੀ key ਚੁਣਦੀ ਹੈ, ਅਤੇ verify ਕਰਦੀ ਹੈ। Draft ਇੱਕ well-known path, /.well-known/http-message-signatures-directory, ਵੀ define ਕਰਦਾ ਹੈ, ਜਿੱਥੇ operator ਆਪਣੀ directory serve ਕਰ ਸਕਦਾ ਹੈ।

Product teams ਲਈ ਲਾਭਦਾਇਕ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ URL identity ਬਣ ਜਾਂਦਾ ਹੈ। ਇੱਕ agent operator ਨੂੰ ਉਹਨਾਂ ਦੀਆਂ keys ਜਿੱਥੇ publish ਹੁੰਦੀਆਂ ਹਨ ਉਸ ਸਥਾਨ ਨਾਲ identify ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ signature ਨੂੰ operator ਦੇ control ਵਾਲੇ domain ਨਾਲ ਜੋੜਦਾ ਹੈ। Key rotation ਨਵੀਂ key ਨੂੰ ਪੁਰਾਣੀ key ਦੇ ਨਾਲ publish ਕਰਕੇ, ਫਿਰ ਪੁਰਾਣੀ ਨੂੰ ਹਟਾ ਕੇ ਕੰਮ ਕਰਦੀ ਹੈ।

Verifying sites ਨੂੰ directories ਨੂੰ ਧਿਆਨ ਨਾਲ handle ਕਰਨ ਦੀ ਲੋੜ ਹੈ: ਉਹਨਾਂ ਨੂੰ normal HTTP rules ਅਨੁਸਾਰ cache ਕਰੋ, size limits ਅਤੇ timeouts set ਕਰੋ, ਅਤੇ private network addresses ਤੋਂ fetch ਕਰਨ ਤੋਂ ਬਚੋ। ਇਹ standard engineering concerns ਹਨ, ਅਤੇ ਇਹੀ ਇੱਕ ਕਾਰਨ ਹੈ ਕਿ ਕਈ teams verification ਉਹਨਾਂ ਲਈ ਕਰਨ ਵਾਲੇ component ਨੂੰ prefer ਕਰਦੀਆਂ ਹਨ।

ਇੱਕ valid signature ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੀ ਨਹੀਂ

ਇਹ ਕਿਸੇ ਵੀ product policy ਲਿਖਣ ਵਾਲੇ ਲਈ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ section ਹੈ।

ਇੱਕ valid signature ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ:

  • Request ਇੱਕ specific private key ਦੇ holder ਦੁਆਰਾ sign ਕੀਤੀ ਗਈ ਸੀ।
  • ਉਹ key ਇੱਕ directory URL 'ਤੇ publish ਕੀਤੀ ਗਈ ਹੈ ਜਿਸਨੂੰ operator control ਕਰਦਾ ਹੈ।
  • Request ਦੇ signed parts transit ਵਿੱਚ ਨਹੀਂ ਬਦਲੇ ਗਏ ਸਨ, ਅਤੇ signature ਆਪਣੀ validity window ਦੇ ਅੰਦਰ ਹੈ।

ਇੱਕ valid signature ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ:

  • ਕਿ agent ਨੂੰ ਕਾਰਵਾਈ ਕਰਨ ਦੀ authorization ਹੈ। Identify ਹੋਣਾ permission ਨਹੀਂ ਹੈ। agent authorization ਵੇਖੋ।
  • ਕਿ agent ਕਿਸੇ specific person ਲਈ act ਕਰਦਾ ਹੈ, ਜਾਂ ਉਸ authority ਦੇ within ਜੋ ਉਹ person ਨੇ ਦਿੱਤੀ ਸੀ। delegated authority ਵੇਖੋ।
  • ਕਿ operator trustworthy ਹੈ ਜਾਂ agent ਚੰਗਾ behave ਕਰੇਗਾ। Reputation working group ਦੇ scope ਤੋਂ explicitly ਬਾਹਰ ਹੈ।
  • ਉਹਨਾਂ requests ਬਾਰੇ ਕੁਝ ਵੀ ਜੋ sign ਨਹੀਂ ਕੀਤੀਆਂ ਗਈਆਂ। Unsigned traffic ਨੂੰ ਹਾਲੇ ਵੀ ਆਪਣੀ handling ਦੀ ਲੋੜ ਹੈ।

ਇੱਕ valid signature ਨੂੰ ਕਿਸ ਨੇ request ਭੇਜੀ ਇਸ ਦੇ strong evidence ਵਜੋਂ treat ਕਰੋ, ਫਿਰ ਆਪਣਾ access control ਇਹ decide ਕਰਨ ਦੇਵੇ ਕਿ ਉਹ sender ਕੀ ਕਰ ਸਕਦਾ ਹੈ।

Product teams ਨੂੰ ਇਸ ਬਾਰੇ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

ਤੁਹਾਨੂੰ plan ਕਰਨ ਲਈ RFC ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। Signed agent traffic ਉਹ ਚੀਜ਼ ਹੈ ਜਿਸ ਲਈ ਤੁਸੀਂ ਹੁਣ ਤੋਂ prepare ਕਰ ਸਕਦੇ ਹੋ, ਇਸ ਉਮੀਦ ਨਾਲ ਕਿ draft ਦੇ ਕੁਝ details ਬਦਲ ਸਕਦੇ ਹਨ।

1. Decide ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ measure ਕਰੋ

ਪਤਾ ਕਰੋ ਕਿ ਤੁਹਾਡਾ ਕਿੰਨਾ traffic automated ਹੈ, agents ਕਿਹੜੇ routes ਵਰਤਦੇ ਹਨ, ਅਤੇ ਇਸ ਵਿੱਚੋਂ ਕਿੰਨਾ signed ਹੈ। observation mode ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ ਤਾਂ ਜੋ measuring ਤੁਹਾਡੇ users ਲਈ ਕੁਝ ਨਾ ਬਦਲੇ।

2. Evidence ਨੂੰ policy ਤੋਂ ਵੱਖ ਕਰੋ

ਜੋ evidence ਕਹਿੰਦਾ ਹੈ, verified, declared, inferred ਜਾਂ unknown, ਉਸਨੂੰ ਉਸ ਤੋਂ ਵੱਖ record ਕਰੋ ਜੋ ਤੁਸੀਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰਦੇ ਹੋ। ਇਹ policies ਨੂੰ readable ਰੱਖਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਬਿਨਾਂ re-instrumenting ਦੇ ਉਹਨਾਂ ਨੂੰ tighten ਜਾਂ relax ਕਰਨ ਦਿੰਦਾ ਹੈ। evidence basis entry ਚਾਰ levels ਨੂੰ ਸਮਝਾਉਂਦੀ ਹੈ।

3. Verified agents ਨੂੰ ਇੱਕ better path ਦਿਓ

ਜਿੱਥੇ ਇਹ ਢੁੱਕਵਾਂ ਹੋਵੇ, verified agents ਨੂੰ people ਲਈ ਬਣੇ pages ਦੀ ਬਜਾਇ structured content ਜਾਂ ਇੱਕ agent-friendly flow ਦਿਓ। serving AI agents structured content ਵਾਲਾ guide patterns ਨੂੰ cover ਕਰਦਾ ਹੈ।

4. Authorization ਆਪਣੇ code ਵਿੱਚ ਰੱਖੋ

Signature ਦਾ use ਇਹ ਜਾਣਨ ਲਈ ਕਰੋ ਕਿ ਕੌਣ ਪੁੱਛ ਰਿਹਾ ਹੈ। ਤੁਹਾਡੀਆਂ existing permissions, scopes ਅਤੇ confirmations ਦਾ use ਇਹ decide ਕਰਨ ਲਈ ਕਰੋ ਕਿ ਉਹ ਕੀ ਕਰ ਸਕਦਾ ਹੈ। High-impact actions ਲਈ ਹਾਲੇ ਵੀ human confirmation ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਭਾਵੇਂ request ਕਿਸੇ ਨੇ ਵੀ sign ਕੀਤੀ ਹੋਵੇ। protecting sensitive actions without blocking agents ਵੇਖੋ।

5. Unsigned ਅਤੇ Unknown traffic ਲਈ plan ਕਰੋ

Signing ਲਈ support agents ਅਤੇ tools ਵਿੱਚ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਕੁਝ ਸਮੇਂ ਲਈ signed ਅਤੇ unsigned requests ਦਾ mix ਉਮੀਦ ਕਰੋ। ਇੱਕ site-wide rule ਚੁਣਨ ਦੀ ਬਜਾਇ ਹਰ route ਲਈ decide ਕਰੋ ਕਿ declared, inferred ਅਤੇ Unknown traffic ਨਾਲ ਕੀ ਹੋਵੇਗਾ। handling Unknown traffic ਵਾਲਾ guide ਇਸ ਨੂੰ step by step ਦਿਖਾਉਂਦਾ ਹੈ।

Proof of Actor Web Bot Auth ਦਾ ਕਿਵੇਂ use ਕਰਦਾ ਹੈ

Proof of Actor ਤੁਹਾਡੀ application ਨੂੰ ਹਰ interaction 'ਤੇ ਦੱਸਦਾ ਹੈ ਕਿ ਕੌਣ ਜਾਂ ਕੀ act ਕਰ ਰਿਹਾ ਹੈ, Human, Human + AI, Agent ਜਾਂ Unknown, ਅਤੇ evidence basis ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। Web Bot Auth signatures ਇਸ ਦੇ evidence ਦੇ ਸਭ ਤੋਂ strong sources ਵਿੱਚੋਂ ਇੱਕ ਹਨ।

ਜਦੋਂ ਇੱਕ agent ਆਪਣੀ request ਨੂੰ HTTP Message Signatures ਨਾਲ sign ਕਰਦਾ ਹੈ, Proof of Actor operator ਦੀ published key ਨਾਲ signature check ਕਰਦਾ ਹੈ। ਜੇ check pass ਹੋ ਜਾਵੇ, ਤਾਂ result ਇੱਕ verified basis ਦੇ ਨਾਲ ਆਉਂਦਾ ਹੈ, ਨਾਲ ਹੀ ਉਹ evidence ਜਿਸਨੂੰ ਤੁਹਾਡੀ team review ਕਰ ਸਕਦੀ ਹੈ। ਜੇ ਕੋਈ client ਆਪਣੇ ਆਪ ਨੂੰ ਸਿਰਫ਼ header ਵਿੱਚ ਨਾਮ ਦੇ ਕੇ ਦਰਸਾਉਂਦਾ ਹੈ, ਤਾਂ result declared ਹੁੰਦਾ ਹੈ। ਜੇ conclusion behavioral ਜਾਂ contextual signals 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ inferred label ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜੇ evidence ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ, ਤਾਂ result Unknown ਹੁੰਦਾ ਹੈ।

ਤੁਹਾਡੀ application ਇਸ context ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ, ਇਹ ਖੁਦ decide ਕਰਦੀ ਹੈ। Policies ਹਰ route, ਹਰ actor class ਅਤੇ ਹਰ basis ਲਈ ਲਿਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, outcomes ਜਿਵੇਂ ਕਿ allow, adapt, challenge, review ਅਤੇ rate-limit ਨਾਲ। ਮੂਲ ਰੂਪ ਵਿੱਚ ਕੁਝ ਵੀ enforce ਨਹੀਂ ਹੁੰਦਾ: ਤੁਸੀਂ real traffic ਦੇ ਖਿਲਾਫ ਇੱਕ policy preview ਕਰਦੇ ਹੋ ਅਤੇ route by route, ਆਪਣੇ code ਵਿੱਚ enforce ਕਰਦੇ ਹੋ।

Founding teams Node.js middleware, Next.js, ਇੱਕ edge integration, approved pages 'ਤੇ ਇੱਕ browser collector, generic HTTP API, ਜਾਂ ਇੱਕ MCP server integration ਰਾਹੀਂ evidence collect ਕਰ ਸਕਦੇ ਹਨ। integrations ਵੇਖੋ, ਅਤੇ practical steps ਲਈ verifying signed agent requests ਵਾਲਾ guide ਵੇਖੋ।

Proof of Actor standard ਦੀ ਉਸੀ limit ਦਾ ਪਾਲਣ ਕਰਦਾ ਹੈ: ਇੱਕ verified signature ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ request ਕਿਸ key ਨੇ sign ਕੀਤੀ, ਨਾ ਕਿ agent ਨੂੰ authorization ਹੈ ਜਾਂ ਨਹੀਂ। Authorization ਤੁਹਾਡੇ ਕੋਲ ਹੀ ਰਹਿੰਦੀ ਹੈ। evidence and limits page ਸਪਸ਼ਟ ਕਰਦੀ ਹੈ ਕਿ ਹਰ result ਕੀ support ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ।

ਸ਼ੁਰੂ ਕਰੋ

Proof of Actor private beta ਵਿੱਚ ਹੈ। ਚੁਣੀਆਂ ਗਈਆਂ founding developer teams agreed usage limits ਦੇ ਅੰਦਰ up to 12 months ਲਈ free access ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਬਿਨਾਂ automatic billing ਦੇ। Apply for early access ਕਰੋ ਅਤੇ ਸਾਨੂੰ ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜੇ routes 'ਤੇ signed agents ਦੀ ਉਮੀਦ ਕਰਦੇ ਹੋ ਅਤੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨਾਲ ਕੀ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।

ਡਿਵੈਲਪਰਾਂ ਲਈ

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
ਸਬੂਤ ਕਿੰਨਾ ਮਜ਼ਬੂਤ ਹੈ: verified, declared, inferred ਜਾਂ unknown।
evidence
result ਦੇ ਪਿੱਛੇ ਦੇ signals, ਤਾਂ ਜੋ ਤੁਹਾਡੀ team ਵੇਖ ਸਕੇ ਕਿ ਕਿਉਂ।

observation mode ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ: results ਨੂੰ ਆਪਣੇ logs ਦੇ ਨਾਲ record ਕਰੋ ਅਤੇ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਕੋਈ policy ਨਾ ਚੁਣੋ, ਕੁਝ ਵੀ ਨਾ ਬਦਲੋ। Node.js integration guide ਪੜ੍ਹੋ

ਅਕਸਰ ਪੁੱਛੇ ਜਾਂਦੇ ਸਵਾਲ

Web Bot Auth ਕੀ ਹੈ?

Web Bot Auth IETF working group ਦਾ ਨਾਮ ਹੈ, webbotauth, ਅਤੇ ਉਹ approach ਜਿਸਨੂੰ ਇਹ standardize ਕਰ ਰਿਹਾ ਹੈ: automated clients HTTP Message Signatures (RFC 9421) ਨਾਲ HTTP requests sign ਕਰਦੇ ਹਨ ਅਤੇ ਆਪਣੀਆਂ public keys publish ਕਰਦੇ ਹਨ, ਤਾਂ ਜੋ websites verify ਕਰ ਸਕਣ ਕਿ ਕਿਸ operator ਨੇ request ਭੇਜੀ ਸੀ।

ਕੀ Web Bot Auth ਇੱਕ ਪੂਰਾ standard ਹੈ?

ਹਾਲੇ ਨਹੀਂ। November 2026 ਤੱਕ, main protocol document, draft-ietf-webbotauth-httpsig-protocol, revision 01 'ਤੇ ਇੱਕ working group Internet-Draft ਹੈ। RFC 9421, ਜਿਸ signature format 'ਤੇ ਇਹ ਬਣਿਆ ਹੈ, ਇੱਕ published Proposed Standard ਹੈ।

ਕੀ ਇੱਕ valid Web Bot Auth signature ਦਾ ਮਤਲਬ ਹੈ ਕਿ agent ਨੂੰ act ਕਰਨ ਦੀ ਆਗਿਆ ਹੈ?

ਨਹੀਂ। ਇਹ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੀ key ਨੇ request sign ਕੀਤੀ ਅਤੇ ਇਹ ਕਿ signed parts ਵਿਚ ਕੋਈ ਤਬਦੀਲੀ ਨਹੀਂ ਹੋਈ। ਕੀ ਉਹ agent data ਪੜ੍ਹ ਸਕਦਾ ਹੈ, form submit ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਕਿਸੇ ਖਾਸ user ਲਈ act ਕਰ ਸਕਦਾ ਹੈ, ਇਹ authorization ਦਾ decision ਤੁਹਾਡੀ application ਹੀ ਕਰਦੀ ਹੈ।

ਕੀ product teams ਨੂੰ Web Bot Auth ਖੁਦ implement ਕਰਨ ਦੀ ਲੋੜ ਹੈ?

Sites signatures verify ਕਰਦੀਆਂ ਹਨ; ਉਹਨਾਂ ਨੂੰ ਕੁਝ sign ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਜਦੋਂ ਤੱਕ ਉਹ ਖੁਦ automated clients ਨਾ ਚਲਾਉਣ। Verification ਵਿੱਚ key directories fetch ਕਰਨਾ, ਉਹਨਾਂ ਨੂੰ safely cache ਕਰਨਾ ਅਤੇ signatures check ਕਰਨਾ ਸ਼ਾਮਲ ਹੈ, ਜੋ Proof of Actor ਵਰਗਾ tool ਤੁਹਾਡੇ ਲਈ ਕਰ ਸਕਦਾ ਹੈ।

ਸਾਨੂੰ ਉਹਨਾਂ agents ਨਾਲ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਆਪਣੀਆਂ requests sign ਨਹੀਂ ਕਰਦੇ?

ਉਹਨਾਂ ਨੂੰ ਉਪਲਬਧ evidence ਦੇ ਅਨੁਸਾਰ handle ਕਰੋ: declared, inferred ਜਾਂ Unknown। ਕੁਝ ਸਮੇਂ ਲਈ signed ਅਤੇ unsigned traffic ਦਾ mix ਹੋਣ ਦੀ ਉਮੀਦ ਰੱਖੋ, ਅਤੇ ਇੱਕ site-wide rule ਦੀ ਬਜਾਇ ਹਰ route ਲਈ fallback set ਕਰੋ।

Proof of Actor Web Bot Auth ਨੂੰ ਕਿਵੇਂ use ਕਰਦਾ ਹੈ?

ਇਹ HTTP Message Signatures ਨੂੰ published key ਨਾਲ check ਕਰਦਾ ਹੈ ਅਤੇ, ਜਦੋਂ check pass ਹੋ ਜਾਂਦਾ ਹੈ, ਨਤੀਜੇ ਨੂੰ verified basis ਨਾਲ report ਕਰਦਾ ਹੈ। ਫਿਰ ਤੁਹਾਡੀਆਂ policies verified agents ਨੂੰ declared ਜਾਂ Unknown traffic ਤੋਂ ਵੱਖਰਾ treat ਕਰ ਸਕਦੀਆਂ ਹਨ।

ਜਾਣੋ ਤੁਹਾਡਾ app ਕੌਣ ਵਰਤ ਰਿਹਾ ਹੈ।

Founding developers ਦੇ ਇੱਕ ਛੋਟੇ group ਲਈ private beta।

ਅਗਾਊਂ ਪਹੁੰਚ ਲਵੋਕੀਮਤ ਵੇਖੋ

ਪਹਿਲਾਂ ਗੱਲ ਕਰਨੀ ਪਸੰਦ ਕਰੋਗੇ? founders ਨਾਲ ਗੱਲ ਕਰੋ