ਦੋ categories ਹੁਣ ਕਾਫ਼ੀ ਨਹੀਂ ਹਨ
ਸਾਲਾਂ ਤੱਕ traffic ਨੂੰ ਦੋ buckets ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਸੀ: humans ਅਤੇ bots। Humans ਨੂੰ product ਮਿਲਦਾ ਸੀ। Bots ਨੂੰ block, rate-limit ਜਾਂ ignore ਕੀਤਾ ਜਾਂਦਾ ਸੀ।
ਉਹ ਵੰਡ ਹੁਣ ਕਾਇਮ ਨਹੀਂ ਰਹੀ। ਕੁਝ automated visitors agents ਹੁੰਦੇ ਹਨ ਜੋ ਅਸਲੀ customers ਦੀ ਵਕਾਲਤ ਕਰਦੇ ਹਨ: ਇੱਕ assistant plans compare ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਇੱਕ agent ਤੁਹਾਡੇ API ਰਾਹੀਂ data ਖਿੱਚ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਇੱਕ tool ਆਪਣੇ task ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਤੁਹਾਡੇ MCP server ਨੂੰ call ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। AI providers ਹੁਣ ਇਸ ਕਿਸਮ ਦੇ user-initiated access ਨੂੰ ਖੁਦ document ਕਰਦੇ ਹਨ: OpenAI ਕਹਿੰਦਾ ਹੈ ਕਿ ਉਸਦਾ ChatGPT-User agent pages ਨੂੰ visit ਕਰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ user ChatGPT ਤੋਂ ਕੋਈ question ਪੁੱਛਦਾ ਹੈ (OpenAI crawler documentation), ਅਤੇ Anthropic Claude-User ਨੂੰ ਉਸੇ ਮਕਸਦ ਲਈ list ਕਰਦਾ ਹੈ (Anthropic crawler documentation). ਇਸੇ ਸਮੇਂ, ਕੁਝ ਲੋਕ AI ਨਾਲ ਮਿਲ ਕੇ ਕੰਮ ਕਰਦੇ ਹਨ, messages draft ਕਰਦੇ ਹਨ, forms ਭਰਦੇ ਹਨ ਅਤੇ ਆਪਣੇ ਨਾਲ assistant ਰੱਖ ਕੇ products ਵਿੱਚ navigate ਕਰਦੇ ਹਨ। ਇਹ ਸਭ ਕੁਝ human ਜਾਂ bot ਵਿੱਚ force ਕਰਨਾ ਦੋਵੇਂ ਪਾਸਿਆਂ ਤੋਂ ਖਰਾਬ decisions ਪੈਦਾ ਕਰਦਾ ਹੈ। Legitimate agents block ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਅਸਲੀ ਲੋਕਾਂ ਨੂੰ challenge ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਦਾ behavior ਅਜੀਬ ਲੱਗਦਾ ਹੈ।
human ਅਤੇ AI agent ਟ੍ਰੈਫਿਕ ਵਿਚ ਫ਼ਰਕ ਕਰਨ ਲਈ, ਜਿਸ ਨਾਲ ਚੰਗੇ decisions ਤੱਕ ਪਹੁੰਚਿਆ ਜਾ ਸਕੇ, ਤੁਹਾਨੂੰ ਵੱਧ categories ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਇਹ ਜਾਣਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਹਰ result ਤੇ ਕਿੰਨਾ ਭਰੋਸਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਕਿਵੇਂ ਪਤਾ ਲਗਾਇਆ ਜਾਵੇ ਕਿ website traffic AI agents ਤੋਂ ਆ ਰਿਹਾ ਹੈ ਵਾਲਾ blog post ਉਹ signals ਸਮਝਾਉਂਦਾ ਹੈ ਜੋ ਇਹ ਸੰਭਵ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ SaaS apps use case ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਇਹ distinction product decisions ਨੂੰ ਕਿੱਥੇ ਬਦਲਦੀ ਹੈ।
ਚਾਰ classes, ਹਰ ਇੱਕ ਦਾ ਸਹੀ ਮਤਲਬ
Proof of Actor interactions ਨੂੰ ਚਾਰ classes ਵਿੱਚ classify ਕਰਦਾ ਹੈ। ਹਰ ਇੱਕ ਦੀ ਇੱਕ definition ਅਤੇ ਇੱਕ explicit limit ਹੈ, ਤਾਂ ਜੋ ਤੁਹਾਡੀ team ਵਿੱਚ ਕੋਈ ਵੀ result ਨੂੰ evidence ਤੋਂ ਵੱਧ ਨਾ ਪੜ੍ਹੇ। ਇਸ taxonomy ਦੇ reasoning ਲਈ, Human, AI-assisted or agent: a taxonomy for app traffic ਪੜ੍ਹੋ।
Human
Supported observable signals human-directed interaction ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ। ਇਹ class ਇਸ ਗੱਲ ਬਾਰੇ ਹੈ ਕਿ interaction ਨੂੰ ਕੌਣ direct ਕਰ ਰਿਹਾ ਹੈ, identity ਬਾਰੇ ਨਹੀਂ। Human result ਇਹ verify ਨਹੀਂ ਕਰਦਾ ਕਿ ਵਿਅਕਤੀ ਕੌਣ ਹੈ, ਅਤੇ ਇਹ ਇਹ claim ਨਹੀਂ ਕਰਦਾ ਕਿ ਕਿਤੇ ਵੀ AI ਵਰਤੀ ਨਹੀਂ ਗਈ।
Human + AI
AI assistance declared ਸੀ, ਜਾਂ ਇੱਕ supported integration ਰਾਹੀਂ observed ਸੀ ਜੋ ਇਸਨੂੰ ਵਾਸਤਵ ਵਿੱਚ ਵੇਖ ਸਕਦੀ ਹੈ। ਉਦਾਹਰਣਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ user ਦਾ ਆਪਣੇ disclosure control ਰਾਹੀਂ AI ਨਾਲ drafted content ਨੂੰ mark ਕਰਨਾ, ਜਾਂ ਤੁਹਾਡੀ application ਦਾ ਇਹ report ਕਰਨਾ ਕਿ ਉਸਦੇ built-in assistant ਨੇ signed-in user ਲਈ ਇੱਕ action ਕੀਤਾ। ਹੋਰ ਪੜ੍ਹੋ AI-assisted interaction glossary entry ਵਿੱਚ।
Agent
Automated ਜਾਂ agent-origin interaction, ਜੋ verifiable identity ਨਾਲ supported ਹੋਵੇ, ਜਿਵੇਂ published key ਤੋਂ valid request signature, ਜਾਂ ਧਿਆਨ ਨਾਲ qualified inference। Agent result ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕੌਣ act ਕਰ ਰਿਹਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ agent authorized ਹੈ, safe ਹੈ, ਜਾਂ ਕਿਸੇ person ਵੱਲੋਂ valid delegation ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। autonomous agents ਬਾਰੇ ਹੋਰ ਪੜ੍ਹੋ।
Unknown
ਉਪਲਬਧ evidence ਇੱਕ ਭਰੋਸੇਯੋਗ determination ਨੂੰ support ਨਹੀਂ ਕਰਦੀ। Unknown ਇੱਕ ਇਮਾਨਦਾਰ ਅਤੇ ਲਾਭਦਾਇਕ result ਹੈ: ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਤੁਹਾਡੀ coverage ਕਿੱਥੇ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਹ ਤੁਹਾਡੀਆਂ policies ਨੂੰ uncertain cases ਨੂੰ accident ਨਾਲ ਨਹੀਂ, ਸਗੋਂ ਜਾਣਬੂਝ ਕੇ handle ਕਰਨ ਦਿੰਦਾ ਹੈ।
ਹਰ class ਦੇ ਨਾਲ ਇੱਕ basis ਹੁੰਦਾ ਹੈ
Human ਅਤੇ agent traffic ਨੂੰ ਵੱਖਰਾ ਕਰਨਾ ਸਿਰਫ਼ ਅੱਧਾ ਕੰਮ ਹੈ। ਦੂਜਾ ਅੱਧਾ ਇਹ ਜਾਣਨਾ ਹੈ ਕਿ ਹਰ conclusion ਕਿੰਨਾ ਮਜ਼ਬੂਤ ਹੈ। ਇਸੇ ਲਈ ਹਰ Proof of Actor result ਦੇ ਨਾਲ ਇੱਕ basis ਹੁੰਦਾ ਹੈ:
- Verified: ਇੱਕ check ਕੀਤੀ ਜਾ ਸਕਣ ਵਾਲੀ assertion ਦੀ ਤਸਦੀਕ ਕੀਤੀ ਗਈ, ਉਦਾਹਰਣ ਵਜੋਂ ਇੱਕ request signature ਜੋ published key ਦੇ ਖ਼ਿਲਾਫ਼ checked ਕੀਤੀ ਗਈ ਹੋਵੇ।
- Declared: client ਜਾਂ ਤੁਹਾਡੀ application ਨੇ ਇਹ ਦਰਸਾਇਆ, ਉਦਾਹਰਣ ਵਜੋਂ ਇੱਕ agent ਦਾ ਆਪਣੇ ਆਪ ਨੂੰ ਨਾਮ ਦੇਣਾ ਜਾਂ ਇੱਕ user ਦਾ AI assistance reveal ਕਰਨਾ।
- Inferred: behavioral ਜਾਂ contextual signals ਤੋਂ ਕੱਢਿਆ ਗਿਆ conclusion, ਹਮੇਸ਼ਾ ਇੱਕ inference ਵਜੋਂ label ਕੀਤਾ ਗਿਆ।
- Unknown: determination ਲਈ ਕਾਫ਼ੀ evidence ਨਹੀਂ ਹੈ।
Class ਅਤੇ basis ਦਾ ਇਹ ਮਿਲਾਪ ਹੀ ਤੁਹਾਨੂੰ precise rules ਬਣਾਉਣ ਦਿੰਦਾ ਹੈ। ਇੱਕ verified agent ਅਤੇ ਇੱਕ inferred agent ਦੋਵੇਂ agents ਹਨ, ਪਰ ਤੁਸੀਂ ਪਹਿਲੇ ਨੂੰ structured API ਦੇਣਾ ਅਤੇ ਦੂਜੇ ਨੂੰ standard rate limit ਦੇ ਨਾਲ treat ਕਰਨਾ ਚਾਹ ਸਕਦੇ ਹੋ। ਇੱਕ declared AI-assisted submission ਅਤੇ ਇੱਕ human session ਦੋਵੇਂ normally ਅੱਗੇ ਵੱਧ ਸਕਦੇ ਹਨ, ਇੱਕ label ਦੇ ਨਾਲ ਜੋ ਤੁਹਾਡੀ support team ਦੀ ਮਦਦ ਕਰਦਾ ਹੈ। ਪੂਰੀ taxonomy ਤੁਹਾਨੂੰ Detection & Limitations ਵਿੱਚ ਮਿਲੇਗੀ।
Classification ਕਿਵੇਂ ਹੁੰਦੀ ਹੈ
Proof of Actor ਹਰ interaction ਲਈ ਉਹੀ evidence-first path follow ਕਰਦਾ ਹੈ। ਪੂਰੀ ਵਿਆਖਿਆ How It Works ਵਿੱਚ ਹੈ।
ਤੁਹਾਡੀ integration ਜੋ signals ਦੇਖ ਸਕਦੀ ਹੈ
- Request signatures automated clients ਤੋਂ, ਜੋ ਆਪਣੀਆਂ keys publish ਕਰਦੇ ਹਨ, HTTP Message Signatures ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਜਿਵੇਂ RFC 9421 ਵਿੱਚ defined ਹੈ। IETF Web Bot Auth working group ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ automated clients ਨੂੰ authenticate ਕਰਨ ਦੇ standard ਬਣਾਉਣ ਲਈ charter ਕੀਤਾ ਗਿਆ ਹੈ।
- Declarations clients ਵੱਲੋਂ ਜੋ ਆਪਣੇ ਆਪ ਨੂੰ identify ਕਰਦੇ ਹਨ, ਜਿਵੇਂ AI crawlers ਅਤੇ fetchers ਦੇ documented user agents, ਅਤੇ ਤੁਹਾਡੀ ਆਪਣੀ application ਵੱਲੋਂ ਜਦੋਂ ਉਹ ਜਾਣਦੀ ਹੈ ਕਿ AI assistance involved ਹੈ।
- Request context ਜੋ ਇੱਕ server-side integration ਲਈ available ਹੈ, ਜਿਵੇਂ headers ਅਤੇ protocol details।
- Interaction signals ਇੱਕ approved browser integration ਤੋਂ, ਉਹਨਾਂ pages ਤੇ ਜਿੱਥੇ ਇਹ run ਕਰਦੀ ਹੈ।
Signals ਤੋਂ result ਤੱਕ
Signals checked ਕੀਤੇ ਜਾਂਦੇ ਹਨ, basis ਦੇ ਨਾਲ label ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ combine ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਮਜ਼ਬੂਤ verified evidence ਇੱਕ confident result ਪੈਦਾ ਕਰਦੀ ਹੈ। ਕਮਜ਼ੋਰ ਜਾਂ conflicting evidence ਇੱਕ qualified inference ਜਾਂ Unknown ਪੈਦਾ ਕਰਦੀ ਹੈ। ਇੱਕ timeout ਜਾਂ missing signal ਕਦੇ ਵੀ Human result ਨਹੀਂ ਬਣਦਾ। Output ਇੱਕ class, ਇੱਕ basis ਅਤੇ ਇੱਕ evidence summary ਹੁੰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੀ team ਵਿੱਚ ਕੋਈ ਵੀ ਪੜ੍ਹ ਸਕਦਾ ਹੈ।
ਜਦੋਂ traffic ਵੱਖਰਾ ਹੋ ਜਾਵੇ ਤਾਂ ਤੁਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹੋ
Proof of Actor ਤਿੰਨ capabilities ਦੇ ਆਲੇ-ਦੁਆਲੇ organize ਕੀਤਾ ਗਿਆ ਹੈ: Detect, Understand ਅਤੇ Route।
ਹਰ interaction ਦੇ ਪਿੱਛੇ actor ਨੂੰ Detect ਕਰੋ
ਹਰ context ਵਿੱਚ available signals ਇਕੱਠੇ ਕਰੋ ਅਤੇ verified assertions ਨੂੰ inferences ਤੋਂ ਵੱਖ ਕਰੋ। Unknown ਨੂੰ visible ਰੱਖੋ।
ਸਮਝੋ ਕਿ ਹਰ actor ਤੁਹਾਡੇ product ਨੂੰ ਕਿਵੇਂ ਵਰਤਦਾ ਹੈ
Route ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ human, AI-assisted, agent ਅਤੇ unknown activity ਦਾ mix ਦੇਖੋ। ਕੋਈ ਵੀ result ਖੋਲ੍ਹੋ ਤਾਂ ਵੇਖ ਸਕੋ ਕਿ ਕੀ known ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ। ਉਹ routes ਪਛਾਣੋ ਜਿੱਥੇ agents ਇਕੱਠੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਉਹ workflows ਜਿੱਥੇ AI assistance ਆਮ ਹੈ।
ਹਰ actor ਨੂੰ ਸਹੀ experience ਵੱਲ Route ਕਰੋ
ਜਦੋਂ evidence ਉਨ੍ਹਾਂ ਨੂੰ support ਕਰਦੀ ਹੈ, ਆਪਣੀਆਂ policies ਲਾਗੂ ਕਰੋ। ਇੱਕ public website ਤੇ, websites use case ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਇਹ choices ਅਸਲੀ routes ਨਾਲ ਕਿਵੇਂ map ਹੁੰਦੀਆਂ ਹਨ:
- Verified agents ਨੂੰ human-shaped pages ਦੀ ਬਜਾਏ ਇੱਕ structured response ਜਾਂ API serve ਕਰੋ।
- Human-directed sessions ਲਈ standard experience ਬਣਾਈ ਰੱਖੋ।
- AI-assisted submissions ਨੂੰ label ਕਰੋ ਤਾਂ ਜੋ ਸਹੀ team ਉਨ੍ਹਾਂ ਨੂੰ handle ਕਰੇ।
- Sensitive actions ਤੇ stronger credentials ਮੰਗੋ ਜਦੋਂ ਤੁਹਾਡੀਆਂ ਆਪਣੀਆਂ conditions ਇਹ ਲੋੜੀਂਦੀਆਂ ਹੋਣ।
- ਹਰ route ਤੇ Unknown ਲਈ ਇੱਕ explicit fallback ਚੁਣੋ, ਜਿਵੇਂ public pages ਨੂੰ allow ਕਰਨਾ ਅਤੇ account changes ਤੇ ਮੌਜੂਦਾ checks ਬਣਾਈ ਰੱਖਣਾ।
rolling out actor-aware policies safely ਵਾਲਾ guide ਦੱਸਦਾ ਹੈ ਕਿ observation ਤੋਂ enforcement ਵੱਲ ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ route ਕਿਵੇਂ move ਕਰਨਾ ਹੈ।
ਇਹ ਤੁਹਾਡੇ users ਲਈ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
ਇਹ ਸਹੀ ਕਰਨਾ ਹਰ ਉਸ ਵਿਅਕਤੀ ਲਈ ਚੰਗਾ ਹੈ ਜੋ ਤੁਹਾਡੀ application ਵਰਤਦਾ ਹੈ।
ਲੋਕਾਂ ਨੂੰ smoother experience ਮਿਲਦੀ ਹੈ ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ vague score ਦੀ ਤਾਕਤ ਦੇ ਆਧਾਰ ਤੇ challenge ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ। AI ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲੇ ਲੋਕਾਂ ਨੂੰ ਉਹ workflows ਵਿੱਚ disclosed assistance ਲਈ support ਮਿਲਦੀ ਹੈ ਜਿੱਥੇ ਇਹ fit ਹੁੰਦੀ ਹੈ। Legitimate agents ਨੂੰ ਆਪਣੇ ਕੰਮ ਕਰਨ ਦਾ ਇੱਕ ਭਰੋਸੇਯੋਗ, structured ਤਰੀਕਾ ਮਿਲਦਾ ਹੈ, ਜਿਸ ਨਾਲ scraping ਅਤੇ ਤੁਹਾਡੇ interface ਤੇ load ਘੱਟ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਡੀ team ਨੂੰ explainable decisions ਮਿਲਦੀਆਂ ਹਨ, ਤਾਂ support conversations, incident reviews ਅਤੇ policy changes guesswork ਦੀ ਬਜਾਏ evidence ਤੇ ਆਧਾਰਿਤ ਹੁੰਦੇ ਹਨ।
Login actor ਨਹੀਂ ਹੁੰਦਾ
ਗੁੰਝਲ ਦਾ ਸਭ ਤੋਂ ਆਮ ਸਰੋਤ account ਖੁਦ ਹੈ। ਇੱਕ signed-in session ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਹੜਾ account ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ। ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ current interaction ਨੂੰ ਕੌਣ direct ਕਰ ਰਿਹਾ ਹੈ। ਉਹੀ account ਸਵੇਰੇ ਇਸਦੇ owner ਵੱਲੋਂ settings ਵਿੱਚ click ਕਰਨ ਲਈ, ਦੁਪਹਿਰ ਨੂੰ owner ਵੱਲੋਂ report export ਕਰਨ ਲਈ ਕਹੇ ਗਏ assistant ਵੱਲੋਂ, ਅਤੇ ਸ਼ਾਮ ਨੂੰ ਇੱਕ API key ਰਾਹੀਂ ਕੰਮ ਕਰਦੇ agent ਵੱਲੋਂ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਇਨ੍ਹਾਂ ਤਿੰਨਾਂ ਨੂੰ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ treat ਕਰਨ ਨਾਲ ਦੋਵੇਂ ਪਾਸਿਆਂ ਤੋਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ account ਤੇ ਹਰ request ਨੂੰ owner ਮੰਨ ਲਿਆ ਜਾਵੇ, ਤਾਂ ਇੱਕ agent ਉਹ workflows ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ ਜੋ ਇੱਕ person ਲਈ design ਕੀਤੇ ਗਏ ਸਨ। ਜੇ ਹਰ unusual request ਨੂੰ attack ਮੰਨ ਲਿਆ ਜਾਵੇ, ਤਾਂ owner ਦੇ ਆਪਣੇ tools block ਹੋ ਜਾਂਦੇ ਹਨ। Actor ਨੂੰ account ਤੋਂ ਵੱਖਰਾ ਕਰਨ ਨਾਲ ਤੁਹਾਡੀ application authentication ਅਤੇ authorization ਨੂੰ ਜਿਵੇਂ ਹਨ ਤਿਵੇਂ ਰੱਖ ਸਕਦੀ ਹੈ, ਅਤੇ ਹੁਣ ਕੌਣ act ਕਰ ਰਿਹਾ ਹੈ ਇਸ ਬਾਰੇ ਘਾਟ context ਜੋੜ ਸਕਦੀ ਹੈ। ਇਹ context ਹੀ agents ਨੂੰ structured access ਦੇਣਾ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ, ਬਿਨਾਂ human-only workflows ਨੂੰ ਉਨ੍ਹਾਂ ਲਈ ਖੋਲ੍ਹੇ।
Observation mode ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ
ਹਰ deployment observation mode ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। Proof of Actor results ਦਰਜ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਤੁਹਾਡੀ application ਬਿਲਕੁਲ ਪਹਿਲਾਂ ਵਾਂਗ respond ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ। ਤੁਹਾਡੀ team human, AI-assisted, agent ਅਤੇ unknown activity ਦਾ baseline ਬਣਾਉਂਦੀ ਹੈ, ਇਸਦੀ ਤੁਲਨਾ ਉਹਨਾਂ outcomes ਨਾਲ ਕਰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹੋ, ਅਤੇ ਇੱਕ ਵੀ rule ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਵੀ false positive ਦੀ review ਕਰਦੀ ਹੈ। ਜਦੋਂ policy ready ਹੋਵੇ, ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ workflow ਲਈ enable ਕਰਦੇ ਹੋ ਅਤੇ ਉੱਥੋਂ ਵਧਾਉਂਦੇ ਹੋ।
Founding developer program ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੋ
Proof of Actor ਕੁਝ application teams ਦੇ ਛੋਟੇ ਸਮੂਹ ਨਾਲ private beta ਵਿੱਚ ਹੈ। ਚੁਣੇ ਗਏ founding developers agreed usage limits ਦੇ ਅੰਦਰ, hands-on feedback ਦੇ ਬਦਲੇ 12 months ਤੱਕ free access ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਸਾਡੇ engineers ਵੱਲੋਂ direct integration support, capabilities ਤੱਕ early access, ਅਤੇ priorities ਤੇ ਪ੍ਰਭਾਵ ਮਿਲਦਾ ਹੈ।
ਜੇ ਤੁਹਾਨੂੰ ਆਪਣੀ application ਵਿੱਚ human ਅਤੇ AI agent ਟ੍ਰੈਫਿਕ ਵਿਚ ਫ਼ਰਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ early access ਲਈ apply ਕਰੋ ਅਤੇ ਸਾਨੂੰ ਉਸ interaction ਬਾਰੇ ਦੱਸੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਸਭ ਤੋਂ ਵੱਧ ਸਮਝਣਾ ਚਾਹੁੰਦੇ ਹੋ।
Proof of Actor explore ਕਰੋ, how it works ਪੜ੍ਹੋ, ਜਾਂ ਸਹੀ ਤੌਰ 'ਤੇ ਦੇਖੋ ਕਿ evidence ਕੀ establish ਕਰ ਸਕਦੀ ਹੈ।
Sources
- 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.