ਪੁਸ਼ਟੀਤ ਆਟੋਮੇਸ਼ਨ

ਪੁਸ਼ਟੀਤ ਆਟੋਮੇਟਡ ਬੇਨਤੀਆਂ ਨੂੰ ਪਛਾਣੋ

ਜਦੋਂ ਕੋਈ ਆਟੋਮੇਟਡ client ਆਪਣੀਆਂ ਬੇਨਤੀਆਂ 'ਤੇ signature ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ application ਉਸ signature ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ caller ਨਾਲ ਉਸੇ ਮੁਤਾਬਕ ਵਤੀਰਾ ਕਰ ਸਕਦੀ ਹੈ। Proof of Actor ਉਸ ਜਾਂਚ ਨੂੰ ਇੱਕ ਸਪੱਸ਼ਟ, route ਕਰਨ ਯੋਗ ਨਤੀਜੇ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।

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

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

ਸਾਰੀ ਆਟੋਮੇਟਡ traffic ਇੱਕੋ ਜਿਹੀ ਨਹੀਂ ਹੁੰਦੀ

ਆਟੋਮੇਟਡ clients ਹਰ ਮਿੰਟ ਤੁਹਾਡੀ application ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ: search crawlers, monitoring tools, partner integrations, ਕਿਸੇ user ਲਈ pages ਲਿਆਉਣ ਵਾਲੇ AI assistants, ਅਤੇ ਕਾਰਜ ਪੂਰੇ ਕਰਨ ਵਾਲੇ autonomous agents। ਸਾਲਾਂ ਤੱਕ, ਜ਼ਿਆਦਾਤਰ applications ਲਈ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਫ਼ਰਕ ਪਛਾਣਨ ਦਾ ਇਕੱਲਾ ਤਰੀਕਾ user-agent header ਸੀ, ਇੱਕ ਐਸੀ string ਜੋ ਕੋਈ ਵੀ client ਕਿਸੇ ਵੀ value ਨਾਲ set ਕਰ ਸਕਦਾ ਹੈ।

ਇਸ ਨਾਲ application teams ਇਕ ਮੁਸ਼ਕਲ ਹਾਲਤ ਵਿੱਚ ਫਸ ਜਾਂਦੀਆਂ ਹਨ। ਸਾਰੀ automation 'ਤੇ ਸ਼ੱਕ ਕਰੋ, ਅਤੇ ਤੁਸੀਂ ਆਪਣੇ customers ਦੇ ਨਿਰਭਰ legitimate agents ਦਾ experience ਖ਼ਰਾਬ ਕਰ ਦਿੰਦੇ ਹੋ। Header 'ਤੇ ਭਰੋਸਾ ਕਰੋ, ਅਤੇ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਨੂੰ ਕਿਸੇ ਮਸ਼ਹੂਰ crawler ਹੋਣ ਦਾ ਦਾਅਵਾ ਕਰਨ ਲਈ ਸੱਦਾ ਦੇ ਦਿੰਦੇ ਹੋ।

ਪੁਸ਼ਟੀਤ ਆਟੋਮੇਟਡ ਬੇਨਤੀਆਂ ਇਸ ਸਮੀਕਰਨ ਨੂੰ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ। ਜਦੋਂ ਕੋਈ ਆਟੋਮੇਟਡ client ਆਪਣੀਆਂ ਬੇਨਤੀਆਂ 'ਤੇ ਉਹ key ਵਰਤ ਕੇ signature ਕਰਦਾ ਹੈ ਜੋ ਉਸ ਨੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤੀ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ application signature ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ cryptographically ਜਾਣ ਸਕਦੀ ਹੈ ਕਿ ਕਿਸ client ਨੇ ਬੇਨਤੀ 'ਤੇ signature ਕੀਤੀ। Proof of Actor ਉਸ ਜਾਂਚ ਨੂੰ ਇੱਕ ਹੀ, ਸਥਿਰ actor ਨਤੀਜੇ ਦਾ ਹਿੱਸਾ ਬਣਾਉਂਦਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਹਾਡਾ code route ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਜਾਂਚ ਕੀ ਸਥਾਪਤ ਕਰਦੀ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ, ਇਸ ਨੂੰ ਹੋਰ ਨੇੜੇ ਤੋਂ ਦੇਖਣ ਲਈ signed AI agent requests ਕੀ ਸਾਬਤ ਕਰਦੀਆਂ ਹਨ ਪੜ੍ਹੋ।

request signing ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

ਆਟੋਮੇਟਡ traffic ਲਈ ਉਭਰਦਾ ਹੋਇਆ ਤਰੀਕਾ HTTP message signatures ਵਰਤਦਾ ਹੈ, ਜੋ RFC 9421 ਵਿੱਚ ਮਿਆਰੀਕ੍ਰਿਤ ਹੈ, ਅਤੇ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ HTTP message ਦੇ components ਉੱਤੇ signatures ਕਿਵੇਂ ਬਣਾਉਣੀਆਂ, encode ਕਰਣੀਆਂ ਅਤੇ verify ਕਰਣੀਆਂ ਹਨ। client ਹਰ ਬੇਨਤੀ ਦੇ ਚੁਣੇ ਹੋਏ ਹਿੱਸਿਆਂ 'ਤੇ private key ਨਾਲ signature ਕਰਦਾ ਹੈ ਅਤੇ headers ਵਿੱਚ signature ਅਤੇ ਉਸਦੇ parameters ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ। ਇਹ ਉਸ identifier ਨਾਲ ਜੁੜੇ ਸਥਾਨ 'ਤੇ ਸੰਬੰਧਿਤ public key ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਇਸਦਾ ਕੰਟਰੋਲ ਹੁੰਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਉਸਦਾ domain।

ਜਦੋਂ ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ, receiver ਪ੍ਰਕਾਸ਼ਿਤ key ਨੂੰ fetch ਜਾਂ lookup ਕਰਦਾ ਹੈ, signed ਸਮੱਗਰੀ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ signature ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਜੇ ਇਹ validate ਹੋ ਜਾਵੇ, ਤਾਂ ਬੇਨਤੀ ਉਸ key ਦੇ holder ਵੱਲੋਂ signed ਸੀ। ਆਟੋਮੇਟਡ traffic 'ਤੇ signature ਕਰਨ ਦਾ ਕੰਮ 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 ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਸਮਝਾਉਂਦੀ ਹੈ, ਅਤੇ APIs use case ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ verification ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕਿੱਥੇ ਲਾਭਦਾਇਕ ਹੁੰਦੀ ਹੈ।

verifying signed agent requests ਵਾਲਾ guide mechanics ਨੂੰ ਵਿਸਥਾਰ ਨਾਲ ਕਵਰ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ timestamps, replay windows ਅਤੇ key caching ਸ਼ਾਮਲ ਹਨ।

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

ਇਹ ਫ਼ਰਕ verified automated requests ਨੂੰ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਣ ਦਾ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਹੈ।

ਇੱਕ valid signature ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਬੇਨਤੀ ਉਸ key ਨਾਲ signed ਕੀਤੀ ਗਈ ਸੀ ਜੋ ਪ੍ਰਕਾਸ਼ਿਤ identifier ਨਾਲ ਜੁੜੀ ਹੋਈ ਹੈ। ਜੇ key ਕਿਸੇ operator ਦੇ domain ਦੀ ਹੈ, ਤਾਂ ਬੇਨਤੀ ਉਸ client ਤੋਂ ਆਈ ਜਿਸ ਕੋਲ ਉਸ operator ਦੀ key ਸੀ।

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

ਕਿਸ ਨੇ agent ਨੂੰ ਹਦਾਇਤ ਦਿੱਤੀ, ਜਾਂ ਕੀ ਕਿਸੇ person ਨੇ ਇਸ action ਲਈ ਬੇਨਤੀ ਕੀਤੀ ਸੀ;
ਕਿ ਕਿਸੇ person ਨੇ agent ਨੂੰ authority ਸੌਂਪੀ ਸੀ;
operator ਦੇ ਪਿੱਛੇ ਮੌਜੂਦ ਅਸਲ-ਜਗਤ ਦੀ ਕਾਨੂੰਨੀ ਪਛਾਣ;
ਕਿ ਮੰਗਿਆ ਗਿਆ action ਤੁਹਾਡੀ application ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਜਾਂ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਹੈ।

ਇਹ ਵੱਖ-ਵੱਖ ਸਵਾਲ ਹਨ। ਤੁਹਾਡੀ application ਉਨ੍ਹਾਂ ਦਾ ਜਵਾਬ ਆਪਣੀਆਂ credentials, authorization model ਅਤੇ policy ਨਾਲ ਦਿੰਦੀ ਹੈ। Proof of Actor ਉਨ੍ਹਾਂ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਵੱਖ ਰੱਖਦਾ ਹੈ, ਅਤੇ Detection & Limitations ਵਾਲਾ page ਸਪੱਸ਼ਟ ਕਰਦਾ ਹੈ ਕਿ ਹਰ ਕਿਸਮ ਦਾ evidence ਕੀ ਸਥਾਪਤ ਕਰ ਸਕਦਾ ਹੈ।

Proof of Actor verified automated requests ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦਾ ਹੈ

Detect

ਤੁਹਾਡੀ integration request context, ਜਿਸ ਵਿੱਚ ਕੋਈ ਵੀ signature headers ਸ਼ਾਮਲ ਹਨ, Proof of Actor ਨੂੰ ਭੇਜਦੀ ਹੈ। Signatures ਨੂੰ published keys ਦੇ ਮੁਕਾਬਲੇ ਜਾਂਚਿਆ ਜਾਂਦਾ ਹੈ। ਜੋ requests validate ਹੁੰਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਨੂੰ verified ਆਧਾਰ ਨਾਲ ਦਰਜ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜੋ clients ਸਿਰਫ਼ ਆਪਣੇ ਆਪ ਨੂੰ ਨਾਮ ਦਿੰਦੇ ਹਨ, ਉਹ declared ਵਜੋਂ ਦਰਜ ਹੁੰਦੇ ਹਨ। ਵਿਹਾਰਕ patterns inferred ਵਜੋਂ ਦਰਜ ਹੁੰਦੇ ਹਨ। ਜਦੋਂ ਅੱਗੇ ਵਧਣ ਲਈ ਕਾਫ਼ੀ evidence ਨਹੀਂ ਹੁੰਦੀ, ਤਾਂ ਨਤੀਜਾ Unknown ਹੁੰਦਾ ਹੈ। ਜਦ ਤੱਕ ਕੋਈ cryptographic check pass ਨਹੀਂ ਹੁੰਦੀ, ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ verified ਨਹੀਂ ਬਣਾਇਆ ਜਾਂਦਾ।

Understand

ਦੇਖੋ ਕਿਹੜੇ verified operators ਤੁਹਾਡੀ application ਨੂੰ call ਕਰਦੇ ਹਨ, ਕਿਹੜੇ routes ਉਹ ਵਰਤਦੇ ਹਨ, ਕਿੰਨੀ ਵਾਰ, ਅਤੇ ਇਹ declared ਅਤੇ unknown automation ਨਾਲ ਕਿਵੇਂ ਤੁਲਨਾ ਕਰਦਾ ਹੈ। ਹਰ ਨਤੀਜੇ 'ਤੇ ਦਿੱਤਾ evidence summary ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜੀ key ਅਤੇ identifier ਸ਼ਾਮਲ ਸਨ, ਤਾਂ ਜੋ ਤੁਹਾਡੀ team ਕਿਸੇ ਵੀ ਬੇਨਤੀ ਦੀ ਤੇਜ਼ੀ ਨਾਲ ਜਾਂਚ ਕਰ ਸਕੇ।

Route

ਆਪਣੀਆਂ policies ਵਿੱਚ ਆਧਾਰ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਆਮ patterns ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

verified agents ਨੂੰ read-only routes 'ਤੇ ਇੱਕ structured response ਦਿਓ, ਜਿਵੇਂ ਕੋਈ API ਜਾਂ page ਦਾ Markdown version।
ਜਿਨ੍ਹਾਂ verified operators ਨੂੰ ਤੁਸੀਂ ਪਛਾਣਦੇ ਹੋ, ਉਨ੍ਹਾਂ ਲਈ rate limits ਵਧਾਓ, ਜਦਕਿ declared clients ਲਈ standard limits ਕਾਇਮ ਰੱਖੋ।
ਹਰ write route 'ਤੇ ਆਪਣੀ ਮੌਜੂਦਾ authorization ਬਰਕਰਾਰ ਰੱਖੋ, signature ਜੋ ਵੀ ਕਹੇ।
ਹਰ route ਲਈ unsigned ਅਤੇ Unknown callers ਲਈ ਇੱਕ ਸਪੱਸ਼ਟ fallback ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ।

ਫੈਸਲਾ ਤੁਹਾਡੀਆਂ policies ਕਰਦੀਆਂ ਹਨ; Proof of Actor evidence ਦਿੰਦਾ ਹੈ।

user-agent header ਕਿਉਂ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ

User-agent strings declarations ਹੁੰਦੀਆਂ ਹਨ। ਕੋਈ ਵੀ client ਕੋਈ ਵੀ value ਭੇਜ ਸਕਦਾ ਹੈ, ਅਤੇ user-agent spoofing ਲਈ ਕੋਈ skill ਨਹੀਂ ਚਾਹੀਦੀ। ਇਸੀ ਲਈ crawler operators ਆਪਣੀਆਂ checks ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹਨ: Google Googlebot ਦੀ verification ਲਈ reverse ਅਤੇ forward DNS lookups ਅਤੇ ਪ੍ਰਕਾਸ਼ਿਤ IP ranges ਦਾ ਵੇਰਵਾ ਦਿੰਦਾ ਹੈ, Bing Bingbot ਦੀ verification ਲਈ ਇੱਕ DNS check ਦਾ ਵੇਰਵਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ OpenAI ਆਪਣੇ ਹਰ crawlers ਅਤੇ user agents ਲਈ IP range files ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। Proof of Actor user-agent claim ਨੂੰ declared evidence ਮੰਨਦਾ ਹੈ, verification ਕਦੇ ਨਹੀਂ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜੇ ਕੋਈ client valid signature ਦੇ ਬਿਨਾਂ ਆਪਣੇ ਆਪ ਨੂੰ ਕਿਸੇ ਮਸ਼ਹੂਰ crawler ਵਜੋਂ ਦਾਅਵਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ declared ਜਾਂ inferred ਆਧਾਰ ਨਾਲ report ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ policy ਉਸਨੂੰ ਉਸ client ਤੋਂ ਵੱਖਰਾ ਸੰਭਾਲ ਸਕਦੀ ਹੈ ਜਿਸ ਨੇ ਆਪਣੀ ਪਛਾਣ ਸਾਬਤ ਕੀਤੀ ਹੈ।

ਇਹੀ ਗੱਲ verified automated requests ਨੂੰ ਕੀਮਤੀ ਬਣਾਉਂਦੀ ਹੈ: ਇਹ ਤੁਹਾਨੂੰ ਉਹਨਾਂ clients ਤੱਕ ਭਰੋਸਾ ਵਧਾਉਣ ਦਾ ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ ਦਿੰਦੀਆਂ ਹਨ ਜੋ ਇਹ ਭਰੋਸਾ ਕਮਾਉਂਦੇ ਹਨ, ਬਿਨਾਂ ਇਸਨੂੰ ਹਰ ਉਸ ਵਿਅਕਤੀ ਤੱਕ ਫੈਲਾਏ ਜੋ ਉਨ੍ਹਾਂ ਦਾ header ਕਾਪੀ ਕਰ ਲੈਂਦਾ ਹੈ।

identity evidence, credentials ਅਤੇ authorization

ਕਿਸੇ ਵੀ application ਵਿੱਚ ਜੋ automated clients ਨੂੰ ਸੇਵਾ ਦਿੰਦੀ ਹੈ, ਤਿੰਨ layers ਇਕੱਠੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ:

Identity evidence: ਇਸ ਬੇਨਤੀ 'ਤੇ ਕਿਸ client ਨੇ signature ਕੀਤੀ? ਇੱਕ verified signature ਇਸਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ।
Credentials: ਕਿਹੜਾ account ਜ਼ਿੰਮੇਵਾਰ ਹੈ? ਤੁਹਾਡੀ API key, token ਜਾਂ session ਇਸਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ।
Authorization: ਕੀ ਇਹ caller ਇਹ ਕਰ ਸਕਦਾ ਹੈ? ਤੁਹਾਡਾ permission model ਇਸਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।

Proof of Actor ਪਹਿਲੀ layer ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਦਿੱਖਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ identity ਜਾਂ delegation credentials ਜਾਰੀ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇਹ ਤੁਹਾਡੀ authorization ਨੂੰ replace ਨਹੀਂ ਕਰਦਾ। Layers ਨੂੰ ਵੱਖ-ਵੱਖ ਰੱਖਣਾ ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਤੁਹਾਨੂੰ low-risk routes 'ਤੇ verified agents ਨਾਲ ਖੁੱਲ੍ਹਾ ਅਤੇ high-impact ones 'ਤੇ ਸਾਵਧਾਨ ਬਣਾਉਂਦੀ ਹੈ।

ਇਹ ਕਿੱਥੇ ਫਿੱਟ ਹੁੰਦਾ ਹੈ

Proof of Actor ਤੁਹਾਡੇ gateway, authentication ਅਤੇ rate limiting ਦੇ ਨਾਲ-ਨਾਲ ਬੈਠਦਾ ਹੈ। Integrations server-side middleware ਵਜੋਂ, edge 'ਤੇ, ਤੁਹਾਡੇ MCP server ਵਿੱਚ ਜਾਂ generic HTTP integration ਰਾਹੀਂ ਚਲਦੀਆਂ ਹਨ, ਜੋ ਹਰ founding team ਨਾਲ ਹੱਥੋਂ-ਹੱਥ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਜੇ ਤੁਹਾਡਾ traffic ਜ਼ਿਆਦਾਤਰ APIs ਅਤੇ tools ਦਾ ਹੈ, ਤਾਂ APIs ਅਤੇ MCP Servers use cases ਉਹ patterns ਦਿਖਾਉਂਦੇ ਹਨ ਜੋ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹਨ।

observation mode ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ

ਹਰ integration observation mode ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਨਤੀਜੇ ਇਸ ਗੱਲ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਦਰਜ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਕਿ ਤੁਹਾਡੀ application ਕਿਵੇਂ respond ਕਰਦੀ ਹੈ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਦੇਖ ਸਕੋ ਕਿ ਤੁਹਾਡੇ ਆਟੋਮੇਟਡ traffic ਦਾ ਕਿੰਨਾ ਹਿੱਸਾ verified ਹੈ, ਕਿਹੜੇ operators signature ਕਰ ਰਹੇ ਹਨ, ਅਤੇ unknown rate ਸਭ ਤੋਂ ਉੱਚਾ ਕਿੱਥੇ ਹੈ। Policies ਬਾਅਦ ਵਿੱਚ, route ਦਰ route, ਜਦ evidence ਉਨ੍ਹਾਂ ਨੂੰ support ਕਰਦਾ ਹੈ, ਆਉਂਦੀਆਂ ਹਨ। How It Works ਪੂਰੇ flow ਨੂੰ ਸਮਝਾਉਂਦਾ ਹੈ।

practical details ਜੋ verification ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ

Signature checking ਸਿਰਫ਼ ਉਨ੍ਹਾਂ details ਜਿੰਨੀ ਹੀ ਚੰਗੀ ਹੁੰਦੀ ਹੈ ਜੋ ਉਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਹਨ। ਕੁਝ practices verified automated requests ਨੂੰ production ਵਿੱਚ dependable ਬਣਾਉਂਦੀਆਂ ਹਨ।

freshness ਦੀ ਜਾਂਚ ਕਰੋ

RFC 9421 created ਅਤੇ expires signature parameters define ਕਰਦਾ ਹੈ, ਅਤੇ signed requests ਆਮ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਨੂੰ carry ਕਰਦੀਆਂ ਹਨ। Short window ਤੋਂ ਬਾਹਰ signatures reject ਕਰੋ, ਤਾਂ ਜੋ captured request ਨੂੰ ਬਾਅਦ ਵਿੱਚ replay ਨਾ ਕੀਤਾ ਜਾ ਸਕੇ।

keys ਨੂੰ ਸਮਝਦਾਰੀ ਨਾਲ cache ਕਰੋ

ਹਰ request 'ਤੇ operator ਦੀਆਂ ਪ੍ਰਕਾਸ਼ਿਤ keys fetch ਕਰਨ ਨਾਲ latency ਵਧਦੀ ਹੈ। ਉਨ੍ਹਾਂ ਨੂੰ ਵਾਜਬ ਸਮੇਂ ਲਈ cache ਕਰੋ ਅਤੇ ਜਦ ਕੋਈ signature unknown key identifier ਨਾਲ fail ਹੋਵੇ ਤਾਂ refresh ਕਰੋ, ਤਾਂ ਜੋ key rotation false failures ਦਾ ਕਾਰਨ ਨਾ ਬਣੇ।

request ਦੇ ਸਹੀ ਹਿੱਸਿਆਂ 'ਤੇ signature ਕਰੋ

ਕੇਵਲ timestamp ਨੂੰ cover ਕਰਨ ਵਾਲੀ signature ਬਹੁਤ ਘੱਟ ਸਾਬਤ ਕਰਦੀ ਹੈ। ਜਾਂਚ ਕਰੋ ਕਿ signed components ਵਿੱਚ method, path ਅਤੇ host ਸ਼ਾਮਲ ਹੋਣ, ਤਾਂ ਜੋ signature ਉਸ request ਨਾਲ ਜੁੜੇ ਜਿਸੇ ਤੁਹਾਡੀ application ਨੇ ਵਾਸਤਵ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕੀਤਾ ਸੀ।

evidence ਦਰਜ ਕਰੋ

ਹਰ verified request ਨਾਲ key identifier, ਪ੍ਰਕਾਸ਼ਿਤ identifier ਅਤੇ ਨਤੀਜਾ ਰੱਖੋ। ਜਦ ਕੁਝ ਅਸਧਾਰਣ ਹੁੰਦਾ ਹੈ, ਤੁਹਾਡੀ team ਸਹੀ ਤੌਰ 'ਤੇ ਦੇਖ ਸਕਦੀ ਹੈ ਕਿ ਕਿਸ client ਨੇ ਕੀ ਅਤੇ ਕਦੋਂ signed ਕੀਤਾ।

Proof of Actor ਇਹ checks Detect step ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਸੰਭਾਲਦਾ ਹੈ ਅਤੇ outcome ਨੂੰ ਉਸ ਆਧਾਰ ਵਜੋਂ report ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੀਆਂ policies ਪੜ੍ਹ ਸਕਦੀਆਂ ਹਨ, ਤਾਂ ਜੋ ਤੁਹਾਡਾ application code ਸਧਾਰਣ ਰਹੇ।

founding developer program ਨਾਲ ਜੁੜੋ

Proof of Actor private beta ਵਿੱਚ ਹੈ। ਚੁਣੀਆਂ ਗਈਆਂ founding development teams agreed usage limits ਦੇ ਅੰਦਰ 12 months ਤੱਕ ਮੁਫ਼ਤ access ਲੈ ਸਕਦੀਆਂ ਹਨ, ਸਾਡੇ engineers ਵੱਲੋਂ direct integration support ਦੇ ਨਾਲ।

ਜੇ ਆਟੋਮੇਟਡ clients ਤੁਹਾਡੀ application ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ ਅਤੇ ਤੁਸੀਂ verified ones ਨਾਲ ਵੱਖਰਾ ਵਤੀਰਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ early access ਲਈ ਅਰਜ਼ੀ ਦਿਓ। ਸਾਨੂੰ ਆਪਣੀ application ਅਤੇ ਉਹ automated callers ਬਾਰੇ ਦੱਸੋ ਜੋ ਤੁਸੀਂ ਵੇਖਦੇ ਹੋ, ਅਤੇ ਅਸੀਂ ਤੁਹਾਨੂੰ ਦਿਖਾਵਾਂਗੇ ਕਿ Proof of Actor ਕਿਵੇਂ fit ਹੁੰਦਾ ਹੈ।

ਸਰੋਤ

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

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

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

ਪੁਸ਼ਟੀਤ ਆਟੋਮੇਟਡ ਬੇਨਤੀ ਕੀ ਹੁੰਦੀ ਹੈ?

ਇਹ ਇੱਕ ਆਟੋਮੇਟਡ client ਤੋਂ ਆਈ ਬੇਨਤੀ ਹੁੰਦੀ ਹੈ ਜਿਸ ਦੀ cryptographic signature ਕਿਸੇ ਜਾਣੇ-ਪਹਿਚਾਣੇ identifier, ਜਿਵੇਂ operator ਦੇ domain, ਲਈ ਪ੍ਰਕਾਸ਼ਿਤ key ਨਾਲ validate ਹੁੰਦੀ ਹੈ। ਇਹ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕਿਸ client ਨੇ ਬੇਨਤੀ 'ਤੇ signature ਕੀਤੀ ਸੀ।

ਕੀ ਪੁਸ਼ਟੀਤ signature ਦਾ ਮਤਲਬ ਹੈ ਕਿ agent authorized ਹੈ?

ਨਹੀਂ। Signature ਬੇਨਤੀ ਨੂੰ ਇੱਕ key ਅਤੇ ਉਸਦੇ ਪ੍ਰਕਾਸ਼ਿਤ identifier ਨਾਲ ਜੋੜਦੀ ਹੈ। ਕੀ ਉਹ client ਕੋਈ action ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਤੁਹਾਡੀ application ਵੱਲੋਂ ਲਿਆ ਗਿਆ ਇੱਕ ਵੱਖਰਾ authorization ਫੈਸਲਾ ਹੁੰਦਾ ਹੈ।

ਉਨ੍ਹਾਂ ਆਟੋਮੇਟਡ clients ਬਾਰੇ ਕੀ ਜੋ ਆਪਣੀਆਂ ਬੇਨਤੀਆਂ 'ਤੇ signature ਨਹੀਂ ਕਰਦੇ?

Proof of Actor ਫਿਰ ਵੀ ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਗੀਕ੍ਰਿਤ ਕਰਦਾ ਹੈ, ਜਿੱਥੇ ਉਪਲਬਧ ਹੋਵੇ ਉੱਥੇ declared ਅਤੇ inferred evidence ਵਰਤਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ evidence ਕਾਫ਼ੀ ਮਜ਼ਬੂਤ ਨਹੀਂ ਹੁੰਦੀ ਤਾਂ Unknown ਦਰਸਾਉਂਦਾ ਹੈ। ਹਰ ਨਤੀਜਾ ਆਪਣਾ ਆਧਾਰ ਦੱਸਦਾ ਹੈ।

ਕੀ user-agent string ਕਿਸੇ client ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੀ ਹੈ?

ਨਹੀਂ। User-agent strings ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਨਕਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਉਹ declaration ਮੰਨੀ ਜਾਂਦੀ ਹੈ, verification ਨਹੀਂ। Cryptographic signatures ਹੀ ਕਿਸੇ ਬੇਨਤੀ ਨੂੰ verify ਕਰਨ ਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ।

ਮੈਂ ਸ਼ੁਰੂ ਕਿਵੇਂ ਕਰਾਂ?

early access ਲਈ ਅਰਜ਼ੀ ਦਿਓ। Founding teams observation mode ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ ਅਤੇ ਚੁਣੀਆਂ ਗਈਆਂ teams ਨੂੰ agreed usage limits ਦੇ ਅੰਦਰ 12 months ਤੱਕ ਮੁਫ਼ਤ ਮਿਲ ਸਕਦਾ ਹੈ।

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

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

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

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