ਤੁਹਾਡੀ ਵੈੱਬਸਾਈਟ ਕੋਲ ਹੁਣ visitor ਦੀ ਇੱਕ ਤੋਂ ਵੱਧ ਕਿਸਮ ਹੈ
ਵੈੱਬ ਦੇ ਇਤਿਹਾਸ ਦੇ ਜ਼ਿਆਦਾਤਰ ਹਿੱਸੇ ਵਿੱਚ, ਇੱਕ ਵੈੱਬਸਾਈਟ ਇੱਕ ਸਧਾਰਣ ਮਾਡਲ ਮੰਨ ਸਕਦੀ ਸੀ: ਕੋਈ ਵਿਅਕਤੀ browser ਖੋਲ੍ਹਦਾ ਹੈ, ਇੱਧਰ-ਉੱਧਰ click ਕਰਦਾ ਹੈ, ਅਤੇ ਸ਼ਾਇਦ sign in ਕਰ ਲੈਂਦਾ ਹੈ। Analytics, rate limits, onboarding flows ਅਤੇ security checks ਸਭ ਉਸ ਵਿਅਕਤੀ ਦੇ ਆਧਾਰ 'ਤੇ ਬਣੇ ਸਨ।
ਇਹ ਮਾਡਲ ਹੁਣ ਅਸਲ traffic ਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰਦਾ। ਅੱਜ ਇੱਕ ਹੀ ਵੈੱਬਸਾਈਟ ਉਹਨਾਂ ਲੋਕਾਂ ਨੂੰ ਸੇਵਾ ਦਿੰਦੀ ਹੈ ਜੋ ਆਪਣੇ ਆਪ browse ਕਰ ਰਹੇ ਹਨ, ਉਹਨਾਂ ਲੋਕਾਂ ਨੂੰ ਜੋ AI assistant ਨੂੰ ਆਪਣੇ ਲਈ ਕੁਝ summarize ਕਰਨ ਜਾਂ ਭਰਣ ਲਈ ਕਹਿੰਦੇ ਹਨ, autonomous agents ਨੂੰ ਜੋ ਕਿਸੇ ਹੋਰ ਦੀ ਥਾਂ pages ਪੜ੍ਹਦੇ ਹਨ ਅਤੇ endpoints call ਕਰਦੇ ਹਨ, ਅਤੇ crawlers ਅਤੇ scripts ਦੀ ਲੰਮੀ ਲਹਿਰ ਨੂੰ ਵੀ। AI providers ਆਪ ਵੀ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਈ visitors ਨੂੰ document ਕਰਦੇ ਹਨ: ਉਦਾਹਰਨ ਲਈ, OpenAI ਆਪਣੇ search crawler, training crawler ਅਤੇ fetcher ਲਈ ਵੱਖ-ਵੱਖ user agents ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਤਦੋਂ pages visit ਕਰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ChatGPT user ਇੱਕ question ਪੁੱਛਦਾ ਹੈ (OpenAI crawler documentation), ਅਤੇ Anthropic ClaudeBot, Claude-User ਅਤੇ Claude-SearchBot ਲਈ ਵੀ ਇਹੀ ਕਰਦਾ ਹੈ (Anthropic crawler documentation). ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ visitors welcome ਹਨ। ਕੁਝ ਨੂੰ ਵੱਖਰੇ experience ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਕੁਝ ਨੂੰ ਕੁਝ ਸੰਵੇਦਨਸ਼ੀਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹੋਰ ਨਜ਼ਦੀਕੀ ਨਿਗਰਾਨੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਚੁਣੌਤੀ ਇਹ ਹੈ ਕਿ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੀਆਂ interactions ਪਹਿਲੀ ਨਜ਼ਰ ਵਿੱਚ ਮਿਲਦੀਆਂ-ਜੁਲਦੀਆਂ ਲੱਗਦੀਆਂ ਹਨ। ਇੱਕ login ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜਾ account ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ। ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕੋਈ ਵਿਅਕਤੀ click ਕਰ ਰਿਹਾ ਹੈ, ਕੋਈ assistant ਉਸ session ਰਾਹੀਂ act ਕਰ ਰਹੀ ਹੈ, ਜਾਂ ਕੋਈ automated client ਤੁਹਾਡੇ pricing page ਨੂੰ ਕਿਸੇ ਹੋਰ user ਲਈ ਪੜ੍ਹ ਰਿਹਾ ਹੈ। ਵੈੱਬਸਾਈਟਾਂ ਲਈ AI ਏਜੰਟ ਖੋਜ ਦਾ ਮਕਸਦ evidence ਨਾਲ ਇਸ ਖਾਈ ਨੂੰ ਭਰਨਾ ਹੈ, ਤਾਂ ਜੋ ਤੁਹਾਡੀ ਟੀਮ traffic ਨੂੰ ਇੱਕੋ ਜਿਹੇ ਤਰੀਕੇ ਨਾਲ ਨਾ ਸੰਭਾਲੇ, ਸਗੋਂ ਹਰ actor ਕਿਸਮ ਲਈ ਢੰਗ ਨਾਲ ਜਵਾਬ ਦੇਵੇ। ਸ਼ਾਮਲ signals ਦੇ ਇੱਕ ਪ੍ਰਯੋਗਿਕ walkthrough ਲਈ, ਕਿਵੇਂ ਪਤਾ ਲਗੇ ਕਿ website traffic AI agents ਤੋਂ ਆ ਰਿਹਾ ਹੈ ਪੜ੍ਹੋ, ਅਤੇ production site ਉੱਤੇ ਇਹ ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ websites use case ਦੇਖੋ।
ਇੱਕ single bot score ਕਿਉਂ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ
ਕਈ tools ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਇੱਕ number ਨਾਲ ਦਿੰਦੀਆਂ ਹਨ: ਇੱਕ bot score, ਇੱਕ risk score, ਇੱਕ percentage ਜੋ ਦਾਅਵਾ ਕਰਦੀ ਹੈ ਕਿ visitor ਕਿੰਨਾ human ਹੈ। ਆਕਰਸ਼ਣ ਸਪਸ਼ਟ ਹੈ। ਇੱਕ number rule ਵਿੱਚ ਪਾਉਣ ਲਈ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
ਮੁੱਦਾ ਇਹ ਹੈ ਕਿ ਇੱਕ single number reasoning ਨੂੰ ਓਹਲੇ ਕਰ ਦਿੰਦੀ ਹੈ। ਜਦੋਂ ਕੋਈ score ਕਹਿੰਦਾ ਹੈ ਕਿ session ਸ਼ਾਇਦ automated ਹੈ, ਤੁਹਾਡੀ ਟੀਮ ਨਹੀਂ ਦੇਖ ਸਕਦੀ ਕਿ ਇਹ ਨਤੀਜਾ verified signature 'ਤੇ ਆਧਾਰਿਤ ਹੈ, ਕਿਸੇ user-agent string 'ਤੇ ਜੋ ਕੋਈ ਵੀ copy ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਕਿਸੇ ਐਸੇ pattern 'ਤੇ ਜੋ ਇੱਕ ਤੇਜ਼ human typist ਨਾਲ ਵੀ ਮਿਲਦਾ ਹੈ। ਜਦੋਂ ਉਹ score block ਜਾਂ challenge ਚਲਾਉਂਦੀ ਹੈ, ਤੁਸੀਂ ਉਸ ਦੀਆਂ ਸਾਰੀਆਂ ਗਲਤੀਆਂ ਆਪਣੇ ਸਿਰ ਲੈ ਲੈਂਦੇ ਹੋ, ਬਿਨਾਂ ਇਹ ਸਮਝਾਏ ਕਿ ਇਹ customer, colleague ਜਾਂ auditor ਨੂੰ ਕਿਵੇਂ ਦੱਸਣਾ ਹੈ।
Proof of Actor ਇੱਕ ਵੱਖਰਾ ਤਰੀਕਾ ਅਪਣਾਉਂਦਾ ਹੈ। ਹਰ ਨਤੀਜਾ ਚਾਰ ਸਪਸ਼ਟ classes ਵਿੱਚੋਂ ਇੱਕ ਹੁੰਦਾ ਹੈ, ਜਿਸਦੀ ਵਿਆਖਿਆ Human, AI-assisted ਜਾਂ agent: app traffic ਲਈ ਇੱਕ taxonomy ਵਿੱਚ ਹੈ, ਅਤੇ ਹਰ ਨਤੀਜਾ ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਕਿਸ ਆਧਾਰ 'ਤੇ ਹੈ। ਤੁਸੀਂ conclusion ਅਤੇ evidence ਇਕੱਠੇ ਦੇਖਦੇ ਹੋ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਮਜ਼ਬੂਤ ਨਤੀਜਿਆਂ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹੋ, ਕਮਜ਼ੋਰ ਨਤੀਜਿਆਂ 'ਤੇ ਸਵਾਲ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਐਸੀ policies ਬਣਾ ਸਕਦੇ ਹੋ ਜੋ evidence ਦੀ ਗੁਣਵੱਤਾ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹੋਣ।
ਆਪਣੀ ਵੈੱਬਸਾਈਟ 'ਤੇ AI agents ਖੋਜਣ ਦੇ ਚਾਰ ਕਦਮ
ਤੁਸੀਂ ਉਹਨਾਂ tools ਨਾਲ ਆਪਣੀ ਵੈੱਬਸਾਈਟ 'ਤੇ AI agents ਖੋਜਣਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹਨ। ਇਹ ਚਾਰ ਕਦਮ vendor-neutral ਹਨ ਅਤੇ Proof of Actor ਵਰਤਦੇ ਹੋ ਜਾਂ ਨਹੀਂ, ਦੋਵਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ; ਕਿਵੇਂ ਪਤਾ ਲਗੇ ਕਿ website traffic AI agents ਤੋਂ ਆ ਰਿਹਾ ਹੈ ਵਾਲੀ blog post ਹਰ ਕਦਮ ਨੂੰ ਹੋਰ ਗਹਿਰਾਈ ਨਾਲ ਸਮਝਾਉਂਦੀ ਹੈ।
- ਉਹ agents ਲਿਸਟ ਕਰੋ ਜੋ ਆਪਣੇ ਆਪ ਦੀ ਘੋਸ਼ਣਾ ਕਰਦੇ ਹਨ। ਆਪਣੇ server ਜਾਂ CDN logs ਵਿੱਚ AI providers ਵੱਲੋਂ ਪ੍ਰਕਾਸ਼ਿਤ user agents ਖੋਜੋ। OpenAI OAI-SearchBot, GPTBot ਅਤੇ ChatGPT-User ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਦੱਸਦਾ ਹੈ ਕਿ ChatGPT-User pages visit ਕਰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ user ChatGPT ਨੂੰ question ਪੁੱਛਦਾ ਹੈ, ਨਾ ਕਿ ਆਪਣੇ ਆਪ crawl ਕਰਦਾ ਹੈ। Anthropic ClaudeBot, Claude-User ਅਤੇ Claude-SearchBot ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ route ਅਨੁਸਾਰ agent traffic ਦੀ ਇੱਕ ਪਹਿਲੀ, declared ਤਸਵੀਰ ਦਿੰਦਾ ਹੈ।
- string 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਬਜਾਏ ਦਾਅਵਿਆਂ ਦੀ ਤਸਦੀਕ ਕਰੋ। ਇੱਕ user agent self-reported ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ copy ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਇਸ ਨੂੰ operator ਦੇ ਆਪਣੇ verification method ਨਾਲ ਮਿਲਾਓ: Google, Googlebot ਲਈ reverse DNS lookup ਤੋਂ ਬਾਅਦ forward DNS lookup, ਨਾਲ ਹੀ ਪ੍ਰਕਾਸ਼ਿਤ IP range files, ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ (Google: verifying Googlebot); Bing Bingbot ਲਈ ਉਹੀ reverse ਅਤੇ forward DNS check ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ (Bing: verifying Bingbot); OpenAI ਆਪਣੇ ਹਰ user agent ਲਈ IP range files ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਜਿੱਥੇ ਕੋਈ client ਆਪਣੇ requests ਨੂੰ HTTP Message Signatures ਨਾਲ sign ਕਰਦਾ ਹੈ, ਜੋ RFC 9421 ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਹਨ, ਉੱਥੇ signature ਨੂੰ operator ਦੀ ਪ੍ਰਕਾਸ਼ਿਤ key ਨਾਲ ਮਿਲਾਓ।
- ਹਰ ਨਤੀਜੇ ਨੂੰ ਉਸ ਦੇ evidence ਨਾਲ label ਕਰੋ, ਅਤੇ Unknown ਨੂੰ ਬਣੇ ਰਹਿਣ ਦਿਓ। ਦਰਜ ਕਰੋ ਕਿ ਹਰ conclusion verified, declared ਜਾਂ inferred ਹੈ। ਉਹ traffic ਜੋ ਕਿਸੇ verified ਜਾਂ declared agent ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ ਅਤੇ ਕੋਈ ਸਪਸ਼ਟ human pattern ਨਹੀਂ ਦਿਖਾਉਂਦਾ, ਉਸਨੂੰ Unknown label ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, human ਜਾਂ bot ਵਿੱਚ force ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਇਹੀ ਕਦਮ ਇੱਕ ਉਪਯੋਗ report ਅਤੇ ਇੱਕ ਅਨੁਮਾਨ ਵਿਚਕਾਰ ਫਰਕ ਕਰਦਾ ਹੈ।
- ਕਾਰਵਾਈ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ route ਅਨੁਸਾਰ observe ਕਰੋ। ਕੁਝ ਹਫ਼ਤਿਆਂ ਲਈ ਨਤੀਜਿਆਂ ਨੂੰ route ਅਤੇ workflow ਅਨੁਸਾਰ ਵੰਡੋ: public content, signup, account settings, APIs। ਫਿਰ ਹੀ ਉਸ route ਲਈ ਇੱਕ ਸੰਕੁਚਿਤ policy ਲਿਖੋ ਜਿੱਥੇ actor context ਸਭ ਤੋਂ ਵੱਧ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ, ਅਤੇ Unknown ਲਈ ਇੱਕ explicit fallback ਰੱਖੋ।
Proof of Actor ਤੁਹਾਡੀ application ਦੇ ਅੰਦਰ ਇਹ ਕਦਮ automate ਕਰਦਾ ਹੈ: ਇਹ ਉਹ signals ਇਕੱਠੇ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਡਾ integration ਦੇਖ ਸਕਦਾ ਹੈ, ਆਧਾਰ ਸਮੇਤ ਇੱਕ class ਵਾਪਸ ਕਰਦਾ ਹੈ, route ਅਨੁਸਾਰ Unknown ਨੂੰ track ਕਰਦਾ ਹੈ, ਅਤੇ policy ਨੂੰ ਤੁਹਾਡੇ code ਦੇ ਹਵਾਲੇ ਕਰਦਾ ਹੈ।
Proof of Actor websites 'ਤੇ AI agents ਨੂੰ ਕਿਵੇਂ detect ਕਰਦਾ ਹੈ
Proof of Actor ਇੱਕ ਸਧਾਰਣ path ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣਾਇਆ ਗਿਆ ਹੈ: ਉਹ signals ਜੋ ਤੁਹਾਡਾ integration observe ਕਰ ਸਕਦਾ ਹੈ, ਇੱਕ explicit ਆਧਾਰ ਵਾਲੀ classification, ਅਤੇ ਇੱਕ decision ਜੋ ਤੁਹਾਡੇ ਹੱਥ ਵਿੱਚ ਹੀ ਰਹਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਪੂਰਾ flow How It Works ਪੰਨੇ 'ਤੇ ਪੜ੍ਹ ਸਕਦੇ ਹੋ। ਇੱਥੇ ਸੰਖੇਪ version ਹੈ।
ਤੁਹਾਡੇ integration ਤੋਂ ਮਿਲਣ ਵਾਲੇ signals
ਹਰ integration ਉਹੀ ਵੇਖਦਾ ਹੈ ਜੋ ਇਸਦਾ context ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਇੱਕ server-side integration request context, protocol details ਅਤੇ, ਜਦੋਂ ਕੋਈ client ਇਸ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਇੱਕ request signature ਵੇਖਦਾ ਹੈ। ਇੱਕ browser integration ਉਹਨਾਂ pages 'ਤੇ interaction signals ਵੇਖਦਾ ਹੈ ਜਿੱਥੇ ਇਹ ਚੱਲਦਾ ਹੈ। ਇੱਕ application ਆਪਣੀਆਂ declarations ਵੀ ਦਰਜ ਕਰ ਸਕਦੀ ਹੈ, ਜਿਵੇਂ ਕੋਈ user AI assistance ਨਾਲ content drafted ਕਰਨਾ ਚਿੰਨ੍ਹਦਾ ਹੈ, ਜਾਂ ਕੋਈ agent client ਆਪਣੇ ਆਪ ਨੂੰ ਨਾਮ ਦਿੰਦਾ ਹੈ।
Proof of Actor ਉਸ evidence ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਮੌਜੂਦ ਹੈ। ਇਹ ਇਹ ਨਾਟਕ ਨਹੀਂ ਕਰਦਾ ਕਿ ਇਹ ਉਹ ਚੀਜ਼ਾਂ ਦੇਖ ਸਕਦਾ ਹੈ ਜੋ ਤੁਹਾਡੀ ਵੈੱਬਸਾਈਟ observe ਨਹੀਂ ਕਰ ਸਕਦੀ।
ਚਾਰ classes ਜੋ ਕਿਸੇ ਖਾਸ ਅਰਥ ਨੂੰ ਦਰਸਾਉਂਦੀਆਂ ਹਨ
ਹਰ interaction ਚਾਰ classes ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਆਉਂਦਾ ਹੈ:
- Human: ਦੇਖਣ ਯੋਗ signals human-directed interaction ਦਰਸਾਉਂਦੇ ਹਨ।
- Human + AI: AI assistance declared ਸੀ, ਜਾਂ supported integration ਰਾਹੀਂ observe ਹੋਈ ਜੋ ਇਸਨੂੰ ਦੇਖ ਸਕਦੀ ਹੈ।
- Agent: automated ਜਾਂ agent-origin interaction, ਜੋ verifiable identity ਜਾਂ ਧਿਆਨ ਨਾਲ qualified inference ਨਾਲ supported ਹੈ।
- Unknown: ਉਪਲਬਧ evidence ਭਰੋਸੇਯੋਗ ਨਿਰਧਾਰਣ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ।
ਹਰ class ਨਾਲ ਇੱਕ ਸਪਸ਼ਟ definition ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਸੀਮਾ ਹੁੰਦੀ ਹੈ। ਇੱਕ Human result verified identity ਨਹੀਂ ਹੁੰਦੀ। ਇੱਕ Agent result ਇਹ ਬਿਆਨ ਨਹੀਂ ਹੁੰਦਾ ਕਿ agent authorized ਹੈ। ਇੱਕ Unknown result ਇਲਜ਼ਾਮ ਨਹੀਂ ਹੁੰਦਾ। ਤੁਸੀਂ Detection & Limitations ਪੰਨੇ 'ਤੇ ਪੂਰੀ taxonomy ਪੜ੍ਹ ਸਕਦੇ ਹੋ।
ਹਰ ਨਤੀਜੇ 'ਤੇ ਇੱਕ ਆਧਾਰ
Class ਦੇ ਨਾਲ, ਹਰ result ਆਪਣਾ ਆਧਾਰ ਵੀ ਰੱਖਦਾ ਹੈ: verified, declared, inferred ਜਾਂ unknown। ਇੱਕ request ਜਿਸ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ key ਤੋਂ valid signature ਹੁੰਦੀ ਹੈ, ਉਸ check ਲਈ verified ਹੁੰਦੀ ਹੈ। ਇੱਕ client ਜੋ ਆਪਣੇ ਆਪ ਨੂੰ agent ਵਜੋਂ ਨਾਮ ਦਿੰਦਾ ਹੈ, ਉਸ ਨੇ ਇਹ declared ਕੀਤਾ ਹੁੰਦਾ ਹੈ। automation ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਵਿਹਾਰ inferred ਹੁੰਦਾ ਹੈ। ਇਹੀ ਫਰਕ ਤੁਹਾਡੀਆਂ policies ਨੂੰ ਸਹੀ ਬਣਾਉਂਦਾ ਹੈ। ਇੱਕ read-only route 'ਤੇ verified signed agent ਅਤੇ account settings page 'ਤੇ self-declared client ਨੂੰ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਸੰਭਾਲਣਾ ਚਾਹੀਦਾ, ਅਤੇ Proof of Actor ਨਾਲ ਤੁਹਾਨੂੰ ਇਹ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। evidence basis glossary entry ਹਰ ਇੱਕ ਨੂੰ ਹੋਰ ਵਿਸਥਾਰ ਨਾਲ ਸਮਝਾਉਂਦੀ ਹੈ।
ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਕੀ ਮਿਲਦਾ ਹੈ: Detect, Understand, Route
Proof of Actor ਇੱਕ ਹੀ product ਹੈ ਜਿਸ ਵਿੱਚ ਤਿੰਨ capabilities ਹਨ ਜੋ ਇਕੱਠੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ।
Detect
ਉਹ actor signals ਇਕੱਠੇ ਕਰੋ ਜੋ ਤੁਹਾਡੇ integration ਲਈ ਉਪਲਬਧ ਹਨ ਅਤੇ verified assertions ਨੂੰ behavioral inferences ਤੋਂ ਵੱਖ ਕਰੋ। Unknown traffic ਇੱਕ guess ਵਿੱਚ ਮਿਲਾਇਆ ਨਹੀਂ ਜਾਂਦਾ, ਸਗੋਂ ਆਪਣੀ ਵੱਖਰੀ category ਵਜੋਂ visible ਰਹਿੰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਹਮੇਸ਼ਾਂ ਪਤਾ ਰਹਿੰਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ interactions ਬਾਰੇ ਤੁਸੀਂ ਭਰੋਸੇ ਨਾਲ ਬੋਲ ਸਕਦੇ ਹੋ ਅਤੇ ਕਿਹੜਿਆਂ ਲਈ ਹੋਰ evidence ਦੀ ਲੋੜ ਹੈ।
Understand
ਆਪਣੇ AI agent traffic ਨੂੰ context ਵਿੱਚ ਦੇਖੋ। route ਅਤੇ ਸਮੇਂ ਅਨੁਸਾਰ interaction types ਨੂੰ explore ਕਰੋ, human, AI-assisted, agent ਅਤੇ unknown activity ਦੇ trends ਪਾਲੋ, ਅਤੇ ਕਿਸੇ ਵੀ classification ਨੂੰ ਖੋਲ੍ਹ ਕੇ ਦੇਖੋ ਕਿ ਕੀ ਜਾਣਿਆ ਗਿਆ ਹੈ, ਕੀ ਨਹੀਂ ਜਾਣਿਆ ਗਿਆ, ਅਤੇ ਨਤੀਜਾ ਕਿਸ 'ਤੇ ਆਧਾਰਿਤ ਹੈ। ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ product, platform ਅਤੇ security teams ਨੂੰ ਇਸ ਗੱਲ ਦੀ ਇੱਕ ਸਾਂਝੀ, explainable ਤਸਵੀਰ ਮਿਲਦੀ ਹੈ ਕਿ ਵੈੱਬਸਾਈਟ ਨੂੰ ਕੌਣ ਵਰਤ ਰਿਹਾ ਹੈ।
Route
ਆਪਣੀਆਂ policies ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਖਾਸ interactions ਨੂੰ allow, adapt, challenge, review ਜਾਂ limit ਕਰੋ। ਤੁਹਾਡੇ documentation ਨੂੰ ਪੜ੍ਹ ਰਹੇ ਇੱਕ verified agent ਲਈ structured response ਪੇਸ਼ ਕਰੋ। human-directed sessions ਲਈ standard experience ਬਰਕਰਾਰ ਰੱਖੋ। ਜਦੋਂ ਤੁਹਾਡੀਆਂ own conditions ਇਸ ਦੀ ਮੰਗ ਕਰਦੀਆਂ ਹਨ ਤਾਂ ਇੱਕ sensitive account change 'ਤੇ ਹੋਰ ਮਜ਼ਬੂਤ check ਲਈ ਕਹੋ। Unknown results ਅਤੇ timeouts ਲਈ route by route ਇੱਕ explicit fallback ਚੁਣੋ। Enforcement ਹਮੇਸ਼ਾਂ ਤੁਹਾਡੀ application ਵਿੱਚ ਹੁੰਦੀ ਹੈ, ਉਹਨਾਂ policies ਅਧੀਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਹਾਡੀ team confirm ਕਰਦੀ ਹੈ।
ਤੁਹਾਡੀ ਵੈੱਬਸਾਈਟ ਵਿੱਚ ਫਿੱਟ ਹੋਣ ਲਈ ਬਣਾਇਆ ਗਿਆ, ਇਸਦੀ ਥਾਂ ਲੈਣ ਲਈ ਨਹੀਂ
Proof of Actor ਉਹਨਾਂ tools ਦੇ ਨਾਲ ਰਹਿੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਚਲਾ ਰਹੇ ਹੋ। ਇਹ ਤੁਹਾਡੀ authentication, ਤੁਹਾਡੇ authorization model ਜਾਂ ਤੁਹਾਡੇ ਮੌਜੂਦਾ abuse controls ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ। ਇਹ ਉਨ੍ਹਾਂ ਵਿੱਚ actor context ਜੋੜਦਾ ਹੈ।
ਇੱਕ ਆਮ website integration ਉਹਨਾਂ routes ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ actor context ਸਭ ਤੋਂ ਵੱਧ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ: ਉਹ public content ਜਿਸਨੂੰ agents ਬਹੁਤ ਪੜ੍ਹਦੇ ਹਨ, signup ਅਤੇ onboarding flows, account settings ਅਤੇ ਹੋਰ ਸੰਵੇਦਨਸ਼ੀਲ actions, ਅਤੇ ਕੋਈ ਵੀ API ਜੋ site ਨੂੰ power ਕਰਦੀ ਹੈ। Founding teams ਸਾਡੇ engineers ਨਾਲ ਮਿਲ ਕੇ ਇਹ routes ਚੁਣਦੇ ਹਨ, scope ਵਿੱਚ signals 'ਤੇ ਸਹਿਮਤ ਹੁੰਦੇ ਹਨ, ਅਤੇ code ship ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ data ਕਿਵੇਂ handle ਹੋਵੇਗੀ ਇਹ confirm ਕਰਦੇ ਹਨ।
ਕਿਉਂਕਿ decision layer ਤੁਹਾਡੇ code ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ, experience ਉੱਤੇ control ਤੁਹਾਡੇ ਕੋਲ ਰਹਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਹਫ਼ਤਿਆਂ ਤੱਕ internal dashboard ਵਿੱਚ results ਦਿਖਾ ਸਕਦੇ ਹੋ, ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਕੋਈ rule change ਹੋਵੇ, ਫਿਰ ਇੱਕ route ਲਈ ਇੱਕ narrow policy ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ, ਫਿਰ ਜਦੋਂ ਨਤੀਜਿਆਂ ਨੇ ਤੁਹਾਡਾ ਭਰੋਸਾ ਕਮਾ ਲਿਆ ਹੋਵੇ ਤਾਂ ਵਿਸਤਾਰ ਕਰ ਸਕਦੇ ਹੋ। handling unknown traffic ਵਾਲਾ guide ਇਹ ਪਹਿਲੇ rules design ਕਰਨ ਦਾ ਤਰੀਕਾ ਦੱਸਦਾ ਹੈ।
observation mode ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ
AI agent detection ਤੋਂ value ਲੈਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਦੇਖਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਰੋਕਣ ਨਾਲ ਨਹੀਂ। observation mode ਵਿੱਚ, Proof of Actor results record ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੀ ਵੈੱਬਸਾਈਟ ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਜਿਵੇਂ ਇਹ ਇਸ ਦੇ ਬਿਨਾਂ ਦਿੰਦੀ। ਫਿਰ ਤੁਹਾਡੀ ਟੀਮ classifications ਦੀ ਤੁਲਨਾ ਉਹਨਾਂ outcomes ਨਾਲ ਕਰ ਸਕਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਸਮਝਦੇ ਹੋ: support tickets, known integrations, internal tools, ਅਤੇ ਉਹ crawlers ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਪਛਾਣਦੇ ਹੋ।
ਇਹ enforcement ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਤਿੰਨ ਚੀਜ਼ਾਂ ਦਿੰਦਾ ਹੈ:
- ਇੱਕ baseline. ਤੁਹਾਡਾ traffic route ਅਨੁਸਾਰ human-directed, AI-assisted, agent-driven ਜਾਂ unknown ਕਿੰਨਾ ਹੈ।
- evidence 'ਤੇ ਭਰੋਸਾ. ਕਿਹੜੇ signals ਤੁਹਾਡੀ ਵੈੱਬਸਾਈਟ 'ਤੇ ਮਜ਼ਬੂਤ ਹਨ ਅਤੇ coverage ਕਿੱਥੇ ਵਧਾਉਣ ਦੀ ਲੋੜ ਹੈ।
- ਬਿਹਤਰ policies. ਅਸਲ patterns ਦੇ ਆਧਾਰ 'ਤੇ ਬਣੇ rules, assumptions ਦੀ ਬਜਾਏ, ਜਿੱਥੇ false positives ਕਿਸੇ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ review ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
ਜਦੋਂ ਕੋਈ policy ਤਿਆਰ ਹੋ ਜਾਂਦੀ ਹੈ, ਤੁਸੀਂ ਉਸਨੂੰ ਉਸ specific workflow ਲਈ enable ਕਰਦੇ ਹੋ ਜਿਸ ਲਈ ਇਹ ਬਣਾਈ ਗਈ ਸੀ, ਅਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਸੇ ਵੀ ਸਮੇਂ adjust ਕਰਨ ਦੀ ਸਮਰਥਾ ਰੱਖਦੇ ਹੋ।
ਕਿਉਂ evidence-backed detection opaque scores ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ
ਵੈੱਬਸਾਈਟਾਂ ਪਹਿਲਾਂ ਹੀ agents, assistants ਅਤੇ AI ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਲੋਕਾਂ ਨੂੰ ਨਾਲ-ਨਾਲ ਸੇਵਾ ਦਿੰਦੀਆਂ ਹਨ। ਜੋ ਟੀਮਾਂ ਇਸ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੰਭਾਲਣਗੀਆਂ, ਉਹ ਸਭ ਤੋਂ aggressive filters ਵਾਲੀਆਂ ਨਹੀਂ ਹੋਣਗੀਆਂ। ਉਹ ਉਹਨਾਂ ਟੀਮਾਂ ਵਿੱਚੋਂ ਹੋਣਗੀਆਂ ਜੋ ਆਪਣੀਆਂ decisions ਸਮਝਾ ਸਕਦੀਆਂ ਹਨ।
Evidence-backed results ਤੁਹਾਨੂੰ ਉਹ explanation ਦਿੰਦੇ ਹਨ। ਜਦੋਂ ਕੋਈ support agent ਪੁੱਛਦਾ ਹੈ ਕਿ ਕਿਸੇ user ਨੇ ਵਾਧੂ verification step ਕਿਉਂ ਦੇਖੀ, ਤੁਸੀਂ evidence ਅਤੇ ਲਾਗੂ ਹੋਈ policy ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਸਕਦੇ ਹੋ। ਜਦੋਂ ਕੋਈ agent operator ਪੁੱਛਦਾ ਹੈ ਕਿ ਉਸ ਦੀਆਂ signed requests ਨੂੰ structured response ਕਿਉਂ ਮਿਲਿਆ, ਤੁਸੀਂ verified ਆਧਾਰ ਦਿਖਾ ਸਕਦੇ ਹੋ। ਜਦੋਂ evidence ਕਮਜ਼ੋਰ ਹੁੰਦਾ ਹੈ, result Unknown ਕਹਿੰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡਾ fallback ਉਸਨੂੰ ਉਸ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਜਾਣ-ਬੂਝ ਕੇ ਚੁਣਿਆ ਹੈ।
ਇਹ approach web ਨਾਲ ਵੀ scale ਕਰਦੀ ਹੈ। ਜਿਵੇਂ-ਜਿਵੇਂ ਹੋਰ agent operators ਆਪਣੀਆਂ requests sign ਕਰਦੇ ਹਨ ਅਤੇ standards work ਜਿਵੇਂ IETF Web Bot Auth working group, ਜੋ automated clients ਲਈ cryptographic authentication standardize ਕਰਨ ਲਈ chartered ਹੈ, HTTP message signatures 'ਤੇ ਬਣਦਾ ਹੈ, ਤੁਹਾਡਾ ਹੋਰ traffic inferred ਜਾਂ unknown ਤੋਂ verified ਵੱਲ ਚਲਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੀਆਂ policies ਹੋਰ ਸਹੀ ਬਣਦੀਆਂ ਹਨ ਬਿਨਾਂ ਦੁਬਾਰਾ ਲਿਖੀਆਂ ਜਾਣ ਦੇ।
founding developer program ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੋ
Proof of Actor ਕੁਝ application teams ਦੇ ਛੋਟੇ ਗਰੁੱਪ ਨਾਲ private beta ਵਿੱਚ ਹੈ। ਚੁਣੇ ਗਏ founding developers ਸਹਿਮਤ usage limits ਦੇ ਅੰਦਰ, hands-on product feedback ਦੇ ਬਦਲੇ up to 12 months ਦਾ free access ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਸਾਡੇ engineers ਤੋਂ direct integration support, capabilities ਜਿਵੇਂ-ਜਿਵੇਂ ਉਪਲਬਧ ਹੁੰਦੀਆਂ ਹਨ ਉਨ੍ਹਾਂ ਤੱਕ early access, ਅਤੇ ਅਸੀਂ ਅੱਗੇ ਕੀ ਬਣਾਉਂਦੇ ਹਾਂ ਇਸ 'ਤੇ ਅਸਲ ਪ੍ਰਭਾਵ ਮਿਲਦਾ ਹੈ।
ਜੇਕਰ ਤੁਹਾਡੀ ਵੈੱਬਸਾਈਟ ਲੋਕਾਂ, AI-assisted users ਅਤੇ agents ਨੂੰ ਸੇਵਾ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਇਹ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਅੱਗੇ ਕੀ ਹੁੰਦਾ ਹੈ ਇਹ ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਕੌਣ ਵਰਤ ਰਿਹਾ ਹੈ, ਤਾਂ early access ਲਈ apply ਕਰੋ. ਸਾਨੂੰ ਆਪਣੀ ਵੈੱਬਸਾਈਟ ਅਤੇ ਉਸ interaction ਬਾਰੇ ਦੱਸੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਸਭ ਤੋਂ ਵੱਧ ਸਮਝਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਅਸੀਂ review ਕਰਾਂਗੇ ਕਿ ਕੀ ਇਹ ਮੌਜੂਦਾ beta ਲਈ fit ਹੈ।
ਪਹਿਲਾਂ ਵੇਰਵੇ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ? Proof of Actor explore ਕਰੋ, ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਪੜ੍ਹੋ, ਜਾਂ ਸਹੀ-ਸਹੀ review ਕਰੋ ਕਿ ਸਬੂਤ ਕੀ establish ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ.
ਸਰੋਤ
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- Web Bot Auth (webbotauth) working group charter, IETF.
- Overview of OpenAI crawlers, OpenAI.
- Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.
- Verifying Googlebot and other Google crawlers, Google Search Central.
- How to verify that Bingbot is Bingbot, Bing Webmaster Blog.