ਤੁਲਨਾ

Proof of Actor ਬਨਾਮ 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 ਕੋਈ ਵੀ ਨਾਮ ਲਿਖ ਸਕਦਾ ਹੈ। Reverse DNS ਅਤੇ published IP ranges ਕੁਝ operators ਲਈ ਅਸਲ evidence ਜੋੜਦੇ ਹਨ, ਪਰ ਸਿਰਫ਼ ਉਹਨਾਂ ਲਈ ਜੋ ਇਹਨਾਂ ਨੂੰ publish ਕਰਦੇ ਹਨ। Proof of Actor header ਨੂੰ ਇੱਕ declaration ਮੰਨਦਾ ਹੈ, ਜਿੱਥੇ agents ਆਪਣੀਆਂ requests sign ਕਰਦੇ ਹਨ ਉੱਥੇ signatures ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ evidence ਕਮਜ਼ੋਰ ਹੁੰਦਾ ਹੈ ਤਾਂ Unknown ਦਰਜ ਕਰਦਾ ਹੈ, ਤਾਂ ਜੋ ਤੁਹਾਡਾ code facts ਦੇ ਆਧਾਰ 'ਤੇ ਫੈਸਲਾ ਕਰੇ।

User agent allowlist web ਦੇ ਸਭ ਤੋਂ ਪੁਰਾਣੇ patterns ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਤੁਸੀਂ ਉਹਨਾਂ crawler ਅਤੇ client names ਦੀ ਸੂਚੀ ਰੱਖਦੇ ਹੋ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰਦੇ ਹੋ। ਜਦੋਂ ਇੱਕ request ਮਿਲਦੀ ਹੈ ਜਿਸਦਾ User-Agent header ਮਿਲਦਾ ਹੈ, ਤੁਸੀਂ ਉਸਨੂੰ ਅੱਗੇ ਜਾਣ ਦਿੰਦੇ ਹੋ, challenge ਛੱਡ ਦਿੰਦੇ ਹੋ, ਜਾਂ ਉਸਨੂੰ ਹਲਕਾ page serve ਕਰਦੇ ਹੋ। ਇਸਨੂੰ set up ਕਰਨ ਵਿੱਚ ਮਿੰਟ ਲੱਗਦੇ ਹਨ ਅਤੇ team ਵਿੱਚ ਹਰ ਕਿਸੇ ਨੂੰ ਇਹ ਸਮਝ ਆ ਜਾਂਦਾ ਹੈ।

ਇਹ pattern ਉਸ ਵੇਲੇ ਵੱਧ ਅਰਥਪੂਰਨ ਸੀ ਜਦੋਂ ਮੁੱਖ automated visitors ਕੁਝ search crawlers ਅਤੇ ਕੁਝ monitoring tools ਤੱਕ ਸੀਮਤ ਸਨ। ਅੱਜ, AI agents, assistants ਅਤੇ automated clients ਵੱਧਦੀ ਗਿਣਤੀ ਵਿੱਚ applications ਤੱਕ ਪਹੁੰਚ ਰਹੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕਈ ਇੱਕ ਨਾਮ ਦੱਸਦੇ ਹਨ। ਉਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਨਾਮ ਅਸਲ ਹੁੰਦੇ ਹਨ। ਕੁਝ copied ਹੁੰਦੇ ਹਨ। Header ਤੁਹਾਨੂੰ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਕਿਹੜਾ ਹੈ।

Proof of Actor ਇੱਕ ਵੱਖਰਾ approach ਲੈਂਦਾ ਹੈ। ਇਹ User-Agent string ਨੂੰ ਉਸੇ ਰੂਪ ਵਿੱਚ ਲੈਂਦਾ ਹੈ ਜਿਵੇਂ ਇਹ ਹੈ, ਇੱਕ declaration, ਅਤੇ ਜਦੋਂ ਹੋਰ evidence ਮੌਜੂਦ ਹੋਵੇ ਤਾਂ ਉਸਨੂੰ ਉਸ evidence ਦੇ ਨਾਲ ਦਰਜ ਕਰਦਾ ਹੈ। ਇਹ page ਨਾਮ ਦੇ ਆਧਾਰ 'ਤੇ allowlisting ਦੀਆਂ ਸੀਮਾਵਾਂ, network-level checks ਕਿੱਥੇ ਮਦਦ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ verified signatures ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ Unknown class picture ਨੂੰ ਕਿਵੇਂ ਬਦਲਦੇ ਹਨ, ਇਹ ਸਮਝਾਉਂਦੀ ਹੈ।

ਸੰਖੇਪ ਵਰਜਨ

	User agent allowlist	Proof of Actor
ਮੁੱਖ evidence	User-Agent header ਵਿੱਚ ਇੱਕ ਨਾਮ	Signatures, declarations ਅਤੇ signals, ਹਰ ਇੱਕ ਆਪਣੀ basis ਨਾਲ labeled
ਕੀ client ਇਸਨੂੰ ਨਕਲੀ ਬਣਾ ਸਕਦਾ ਹੈ?	ਹਾਂ, ਉਹੀ string ਭੇਜ ਕੇ	ਇੱਕ declared basis ਦਾ ਦਾਅਵਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ; ਇੱਕ verified basis ਲਈ signing key ਲੋੜੀਂਦੀ ਹੈ
Output	ਸੂਚੀ ਵਿੱਚ ਜਾਂ ਨਹੀਂ	Human, Human + AI, Agent ਜਾਂ Unknown, ਨਾਲ ਹੀ ਇੱਕ basis
ਅਸਪਸ਼ਟ traffic	Not allowlisted ਵਜੋਂ treated, ਜਾਂ default ਤੌਰ 'ਤੇ allowed	Unknown, ਇੱਕ fallback ਨਾਲ ਜੋ ਤੁਸੀਂ ਹਰ route ਲਈ ਚੁਣਦੇ ਹੋ
AI ਦੀ ਮਦਦ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲੇ ਲੋਕ	ਅਦ੍ਰਿਸ਼ਯ; ਉਹ ਆਮ browsers ਵਰਤਦੇ ਹਨ	ਇੱਕ ਵੱਖਰਾ class, Human + AI, ਜਦੋਂ declared ਜਾਂ observed ਹੋਵੇ
ਰੱਖ-ਰਖਾਅ	ਨਾਮ ਬਦਲਣ 'ਤੇ manual list updates	Agent operators ਵਲੋਂ published keys; policies ਤੁਹਾਡੇ code ਵਿੱਚ
Install ਕਰਨ 'ਤੇ default	ਸੂਚੀ ਜੋ ਵੀ allow ਕਰੇ	Observation; ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ policy ਨਹੀਂ ਜੋੜਦੇ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ
ਸਭ ਤੋਂ ਵਧੀਆ	ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਰਤਣ ਵਾਲੇ, ਜਾਣੇ-ਪਛਾਣੇ clients ਦੀ cheap routing	Product ਅਤੇ policy decisions ਲਈ evidence-based actor context

ਬਾਕੀ page ਹਰ row ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ।

User-Agent ਦੇ ਆਧਾਰ 'ਤੇ allowlisting ਕਿਉਂ spoofable ਹੈ

User-Agent header client ਵਲੋਂ set ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੱਕ browser ਇਹ set ਕਰਦਾ ਹੈ, ਇੱਕ script ਇਹ set ਕਰਦੀ ਹੈ, ਅਤੇ ਇੱਕ agent framework ਇਹ set ਕਰਦਾ ਹੈ। HTTP ਵਿੱਚ ਕੋਈ ਵੀ ਚੀਜ਼ ਇਹ ਨਹੀਂ ਜਾਂਚਦੀ ਕਿ value ਸੱਚੀ ਹੈ। ਜੇ ਤੁਹਾਡੀ allowlist ਇੱਕ string 'ਤੇ ਭਰੋਸਾ ਕਰਦੀ ਹੈ, ਤਾਂ ਜੋ ਕੋਈ ਵੀ ਉਹੀ string ਕਾਪੀ ਕਰੇ, ਉਸਨੂੰ ਉਹੀ treatment ਮਿਲਦਾ ਹੈ।

ਇਸਨੂੰ user agent spoofing ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਇੱਕ ਸਧਾਰਣ ਕਾਰਨ ਕਰਕੇ ਆਮ ਹੈ: ਇਸ ਦੀ ਕੀਮਤ ਕੁਝ ਨਹੀਂ। ਇੱਕ scraper ਜੋ challenge ਤੋਂ ਬਚਣਾ ਚਾਹੁੰਦਾ ਹੈ, ਉਸਨੂੰ ਸਿਰਫ਼ ਉਸ crawler ਦਾ ਨਾਮ ਉਧਾਰ ਲੈਣਾ ਹੁੰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰਦੇ ਹੋ। ਇੱਕ ਗਲਤ ਵਰਤਾਉ ਵਾਲਾ client ਦਾਅਵਾ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਉਹ ਇੱਕ popular assistant ਹੈ। ਇੱਕ legitimate tool ਵੀ generic browser string ਭੇਜ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇੱਕ library default ਨੇ ਇਹ ਕੀਤਾ ਸੀ।

ਨਤੀਜਾ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਇੱਕ user agent allowlist ਦੇ ਦੋ failure modes ਹੁੰਦੇ ਹਨ:

False trust: ਇੱਕ untrusted client ਇੱਕ trusted ਨਾਮ ਦਾ ਦਾਅਵਾ ਕਰਦਾ ਹੈ ਅਤੇ ਪਾਰ ਹੋ ਜਾਂਦਾ ਹੈ।
False doubt: ਇੱਕ legitimate client ਇੱਕ ਅਣਉਮੀਦ ਜਾਂ generic string ਭੇਜਦਾ ਹੈ ਅਤੇ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ।

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ failure ਸਿਰਫ਼ header ਤੋਂ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦਾ। ਇਹੀ ਮੁੱਖ ਸੀਮਾ ਹੈ, ਅਤੇ list maintenance ਦੀ ਕੋਈ ਵੀ ਮਾਤਰਾ ਇਸਨੂੰ ਦੂਰ ਨਹੀਂ ਕਰਦੀ।

ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਤੁਹਾਨੂੰ User-Agent strings ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਰਤਣ ਵਾਲੇ crawlers ਅਤੇ agents ਆਪਣੇ ਆਪ ਨੂੰ ਸੱਚਾਈ ਨਾਲ ਦਰਸਾਉਂਦੇ ਹਨ, ਅਤੇ ਨਾਮ routing, analytics ਅਤੇ debugging ਲਈ ਇੱਕ ਉਪਯੋਗ hint ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ client ਆਪਣੇ ਆਪ ਨੂੰ ਕੀ ਕਹਿੰਦਾ ਹੈ।

ਇਸ ਜਾਣਕਾਰੀ ਲਈ ਸਹੀ ਥਾਂ ਇੱਕ declaration ਵਜੋਂ ਹੈ, ਹੋਰ evidence ਦੇ ਨਾਲ ਤੌਲ ਕੇ, ਨਾ ਕਿ ਇਕੱਲੀ access unlock ਕਰਨ ਵਾਲੀ key ਵਜੋਂ। Proof of Actor ਇਸਨੂੰ ਬਿਲਕੁਲ ਇਸੇ ਤਰ੍ਹਾਂ ਦਰਜ ਕਰਦਾ ਹੈ।

Reverse DNS ਅਤੇ IP lists: ਅੰਸ਼ਕ measures

ਕਈ teams allowlist ਨੂੰ network checks ਨਾਲ ਮਜ਼ਬੂਤ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਮਦਦ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਠੀਕ ਤਰ੍ਹਾਂ ਸਮਝਣਾ ਲਾਭਦਾਇਕ ਹੈ।

Reverse DNS verification

ਕੁਝ crawler operators ਇੱਕ verification process document ਕਰਦੇ ਹਨ: request ਦੇ IP address ਲਈ hostname ਲੱਭੋ, ਜਾਂਚੋ ਕਿ ਇਹ operator ਦੇ domain ਨਾਲ ਸਬੰਧਤ ਹੈ, ਫਿਰ ਉਸ hostname ਨੂੰ ਲੱਭੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਮੁੜ ਉਸੇ IP 'ਤੇ resolve ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਇਹ round trip ਸਫਲ ਹੁੰਦੀ ਹੈ, ਤੁਹਾਡੇ ਕੋਲ ਅਸਲ evidence ਹੁੰਦੀ ਹੈ ਕਿ request operator ਦੀ infrastructure ਤੋਂ ਆਈ ਸੀ।

ਸੀਮਾਵਾਂ practical ਹਨ। ਇਹ ਸਿਰਫ਼ ਉਹਨਾਂ operators ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਜੋ ਇਸਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਅਤੇ support ਕਰਦੇ ਹਨ। ਇਹ DNS lookups ਜੋੜਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਹਾਨੂੰ cache ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਅਤੇ ਇਹ ਤੁਹਾਨੂੰ network ਬਾਰੇ ਦੱਸਦਾ ਹੈ, ਨਾ ਕਿ ਉਸ network 'ਤੇ ਕਿਹੜਾ product ਜਾਂ agent request ਕਰ ਰਿਹਾ ਸੀ।

Published IP ranges

ਹੋਰ operators ਉਹਨਾਂ IP ranges ਨੂੰ publish ਕਰਦੇ ਹਨ ਜੋ ਉਹਨਾਂ ਦੇ automated clients ਵਰਤਦੇ ਹਨ। ਇੱਕ request ਨੂੰ ਉਹਨਾਂ ranges ਨਾਲ match ਕਰਨਾ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ ਅਤੇ reverse DNS ਵਰਗੀ ਹੀ evidence ਦਿੰਦਾ ਹੈ। IETF ਵਿੱਚ ਇਹਨਾਂ ranges ਨੂੰ publish ਕਰਨ ਦੇ ਇੱਕ standard format ਬਾਰੇ ਚਰਚਾ ਜਾਰੀ ਹੈ, ਪਰ November 2026 ਤੱਕ ਕੋਈ ਨਿਰਧਾਰਤ standard ਨਹੀਂ ਹੈ, ਅਤੇ coverage ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਹਰ operator publish ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।

ਜਿਵੇਂ ਜਿਵੇਂ ਹੋਰ agents shared cloud infrastructure 'ਤੇ, proxies ਦੇ ਪਿੱਛੇ, ਜਾਂ user ਦੇ ਆਪਣੇ device ਤੋਂ ਚੱਲਦੇ ਹਨ, IP evidence ਵੀ ਕਮਜ਼ੋਰ ਹੁੰਦੀ ਹੈ। ਇੱਕ cloud address ਕਈ ਅਸੰਬੰਧਤ clients ਨੂੰ host ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਇੱਕ person ਦੇ browser ਤੋਂ ਕੰਮ ਕਰਦਾ agent ਉਸ person ਦੇ network ਵਰਗਾ ਹੀ ਲੱਗਦਾ ਹੈ।

Network checks ਮਿਲ ਕੇ ਕੀ ਜੋੜਦੀਆਂ ਹਨ

Reverse DNS ਅਤੇ IP lists ਕੁਝ declarations ਨੂੰ well-known operators ਦੇ ਇੱਕ subset ਲਈ ਹੋਰ ਮਜ਼ਬੂਤ ਚੀਜ਼ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ। ਇਹ agents ਅਤੇ tools ਦੀ long tail ਨੂੰ cover ਨਹੀਂ ਕਰਦੀਆਂ, ਅਤੇ AI ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲੇ ਲੋਕਾਂ ਲਈ ਤਾਂ ਇਹ ਬਿਲਕੁਲ ਮਦਦ ਨਹੀਂ ਕਰਦੀਆਂ। ਇਹ partial measures ਹਨ: ਵਰਤਣ ਯੋਗ, ਪਰ ਅਕੇਲੀ ਕਾਫ਼ੀ ਨਹੀਂ।

Signatures ਬਨਾਮ declarations

Evidence ਦਾ ਹੋਰ ਮਜ਼ਬੂਤ ਰੂਪ ਇੱਕ cryptographic signature ਹੈ। HTTP Message Signatures ਦੇ ਨਾਲ, ਜੋ RFC 9421 ਵਿੱਚ defined ਹਨ, ਇੱਕ client ਹਰ request ਦੇ ਚੁਣੇ ਹੋਏ ਹਿੱਸਿਆਂ ਨੂੰ private key ਨਾਲ sign ਕਰਦਾ ਹੈ। Verifier operator ਦੀ published public key ਲੈਂਦਾ ਹੈ ਅਤੇ signature ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਜੇ ਇਹ verify ਹੋ ਜਾਏ, ਤਾਂ request ਉਸ key ਦੇ holder ਵਲੋਂ sign ਕੀਤੀ ਗਈ ਸੀ, ਅਤੇ signed ਹਿੱਸੇ ਰਸਤੇ ਵਿੱਚ ਬਦਲੇ ਨਹੀਂ ਗਏ ਸਨ।

IETF Web Bot Auth working group ਇਹ standardize ਕਰ ਰਹੀ ਹੈ ਕਿ automated clients ਇਹ signatures ਕਿਵੇਂ ਵਰਤਦੇ ਹਨ ਅਤੇ ਆਪਣੀਆਂ keys ਕਿਵੇਂ publish ਕਰਦੇ ਹਨ। ਸਾਡਾ Web Bot Auth for product teams explainer ਮੌਜੂਦਾ status ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ।

Proof of Actor ਇੱਕ valid signature ਨੂੰ Verified evidence ਵਜੋਂ ਵਰਤਦਾ ਹੈ। ਇੱਕ User-Agent string, ਇੱਕ client hint, ਜਾਂ request body ਵਿੱਚ ਇੱਕ self-description ਨੂੰ Declared ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। Behavioral ਅਤੇ contextual signals ਨੂੰ Inferred ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਉਸੇ ਤਰ੍ਹਾਂ labeled ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਹਰ result ਦੱਸਦਾ ਹੈ ਕਿ ਉਹ ਕਿਸ basis 'ਤੇ ਟਿਕਿਆ ਹੈ, ਤਾਂ ਜੋ ਤੁਹਾਡੀ team ਕਦੇ ਵੀ ਇੱਕ ਦਾਅਵੇ ਨੂੰ ਇੱਕ check ਨਾਲ ਨਾ ਮਿਲਾ ਬੈਠੇ। ਪੂਰੀਆਂ definitions ਲਈ evidence basis entry ਵੇਖੋ।

ਇੱਕ ਸੀਮਾ verified evidence ਲਈ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਇੱਕ valid signature ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ request ਕਿਸ key ਨੇ sign ਕੀਤੀ। ਇਹ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ agent ਨੂੰ ਉਹ ਕੰਮ ਕਰਨ ਦੀ ਆਗਿਆ ਹੈ ਜੋ ਉਹ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ। ਇਹ ਇੱਕ agent authorization ਦਾ ਸਵਾਲ ਹੈ, ਅਤੇ ਇਹ ਤੁਹਾਡੀ application ਵਿੱਚ ਹੀ ਰਹਿੰਦਾ ਹੈ।

ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਬਜਾਏ Unknown ਨੂੰ ਸੰਭਾਲਣਾ

ਇੱਕ allowlist ਹਰ request ਨੂੰ ਦੋ bucket ਵਿੱਚ ਧੱਕ ਦਿੰਦਾ ਹੈ: ਸੂਚੀ ਵਿੱਚ ਜਾਂ ਨਹੀਂ। ਅਮਲ ਵਿੱਚ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸਪਸ਼ਟ traffic ਨੂੰ ਤੁਹਾਡਾ ਜੋ ਵੀ default ਹੈ, ਉਹ ਮਿਲਦਾ ਹੈ, ਅਤੇ default ਆਮ ਤੌਰ 'ਤੇ ਪੂਰੀ site ਲਈ ਇੱਕ ਵਾਰ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ।

Proof of Actor Unknown ਨੂੰ ਇੱਕ ਪਹਿਲੀ-ਦਰਜੇ ਦੇ result ਵਜੋਂ ਮੰਨਦਾ ਹੈ। ਜਦੋਂ evidence ਭਰੋਸੇਯੋਗ determination ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੀ, ਇਹ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਬਜਾਏ ਇਹੀ ਕਹਿੰਦਾ ਹੈ। ਫਿਰ ਤੁਹਾਡੀਆਂ policies ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਹਰ route 'ਤੇ Unknown ਦਾ ਕੀ ਅਰਥ ਹੈ:

Public documentation ਜਾਂ marketing pages 'ਤੇ, ਇਸਨੂੰ allow ਕਰੋ।
Search ਜਾਂ listing endpoints 'ਤੇ, ਇਸਨੂੰ ਆਪਣੀਆਂ ਆਮ rate limits ਦੇ ਨਾਲ allow ਕਰੋ।
Account changes 'ਤੇ, ਆਪਣੀਆਂ ਮੌਜੂਦਾ checks ਰੱਖੋ।
ਉੱਚ-ਅਸਰ ਵਾਲੇ actions 'ਤੇ, ਇਸਨੂੰ review ਲਈ ਭੇਜੋ ਜਾਂ ਹੋਰ ਮਜ਼ਬੂਤ signal ਮੰਗੋ।

handling Unknown traffic guide ਅਤੇ unknown classification entry patterns ਨੂੰ ਵਿਸਥਾਰ ਨਾਲ ਸਮਝਾਉਂਦੇ ਹਨ। ਸਮੇਂ ਦੇ ਨਾਲ ਆਪਣੀ Unknown rate ਦਾ ਪਤਾ ਰੱਖਣਾ ਇਹ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਕਿੰਨਾ traffic ਅਜੇ ਵੀ ਕਮਜ਼ੋਰ evidence 'ਤੇ ਟਿਕਿਆ ਹੋਇਆ ਹੈ।

AI ਦੀ ਮਦਦ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲੇ ਲੋਕਾਂ ਬਾਰੇ ਕੀ?

ਇੱਕ user agent allowlist ਉਸ person ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਜੋ ਇੱਕ ordinary browser ਵਿੱਚ AI assistant ਵਰਤਦਾ ਹੈ। ਉਹਨਾਂ ਦਾ User-Agent ਇੱਕ ਆਮ browser string ਹੁੰਦਾ ਹੈ। ਫਿਰ ਵੀ ਕਈ products ਇਸ interaction ਨੂੰ ਪਛਾਣਨਾ ਚਾਹੁੰਦੇ ਹਨ, ਉਦਾਹਰਣ ਵਜੋਂ AI-drafted submissions ਨੂੰ label ਕਰਨ ਲਈ ਜਾਂ ਇਹ ਸਮਝਣ ਲਈ ਕਿ AI-assisted users onboarding ਵਿੱਚ ਕਿਵੇਂ ਅੱਗੇ ਵਧਦੇ ਹਨ।

Proof of Actor ਇਹ interactions ਨੂੰ Human + AI ਵਜੋਂ ਦਰਜ ਕਰਦਾ ਹੈ ਜਦੋਂ assistance declared ਹੋਵੇ ਜਾਂ ਇੱਕ supported integration ਰਾਹੀਂ observed ਹੋਵੇ। ਇਹ ਸਿਰਫ਼ writing style ਤੋਂ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾਉਂਦਾ। ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ AI-assisted interaction ਪੜ੍ਹੋ।

Allowlist ਤੋਂ evidence-based policies ਵੱਲ ਵਧਣਾ

ਤੁਹਾਨੂੰ ਪਹਿਲੇ ਦਿਨ ਹੀ ਆਪਣੀ allowlist ਹਟਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇੱਕ ਸੁਰੱਖਿਅਤ ਰਸਤਾ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦਾ ਹੈ:

Observation mode ਵਿੱਚ install ਕਰੋ। Proof of Actor ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ। ਤੁਹਾਡੀ allowlist ਕੰਮ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ।
ਤੁਲਨਾ ਕਰੋ। ਹਰ route ਲਈ ਦੇਖੋ ਕਿ ਕਿਹੜੀਆਂ allowlisted requests ਕੋਲ verified evidence ਹੈ, ਕਿਹੜੀਆਂ ਕੋਲ ਸਿਰਫ਼ ਇੱਕ declaration ਹੈ, ਅਤੇ ਕਿਹੜੀਆਂ Unknown ਬਣ ਜਾਂਦੀਆਂ ਹਨ।
Policies ਦਾ preview ਕਰੋ। ਇੱਕ policy ਦਾ ਮਸੌਦਾ ਬਣਾਓ ਜੋ verified agents, declared agents ਅਤੇ Unknown ਨਾਲ ਵੱਖਰਾ ਵਰਤਾਓ ਕਰੇ, ਅਤੇ real traffic 'ਤੇ ਇਸਦਾ ਪ੍ਰਭਾਵ preview ਕਰੋ।
Route by route enforce ਕਰੋ। ਉਹਨਾਂ routes ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜਿੱਥੇ spoofed name ਸਭ ਤੋਂ ਵੱਧ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ।
Allowlist ਨੂੰ ਇੱਕ hint ਵਜੋਂ ਰੱਖੋ। ਨਾਮ routing ਅਤੇ analytics ਲਈ ਉਪਯੋਗ ਰਹਿੰਦੇ ਹਨ, ਹੁਣ ਉਹਨਾਂ ਦੀ basis ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ।

rolling out actor-aware policies safely guide ਹਰ ਕਦਮ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ, ਅਤੇ verified automated requests ਸਮਝਾਉਂਦੀ ਹੈ ਕਿ signed clients ਕਿਵੇਂ fit ਹੁੰਦੇ ਹਨ।

ਕਦੋਂ allowlist ਕਾਫ਼ੀ ਹੁੰਦੀ ਹੈ

ਘੱਟ-ਖ਼ਤਰੇ ਵਾਲੀ routing ਲਈ, ਜਿਵੇਂ public content 'ਤੇ ਇੱਕ ਜਾਣੇ-ਪਛਾਣੇ crawler ਨੂੰ ਹਲਕਾ page serve ਕਰਨਾ, ਇੱਕ user agent allowlist ਅਕਸਰ ਠੀਕ ਹੁੰਦੀ ਹੈ। Spoofed name ਦੀ ਕੀਮਤ ਘੱਟ ਹੁੰਦੀ ਹੈ।

ਜਦੋਂ decision ਦੇ ਅਸਰ ਹੁੰਦੇ ਹਨ, ਜਿਵੇਂ challenge ਛੱਡਣਾ, richer data expose ਕਰਨਾ, ਜਾਂ write ਦੀ ਆਗਿਆ ਦੇਣਾ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਹ evidence ਚਾਹੀਦੀ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਜਾਂਚ ਕਰ ਸਕੋ। ਇਹੀ ਥਾਂ ਹੈ ਜਿੱਥੇ Proof of Actor ਆਉਂਦਾ ਹੈ, ਉਹਨਾਂ network checks ਅਤੇ edge controls ਦੇ ਨਾਲ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਚਲਾ ਰਹੇ ਹੋ।

ਸ਼ੁਰੂ ਕਰੋ

Proof of Actor private beta ਵਿੱਚ ਹੈ। ਚੁਣੀਆਂ ਹੋਈਆਂ founding developer teams ਨੂੰ agreed usage limits ਦੇ ਅੰਦਰ 12 months ਤੱਕ ਦਾ free access ਮਿਲ ਸਕਦਾ ਹੈ, ਬਿਨਾਂ automatic billing ਦੇ। early access ਲਈ apply ਕਰੋ ਅਤੇ ਸਾਨੂੰ ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਅੱਜ ਕਿਹੜੇ clients allowlist ਕਰਦੇ ਹੋ ਅਤੇ ਕਿਹੜੇ routes ਨੂੰ ਬਿਹਤਰ evidence ਨਾਲ protect ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।

ਡਿਵੈਲਪਰਾਂ ਲਈ

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 ਪੜ੍ਹੋ

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

ਕੀ ਇੱਕ user agent allowlist ਬੇਕਾਰ ਹੈ?

ਨਹੀਂ। ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਰਤਣ ਵਾਲੇ clients ਵਲੋਂ ਇੱਕ ਉਪਯੋਗ declaration ਹੈ ਅਤੇ ਜਾਣੇ-ਪਛਾਣੇ crawlers ਨੂੰ route ਕਰਨ ਦਾ ਸਸਤਾ ਤਰੀਕਾ ਹੈ। ਸਮੱਸਿਆ ਇਸਨੂੰ proof ਸਮਝਣ ਵਿੱਚ ਹੈ। ਕੋਈ ਵੀ client ਕੋਈ ਵੀ User-Agent string ਭੇਜ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ allowlist ਅਕੇਲੀ ਕਦੇ ਵੀ ਸੰਵੇਦਨਸ਼ੀਲ actions ਨੂੰ unlock ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ।

ਕੀ reverse DNS verification User-Agent spoofing ਨੂੰ ਠੀਕ ਕਰ ਦਿੰਦੀ ਹੈ?

ਇਹ ਉਹਨਾਂ operators ਲਈ ਮਦਦ ਕਰਦੀ ਹੈ ਜੋ ਇਸਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦੇ ਹਨ। Request ਦੇ IP address ਲਈ reverse lookup, ਫਿਰ matching forward lookup, ਇੱਕ IP address ਨੂੰ operator ਦੇ domain ਨਾਲ ਜੋੜਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ ਉਹਨਾਂ operators ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਜੋ ਇਸਨੂੰ support ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹ shared cloud ਜਾਂ residential addresses ਤੋਂ ਆਉਣ ਵਾਲੇ traffic ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ।

Proof of Actor User-Agent header ਨਾਲ ਕਿਵੇਂ ਵਰਤਦਾ ਹੈ?

ਇੱਕ declaration ਵਜੋਂ। ਇਹ result ਵਿੱਚ declared basis ਦੇ ਨਾਲ ਯੋਗਦਾਨ ਪਾਉਂਦਾ ਹੈ, ਕਦੇ ਵੀ verified basis ਵਜੋਂ ਨਹੀਂ। ਇੱਕ verified basis ਲਈ HTTP Message Signature ਵਰਗੀ evidence ਚਾਹੀਦੀ ਹੈ ਜੋ published key ਦੇ ਖ਼ਿਲਾਫ਼ checked ਹੋਵੇ।

ਇੱਕ verified signature ਕੀ ਸਾਬਤ ਕਰਦੀ ਹੈ?

ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ request ਕਿਸ key ਨੇ sign ਕੀਤੀ ਅਤੇ signed ਹਿੱਸੇ ਰਾਹ ਵਿੱਚ ਨਹੀਂ ਬਦਲੇ ਗਏ। ਇਹ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ agent ਨੂੰ ਇਹ action ਕਰਨ ਦੀ authorization ਹੈ। Authorization ਤੁਹਾਡੀ application ਵਿੱਚ ਹੀ ਰਹਿੰਦੀ ਹੈ।

ਜਦੋਂ clients ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਜਾਣੇ-ਪਛਾਣੇ agent ਵਜੋਂ ਦਰਸਾਉਂਦੇ ਹਨ ਪਰ verify ਨਹੀਂ ਹੋ ਸਕਦੇ, ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

Proof of Actor ਉਹੀ ਦਰਜ ਕਰਦਾ ਹੈ ਜੋ evidence ਸਮਰਥਨ ਕਰਦੀ ਹੈ, ਅਕਸਰ ਇੱਕ declared ਜਾਂ inferred result, ਜਾਂ Unknown। ਤੁਹਾਡੀ policy ਉਸ route ਲਈ fallback ਚੁਣਦੀ ਹੈ, claimed name 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਬਜਾਏ।

ਕੀ Proof of Actor ਜੋੜਣ ਨਾਲ ਮੇਰਾ ਮੌਜੂਦਾ allowlist behavior ਬਦਲੇਗਾ?

ਨਹੀਂ। ਇਹ observation mode ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ real traffic 'ਤੇ ਇਸਦੇ results ਦੀ ਆਪਣੀਆਂ allowlist decisions ਨਾਲ ਤੁਲਨਾ ਕਰ ਸਕਦੇ ਹੋ।

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

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

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

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