ಎರಡು ವರ್ಗಗಳು ಈಗ ಸಾಕಾಗುವುದಿಲ್ಲ
ವರ್ಷಗಳ ಕಾಲ, ಟ್ರಾಫಿಕ್ ಅನ್ನು ಎರಡು ಗುಂಪುಗಳಾಗಿ ಹಂಚಲಾಗುತ್ತಿತ್ತು: ಮಾನವರು ಮತ್ತು bots. ಮಾನವರಿಗೆ ಉತ್ಪನ್ನ ದೊರೆಯುತ್ತಿತ್ತು. bots ಗಳನ್ನು block, rate-limit ಅಥವಾ ignore ಮಾಡಲಾಗುತ್ತಿತ್ತು.
ಆ ವಿಭಜನೆ ಈಗ ಉಳಿದಿಲ್ಲ. ಕೆಲವು automated visitors ಗಳು ನಿಜವಾದ customers ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ agents: plans ಹೋಲಿಸುವ assistant, ನಿಮ್ಮ API ಮೂಲಕ data ತೆಗೆದುಕೊಳ್ಳುವ agent, ಕೆಲಸ ಮುಗಿಸಲು ನಿಮ್ಮ MCP server ಅನ್ನು ಕರೆಯುವ tool. AI providers ಕೂಡ ಈಗ ಈ ರೀತಿಯ user-initiated access ಅನ್ನು ಸ್ವತಃ ದಾಖಲಿಸುತ್ತಿದ್ದಾರೆ: ಬಳಕೆದಾರರು ChatGPT ಗೆ ಪ್ರಶ್ನೆ ಕೇಳಿದಾಗ ಅದರ ChatGPT-User agent pages ಭೇಟಿ ಮಾಡುತ್ತದೆ ಎಂದು OpenAI ಹೇಳುತ್ತದೆ (OpenAI crawler documentation), ಮತ್ತು ಅದೇ ಉದ್ದೇಶಕ್ಕೆ Anthropic Claude-User ಅನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ (Anthropic crawler documentation). ಅದೇ ಸಮಯದಲ್ಲಿ, ಕೆಲವು ಜನರು AI ಜೊತೆ ಕೈ ಜೋಡಿಸಿ, ಸಂದೇಶಗಳನ್ನು draft ಮಾಡುತ್ತಾರೆ, forms ತುಂಬುತ್ತಾರೆ ಮತ್ತು ತಮ್ಮ ಪಕ್ಕದಲ್ಲಿ assistant ಇಟ್ಟುಕೊಂಡೇ ಉತ್ಪನ್ನಗಳನ್ನು ಬಳಸುತ್ತಾರೆ. ಇದನ್ನೆಲ್ಲ human ಅಥವಾ bot ಗೆ ತಳ್ಳುವುದರಿಂದ ಎರಡೂ ದಿಕ್ಕಿನಲ್ಲಿ ಕೆಟ್ಟ ನಿರ್ಧಾರಗಳು ಬರುತ್ತವೆ. ಕಾನೂನುಬದ್ಧ agents block ಆಗುತ್ತಾರೆ, ಮತ್ತು ನಿಜವಾದ ಜನರು ಅವರ ವರ್ತನೆ ಅಸಾಮಾನ್ಯವಾಗಿ ಕಾಣುವುದರಿಂದ challenge ಆಗುತ್ತಾರೆ.
ಒಳ್ಳೆಯ ನಿರ್ಧಾರಗಳಿಗೆ ದಾರಿ ಮಾಡುವ ರೀತಿಯಲ್ಲಿ ಮಾನವ ಮತ್ತು AI ಏಜೆಂಟ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ವಿಭೇದಿಸಲು, ನಿಮಗೆ ಹೆಚ್ಚು ವರ್ಗಗಳು ಬೇಕು ಮತ್ತು ಪ್ರತಿಯೊಂದು ಫಲಿತಾಂಶವನ್ನು ಎಷ್ಟು ನಂಬಬಹುದು ಎಂಬುದನ್ನೂ ತಿಳಿದುಕೊಳ್ಳಬೇಕು. ವೆಬ್ಸೈಟ್ ಟ್ರಾಫಿಕ್ AI agents ನಿಂದ ಬರುತ್ತದೆಯೇ ಎಂದು ಹೇಗೆ ಗುರುತಿಸುವುದು ಎಂಬ blog post ಇದನ್ನು ಸಾಧ್ಯವಾಗಿಸುವ signals ಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು SaaS apps use case ಈ ವಿಭೇದವು product decisions ಅನ್ನು ಎಲ್ಲಿ ಬದಲಾಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.
ನಾಲ್ಕು ವರ್ಗಗಳು, ಪ್ರತಿಯೊಂದಕ್ಕೂ ನಿಖರ ಅರ್ಥ
Proof of Actor ಸಂವಹನಗಳನ್ನು ನಾಲ್ಕು ವರ್ಗಗಳಲ್ಲಿ classify ಮಾಡುತ್ತದೆ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ವ್ಯಾಖ್ಯಾನ ಮತ್ತು ಸ್ಪಷ್ಟ ಮಿತಿ ಇದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ತಂಡದ ಯಾರೂ ಸಹ evidence ಬೆಂಬಲಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಅರ್ಥವನ್ನು ಫಲಿತಾಂಶಕ್ಕೆ ನೀಡುವುದಿಲ್ಲ. ಈ taxonomy ಯ ಹಿಂದೆ ಇರುವ reasoning ಗೆ Human, AI-assisted or agent: a taxonomy for app traffic ಅನ್ನು ಓದಿ.
Human
supported observable signals ಮಾನವ-ನಿರ್ದೇಶಿತ ಸಂವಹನವನ್ನು ಸೂಚಿಸುತ್ತವೆ. ಈ ವರ್ಗವು identity ಬಗ್ಗೆ ಅಲ್ಲ, ಸಂವಹನವನ್ನು ಯಾರು ನಿರ್ದೇಶಿಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದರ ಬಗ್ಗೆ. Human ಫಲಿತಾಂಶವು ಆ ವ್ಯಕ್ತಿ ಯಾರು ಎಂಬುದನ್ನು verify ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಎಲ್ಲಿಯಾದರೂ AI ಬಳಸಲಾಗಲಿಲ್ಲ ಎಂದು ಸಹ ಹೇಳುವುದಿಲ್ಲ.
Human + AI
AI ಸಹಾಯವನ್ನು ಘೋಷಿಸಲಾಗಿದೆ, ಅಥವಾ ಅದನ್ನು ಕಾಣಬಲ್ಲ supported integration ಮೂಲಕ ಗಮನಿಸಲಾಗಿದೆ. ಉದಾಹರಣೆಗಳಿಗೆ ನಿಮ್ಮ own disclosure control ಮೂಲಕ content ಅನ್ನು AI ಸಹಿತ draft ಮಾಡಲಾಗಿದೆ ಎಂದು user ಗುರುತಿಸುವುದು, ಅಥವಾ signed-in user ಗೆ action ನಡೆಯಿತು ಎಂದು ನಿಮ್ಮ application ತನ್ನ built-in assistant ವರದಿ ಮಾಡುವುದು ಸೇರಿವೆ. ಇನ್ನಷ್ಟು ವಿವರಗಳಿಗೆ AI-assisted interaction glossary entry ನೋಡಿ.
Agent
ಸ್ವಯಂಚಾಲಿತ ಅಥವಾ agent-origin ಸಂವಹನ, ಉದಾಹರಣೆಗೆ published key ನಿಂದ valid request signature ಎಂಬಂತೆ ಪರಿಶೀಲಿಸಬಹುದಾದ identity ಮೂಲಕ, ಅಥವಾ ಅತ್ಯಂತ ಎಚ್ಚರಿಕೆಯಿಂದ ಅರ್ಹಗೊಳಿಸಿದ inference ಮೂಲಕ supported ಆಗಿರುತ್ತದೆ. Agent ಫಲಿತಾಂಶವು ಯಾರು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ. agent ಗೆ authorization ಇದೆ, ಅದು safe, ಅಥವಾ ವ್ಯಕ್ತಿಯಿಂದ valid delegation ಇದೆ ಎಂಬುದನ್ನು ಅದು ಅರ್ಥವಾಗಿಸುವುದಿಲ್ಲ. autonomous agents ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ಓದಿ.
Unknown
ಲಭ್ಯವಿರುವ evidence ನಂಬಲರ್ಹ ನಿರ್ಧಾರಕ್ಕೆ ಸಾಕಾಗುವುದಿಲ್ಲ. Unknown ಎಂಬುದು ಪ್ರಾಮಾಣಿಕ ಮತ್ತು ಉಪಯುಕ್ತ ಫಲಿತಾಂಶ: ಅದು ನಿಮ್ಮ coverage ಎಲ್ಲಿ ಮುಗಿಯುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ policies ಅನಿಶ್ಚಿತ ಪ್ರಕರಣಗಳನ್ನು ಅಪಘಾತದಿಂದಲ್ಲ, ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿರ್ವಹಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ.
ಪ್ರತಿಯೊಂದು ವರ್ಗಕ್ಕೂ ಒಂದು basis ಇರುತ್ತದೆ
ಮಾನವ ಮತ್ತು agent ಟ್ರಾಫಿಕ್ ಅನ್ನು ಬೇರ್ಪಡಿಸುವುದು ಕೆಲಸದ ಅರ್ಧ ಮಾತ್ರ. ಇನ್ನೊಂದು ಅರ್ಧ ಪ್ರತಿಯೊಂದು ನಿರ್ಣಯ ಎಷ್ಟು ಬಲವಾಗಿದೆ ಎಂಬುದನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು. ಅದಕ್ಕಾಗಿ ಪ್ರತಿಯೊಂದು Proof of Actor ಫಲಿತಾಂಶವೂ ಒಂದು basis ಹೊರುತ್ತದೆ:
- Verified: ಪರಿಶೀಲಿಸಬಹುದಾದ assertion ಮಾನ್ಯಗೊಂಡಿದೆ, ಉದಾಹರಣೆಗೆ published key ವಿರುದ್ಧ ಪರಿಶೀಲಿಸಿದ request signature.
- Declared: client ಅಥವಾ ನಿಮ್ಮ application ಅದನ್ನು ಹೇಳಿದೆ, ಉದಾಹರಣೆಗೆ ತನ್ನನ್ನೇ ಹೆಸರಿಸುವ agent ಅಥವಾ AI ಸಹಾಯವನ್ನು ಬಹಿರಂಗಪಡಿಸುವ user.
- Inferred: behavioral ಅಥವಾ contextual signals ನಿಂದ ತೆಗೆದ ನಿರ್ಣಯ, ಯಾವಾಗಲೂ inference ಎಂದು label ಮಾಡಲ್ಪಟ್ಟಿದೆ.
- Unknown: ನಿರ್ಧಾರಕ್ಕೆ ಸಾಕಷ್ಟು evidence ಇಲ್ಲ.
ವರ್ಗ ಮತ್ತು basis ಗಳ ಸಂಯೋಜನೆಯೇ ನಿಮಗೆ ನಿಖರ ನಿಯಮಗಳನ್ನು ನಿರ್ಮಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ. verified agent ಮತ್ತು inferred agent ಎರಡೂ agents ಆಗಿವೆ, ಆದರೆ ಮೊದಲನೆಯದಕ್ಕೆ structured API ನೀಡಲು ಮತ್ತು ಎರಡನೆಯದಕ್ಕೆ standard rate limit ಅನ್ವಯಿಸಲು ನೀವು ಬಯಸಬಹುದು. declared AI-assisted submission ಮತ್ತು human session ಎರಡೂ ಸಾಮಾನ್ಯವಾಗಿ ಮುಂದುವರಿಯಬಹುದು, ಮತ್ತು ನಿಮ್ಮ support team ಗೆ ಸಹಾಯಕವಾಗುವ label ಇರುತ್ತದೆ. ಸಂಪೂರ್ಣ taxonomy ಅನ್ನು Detection & Limitations ನಲ್ಲಿ ಕಾಣಬಹುದು.
ವರ್ಗೀಕರಣ ಹೇಗೆ ನಡೆಯುತ್ತದೆ
Proof of Actor ಪ್ರತಿಯೊಂದು ಸಂವಹನಕ್ಕೂ ಅದೇ evidence-first ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಸಂಪೂರ್ಣ ವಿವರಣೆ How It Works ನಲ್ಲಿ ಇದೆ.
ನಿಮ್ಮ integration ನೋಡಬಹುದಾದ signals
- Request signatures automated clients ನಿಂದ, ಅವರು ತಮ್ಮ keys ಪ್ರಕಟಿಸಿದಾಗ, RFC 9421 ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದಂತೆ HTTP Message Signatures ಬಳಸಿ. IETF Web Bot Auth working group ಈ ವಿಧಾನದಿಂದ automated clients authentication ಹೇಗೆ ಮಾಡಬೇಕು ಎಂಬುದನ್ನು standardize ಮಾಡಲು charter ಮಾಡಲಾಗಿದೆ.
- Declarations ತಮಗೇ ಗುರುತು ಹೇಳಿಕೊಳ್ಳುವ clients ನಿಂದ, ಉದಾಹರಣೆಗೆ AI crawlers ಮತ್ತು fetchers ಗಳ documented user agents, ಮತ್ತು AI ಸಹಾಯ ಒಳಗೊಂಡಿದೆ ಎಂಬುದನ್ನು ನಿಮ್ಮ own application ತಿಳಿದಿರುವಾಗ ಅದರಿಂದ.
- Request context server-side integration ಗೆ ಲಭ್ಯವಿರುವುದು, ಉದಾಹರಣೆಗೆ headers ಮತ್ತು protocol ವಿವರಗಳು.
- Interaction signals ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುವ pages ಗಳಲ್ಲಿರುವ approved browser integration ನಿಂದ.
signals ಗಳಿಂದ ಫಲಿತಾಂಶಕ್ಕೆ
Signals ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, basis ಪ್ರಕಾರ label ಮಾಡಿ, ನಂತರ ಸಂಯೋಜಿಸಲಾಗುತ್ತದೆ. ಬಲವಾದ verified evidence ಆತ್ಮವಿಶ್ವಾಸದ ಫಲಿತಾಂಶವನ್ನು ನೀಡುತ್ತದೆ. ದುರ್ಬಲ ಅಥವಾ ಪರಸ್ಪರ ವಿರೋಧಿ evidence ಅರ್ಹಗೊಳಿಸಿದ inference ಅಥವಾ Unknown ಅನ್ನು ನೀಡುತ್ತದೆ. timeout ಅಥವಾ ಕಾಣೆಯಾಗಿರುವ signal ಎಂದಿಗೂ Human ಫಲಿತಾಂಶವಾಗುವುದಿಲ್ಲ. output ನಲ್ಲಿ class, basis ಮತ್ತು evidence summary ಇರುತ್ತದೆ, ನಿಮ್ಮ ತಂಡದ ಯಾರೂ ಅದನ್ನು ಓದಬಹುದು.
ಟ್ರಾಫಿಕ್ ಬೇರ್ಪಟ್ಟ ನಂತರ ನೀವು ಏನು ಮಾಡಬಹುದು
Proof of Actor ಮೂರು ಸಾಮರ್ಥ್ಯಗಳ ಸುತ್ತ ಸಂಘಟಿತವಾಗಿದೆ: Detect, Understand ಮತ್ತು Route.
ಪ್ರತಿ ಸಂವಹನದ ಹಿಂದೆ ಇರುವ actor ಅನ್ನು Detect ಮಾಡಿ
ಪ್ರತಿಯೊಂದು context ನಲ್ಲಿ ಲಭ್ಯವಿರುವ signals ಸಂಗ್ರಹಿಸಿ ಮತ್ತು verified assertions ಗಳನ್ನು inferences ಗಳಿಂದ ಬೇರ್ಪಡಿಸಿ. Unknown ಅನ್ನು ದೃಶ್ಯವಾಗಿಯೇ ಇರಿಸಿ.
ಪ್ರತಿ actor ನಿಮ್ಮ product ಅನ್ನು ಹೇಗೆ ಬಳಸುತ್ತದೆ ಎಂಬುದನ್ನು Understand ಮಾಡಿ
route ಪ್ರಕಾರ ಮತ್ತು ಸಮಯದೊಂದಿಗೆ human, AI-assisted, agent ಮತ್ತು unknown activity ಯ ಮಿಶ್ರಣವನ್ನು ನೋಡಿ. ಯಾವುದಾದರೂ result ತೆರೆಯಿರಿ, ಏನು ತಿಳಿದಿದೆ ಮತ್ತು ಏನು ತಿಳಿದಿಲ್ಲ ಎಂಬುದನ್ನು ನೋಡಿ. agents ಏಕಾಗ್ರವಾಗಿರುವ routes ಮತ್ತು AI ಸಹಾಯ ಸಾಮಾನ್ಯವಾಗಿರುವ workflows ಅನ್ನು ಗುರುತಿಸಿ.
ಪ್ರತಿ actor ಅನ್ನು ಸರಿಯಾದ experience ಗೆ Route ಮಾಡಿ
ಸಾಕ್ಷ್ಯವು ಅವನ್ನು ಬೆಂಬಲಿಸಿದ ನಂತರ ನಿಮ್ಮ own policies ಅನ್ವಯಿಸಿ. public website ನಲ್ಲಿ, websites use case ಈ ಆಯ್ಕೆಗಳು ನಿಜವಾದ routes ಗಳಿಗೆ ಹೇಗೆ map ಆಗುತ್ತವೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ:
- verified agents ಗೆ human-shaped pages ಬದಲು structured response ಅಥವಾ API ನೀಡಿ.
- human-directed sessions ಗೆ standard experience ಅನ್ನು ಉಳಿಸಿ.
- ಸರಿಯಾದ team ಅದನ್ನು ನಿರ್ವಹಿಸುವಂತೆ AI-assisted submissions ಗಳನ್ನು label ಮಾಡಿ.
- ನಿಮ್ಮ own conditions ಅವನ್ನು ಕೇಳಿದಾಗ sensitive actions ಗೆ stronger credentials ಕೇಳಿ.
- ಪ್ರತಿಯೊಂದು route ಗೆ Unknown ಗಾಗಿ ಸ್ಪಷ್ಟ fallback ಆಯ್ಕೆಮಾಡಿ, ಉದಾಹರಣೆಗೆ public pages ಗೆ ಅನುಮತಿಸಿ ಮತ್ತು account changes ಮೇಲೆ existing checks ಉಳಿಸಿ.
rolling out actor-aware policies safely guide ನಲ್ಲಿ observation ನಿಂದ enforcement ಗೆ ಒಂದೊಂದು route ಮಾಡಿ ಹೇಗೆ ಸಾಗಬೇಕು ಎಂಬುದನ್ನು ಒಳಗೊಂಡಿದೆ.
ಇದು ನಿಮ್ಮ users ಗೆ ಏಕೆ ಮುಖ್ಯ
ಇದನ್ನು ಸರಿಯಾಗಿ ಮಾಡುವುದು ನಿಮ್ಮ application ಬಳಸುವ ಎಲ್ಲರಿಗೂ ಒಳ್ಳೆಯದು.
ಜನರು ಸುಗಮವಾದ experience ಪಡೆಯುತ್ತಾರೆ, ಏಕೆಂದರೆ ಅವರಿಗೆ vague score ನ ಆಧಾರದಲ್ಲಿ ಪ್ರಶ್ನೆ ಎದುರಾಗುವುದಿಲ್ಲ. AI ಜೊತೆ ಕೆಲಸ ಮಾಡುವ ಜನರಿಗೆ ಅದು ಸರಿಹೊಂದುವ workflows ನಲ್ಲಿ ಬಹಿರಂಗಪಡಿಸಿದ ಸಹಾಯಕ್ಕೆ support ದೊರೆಯುತ್ತದೆ. ಕಾನೂನುಬದ್ಧ agents ಅವರಿಗೆ ತಮ್ಮ ಕೆಲಸಗಳನ್ನು ಮಾಡಲು reliable, structured ಮಾರ್ಗ ಸಿಗುತ್ತದೆ, ಇದರಿಂದ ನಿಮ್ಮ interface ಮೇಲಿನ scraping ಮತ್ತು load ಕಡಿಮೆಯಾಗುತ್ತದೆ. ನಿಮ್ಮ ತಂಡಕ್ಕೆ explainable decisions ಸಿಗುತ್ತವೆ, ಆದ್ದರಿಂದ support conversations, incident reviews ಮತ್ತು policy changes guesswork ಬದಲು evidence ಮೇಲೆ ಆಧಾರವಾಗಿರುತ್ತವೆ.
login ಎಂದರೆ actor ಅಲ್ಲ
ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಗೊಂದಲದ ಮೂಲಗಳಲ್ಲಿ ಒಂದು account ತಾನೇ. signed-in session ಯಾವ account ಬಳಕೆಯಲ್ಲಿದೆ ಎಂಬುದನ್ನು ಹೇಳುತ್ತದೆ. ಆದರೆ current interaction ಅನ್ನು ಯಾರು ನಿರ್ದೇಶಿಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಹೇಳುವುದಿಲ್ಲ. ಅದೇ account ಅನ್ನು ಬೆಳಿಗ್ಗೆ ಅದರ owner settings ಮೂಲಕ click ಮಾಡುವುದಕ್ಕೂ, ಮಧ್ಯಾಹ್ನ report export ಮಾಡಲು owner ಕೇಳಿದ assistant ಗೆ, ಮತ್ತು ಸಂಜೆ API key ಮೂಲಕ ಕೆಲಸ ಮಾಡುವ agent ಗೆ ಬಳಸಬಹುದು.
ಈ ಮೂರನ್ನೂ ಒಂದೇ ರೀತಿಯಲ್ಲಿ ಪರಿಗಣಿಸುವುದರಿಂದ ಎರಡೂ ದಿಕ್ಕಿನಲ್ಲಿ ಸಮಸ್ಯೆಗಳು ಉಂಟಾಗುತ್ತವೆ. account ನಲ್ಲಿನ ಪ್ರತಿಯೊಂದು request ಅನ್ನು owner ಎಂದು ಊಹಿಸಿದರೆ, person ಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದ workflows ಗೆ agent ಪ್ರವೇಶಿಸಬಹುದು. ಅಸಾಮಾನ್ಯ request ಪ್ರತಿಯೊಂದನ್ನೂ attack ಎಂದು ಊಹಿಸಿದರೆ, owner ನ own tools block ಆಗುತ್ತವೆ. actor ಅನ್ನು account ನಿಂದ ಬೇರ್ಪಡಿಸುವುದರಿಂದ ನಿಮ್ಮ application authentication ಮತ್ತು authorization ಅನ್ನು ಹಾಗೆಯೇ ಉಳಿಸಿ, ಈಗ ಯಾರು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದಾರೆ ಎಂಬ missing context ಅನ್ನು ಸೇರಿಸಬಹುದು. ಆ context ನಿಂದ agents ಗೆ human-only workflows ತೆರೆಯದೇ structured access ನೀಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
observation mode ನಲ್ಲಿ ಆರಂಭಿಸಿ
ಪ್ರತಿಯೊಂದು deployment observation mode ನಲ್ಲಿ ಆರಂಭವಾಗುತ್ತದೆ. ನಿಮ್ಮ application ಹಿಂದಿನಂತೆಯೇ ಪ್ರತಿಕ್ರಿಯಿಸುವಾಗ Proof of Actor ಫಲಿತಾಂಶಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ನಿಮ್ಮ ತಂಡ human, AI-assisted, agent ಮತ್ತು unknown activity ಯ baseline ನಿರ್ಮಿಸುತ್ತದೆ, ಅದನ್ನು ನೀವು ಈಗಾಗಲೇ ತಿಳಿದಿರುವ outcomes ಗಳೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ, ಮತ್ತು ಒಂದೇ ಒಂದು ನಿಯಮ ಬದಲಾಯಿಸುವ ಮೊದಲು false positives ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಒಂದು policy ಸಿದ್ಧವಾದಾಗ, ನೀವು ಅದನ್ನು ಒಂದು workflow ಗೆ enable ಮಾಡಿ, ನಂತರ ಅಲ್ಲಿಂದ ವಿಸ್ತರಿಸುತ್ತೀರಿ.
founding developer program ಗೆ ಸೇರಿ
Proof of Actor ಕೆಲವೇ application teams ಗಳೊಂದಿಗೆ private beta ಯಲ್ಲಿದೆ. ಆಯ್ಕೆಯಾದ founding developers ಗೆ ಒಪ್ಪಿಗೆಯಾದ usage limits ಒಳಗೆ, hands-on feedback ಗೆ ಬದಲಾಗಿ, 12 ತಿಂಗಳುಗಳವರೆಗೆ ಉಚಿತ access ದೊರೆಯಬಹುದು. ನೀವು ನಮ್ಮ engineers ರಿಂದ ನೇರ integration support, capabilities ಗೆ early access, ಮತ್ತು priorities ಮೇಲೆ ಪ್ರಭಾವ ಪಡೆಯುತ್ತೀರಿ.
ನಿಮ್ಮ application ನಲ್ಲಿ ಮಾನವ ಮತ್ತು AI ಏಜೆಂಟ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ವಿಭೇದಿಸಬೇಕಿದ್ದರೆ, early access ಗೆ apply ಮಾಡಿ ಮತ್ತು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಹೆಚ್ಚು ಬಯಸುವ interaction ಬಗ್ಗೆ ನಮಗೆ ತಿಳಿಸಿ.
Proof of Actor ಅನ್ನು ಅನ್ವೇಷಿಸಿ, ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಓದಿ, ಅಥವಾ ಸಾಕ್ಷ್ಯವು ನಿಖರವಾಗಿ ಏನು ಸ್ಥಾಪಿಸಬಹುದು ಎಂದು ನೋಡಿ.
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.