ಹೋಲಿಕೆ

Proof of Actor ವಿರುದ್ಧ ಬಾಟ್ ನಿರ್ವಹಣೆ: ಬೇರೆ ಪ್ರಶ್ನೆಗಳು, ಒಂದು ಸ್ಟ್ಯಾಕ್

Q: Proof of Actor ಟ್ರಾಫಿಕ್ ಅನ್ನು ಬ್ಲಾಕ್ ಮಾಡುತ್ತದೆಯೇ?

ಇಲ್ಲ. ಇದು observation ಮೋಡ್ನಲ್ಲಿ ಆರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ನೀವು ಒಂದು policy ಬರೆಯುವವರೆಗೂ ಏನನ್ನೂ ಬದಲಾಯಿಸುವುದಿಲ್ಲ. enforcement ಸದಾ ನಿಮ್ಮದೇ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ನಲ್ಲೇ ಇರುತ್ತದೆ.

ಬಾಟ್ ನಿರ್ವಹಣೆ ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯವನ್ನು ದುರುಪಯೋಗಕಾರಿ ಸ್ವಯಂಚಾಲನೆಯಿಂದ ರಕ್ಷಿಸುತ್ತದೆ. Proof of Actor ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಜನರು, AI ಸಹಾಯ ಪಡೆದ ಬಳಕೆದಾರರು ಮತ್ತು ಏಜೆಂಟ್‌ಗಳನ್ನು ವಿಭಿನ್ನವಾಗಿ ಸೇವಿಸಲು ಬೇಕಾದ actor ಸಂದರ್ಭವನ್ನು ನೀಡುತ್ತದೆ. ಅವು ಹೇಗೆ ಹೋಲುತ್ತವೆ ಮತ್ತು ಹೇಗೆ ಒಟ್ಟಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಎಂಬುದು ಇಲ್ಲಿದೆ.

ಮುಂಗಡ ಪ್ರವೇಶ ಪಡೆಯಿರಿ ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಅನ್ವೇಷಿಸಿ

ರಚನೆ Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

ಸಂಕ್ಷಿಪ್ತ ಉತ್ತರ

ಬಾಟ್ ನಿರ್ವಹಣೆ ಸ್ವಯಂಚಾಲಿತ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಎಡ್ಜ್‌ನಲ್ಲಿ ನಿಲ್ಲಿಸಬೇಕೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. Proof of Actor ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಯಾರು ಅಥವಾ ಏನು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂಬುದನ್ನು, Human, Human + AI, Agent ಅಥವಾ Unknown, ಅದರ ಹಿಂದೆ ಇರುವ ಸಾಕ್ಷ್ಯದೊಂದಿಗೆ ತಿಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮದೇ ಕೋಡ್ ಸರಿಯಾದ ಅನುಭವವನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು. ಇವು ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ, ಮತ್ತು ಬಹುತೇಕ ತಂಡಗಳು ಎರಡನ್ನೂ ಬಳಸುತ್ತವೆ.

ವೆಬ್‌ನ ಹೆಚ್ಚಿನ ಇತಿಹಾಸದಲ್ಲಿ, ಸ್ವಯಂಚಾಲಿತ ಟ್ರಾಫಿಕ್‌ಗೆ security stack‌ನಲ್ಲಿ ಒಂದೇ ಕೆಲಸ ಇತ್ತು: ಗುರುತಿಸಿಕೊಳ್ಳಿ ಮತ್ತು ನಿಲ್ಲಿಸಿ. ಬಾಟ್ ನಿರ್ವಹಣೆ ಅದೇ ಕೆಲಸದ ಸುತ್ತ ಬೆಳೆಯಿತು. ಅದು ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯದ ಎಡ್ಜ್‌ನಲ್ಲಿ ಕುಳಿತು requests ಅನ್ನು score ಮಾಡುತ್ತದೆ, ಮತ್ತು ದುರುಪಯೋಗಕಾರಿ ಎಂದು ಕಾಣುವವವನ್ನು block ಅಥವಾ challenge ಮಾಡುತ್ತದೆ. ಅದು ಅದರಲ್ಲಿ ಬಹಳ ಉತ್ತಮ, ಮತ್ತು ನೀವು ಅದನ್ನು ಇರಿಸಿಕೊಳ್ಳಬೇಕು.

AI agents ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ತಿಳಿಯಬೇಕಾದುದನ್ನು ಬದಲಾಯಿಸಿವೆ. ಈಗ ಸ್ವಯಂಚಾಲಿತ requests‌ನ ಹೆಚ್ಚುತ್ತಿರುವ ಭಾಗವು ನೈಜ ಗ್ರಾಹಕರಿಗಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಏಜೆಂಟ್‌ಗಳಿಂದ ಬರುತ್ತದೆ: plans ಹೋಲಿಸುವ assistant, support ticket ಸಲ್ಲಿಸುವ agent, ಕೆಲಸವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ನಿಮ್ಮ MCP server ಅನ್ನು ಕರೆ ಮಾಡುವ client. ಅದೇ ಸಮಯದಲ್ಲಿ, ಅನೇಕ ಜನರು ತಮ್ಮ ಉತ್ಪನ್ನವನ್ನು AI assistant ಜೊತೆ ಬಳಸುತ್ತಾರೆ. ಇವು ದಾಳಿಗಳಲ್ಲ. ಇವು ಬಳಕೆದಾರರು, ಮತ್ತು block page ಬದಲು ಸರಿಯಾದ experience ಅವರಿಗೆ ದೊರಕಬೇಕು.

ಆ ಅಂತರವನ್ನು Proof of Actor ತುಂಬುತ್ತದೆ. ಈ ಪುಟವು ಇಬ್ಬರ ವರ್ಗಗಳನ್ನು ಸರಳವಾಗಿ ಹೋಲಿಸುತ್ತದೆ, ώστε ಪ್ರತಿಯೊಂದು ಎಲ್ಲಿಗೆ ಸೇರುತ್ತದೆ ಎಂಬುದು ನಿಮಗೆ ಕಾಣಲಿ.

ಸಂಕ್ಷಿಪ್ತ ಆವೃತ್ತಿ

	ಬಾಟ್ ನಿರ್ವಹಣೆ	Proof of Actor
ಮುಖ್ಯ ಪ್ರಶ್ನೆ	ಈ request ನಿಲ್ಲಿಸಬೇಕೇ?	ಯಾರು ಅಥವಾ ಏನು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ, ಮತ್ತು ಸಾಕ್ಷ್ಯ ಏನು?
ಅದು ಎಲ್ಲಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ	ಎಡ್ಜ್‌ನಲ್ಲಿ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೂ ಮುನ್ನ	ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್, API ಅಥವಾ MCP server ಒಳಗೆ
ಸಾಮಾನ್ಯ output	allow, block ಅಥವಾ challenge; ಸಾಮಾನ್ಯವಾಗಿ score	Human, Human + AI, Agent ಅಥವಾ Unknown, ಜೊತೆಗೆ ಒಂದು basis
AI ಸಹಾಯ ಪಡೆದ ಜನರನ್ನು ಹೇಗೆ ಕಾಣುತ್ತದೆ	ಸಾಮಾನ್ಯವಾಗಿ ಇತರ ಜನರಿಂದ ಬೇರ್ಪಡಿಸಲಾಗುವುದಿಲ್ಲ	ವಿಭಿನ್ನ ವರ್ಗ, Human + AI
ಅಸ್ಪಷ್ಟ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹೇಗೆ ಕಾಣುತ್ತದೆ	ಸಾಮಾನ್ಯವಾಗಿ challenge ಅಥವಾ block	Unknown, ನಿಮ್ಮು route ಪ್ರಕಾರ ಆಯ್ಕೆಮಾಡುವ fallback ಜೊತೆಗೆ
ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಯಾರು ನಿರ್ಧರಿಸುತ್ತಾರೆ	ಎಡ್ಜ್ rule set	ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್
install ನಂತರದ ಪೂರ್ವನಿಯೋಜಿತ ವರ್ತನೆ	enforcement	observation; ನೀವು policy ಸೇರಿಸುವವರೆಗೂ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ
ಅತ್ಯುತ್ತಮವಾಗಿ ಏನಿಗೆ	ಕ್ರೆಡೆನ್ಷಿಯಲ್ ಸ್ಟಫಿಂಗ್, ಸ್ಕ್ರೇಪಿಂಗ್ ದುರುಪಯೋಗ ಮತ್ತು ವಾಲ್ಯೂಮೆಟ್ರಿಕ್ ದಾಳಿಗಳನ್ನು ನಿಲ್ಲಿಸಲು	ಪ್ರತಿಯೊಬ್ಬ actor ಗಾಗಿ ಉತ್ಪನ್ನ, analytics ಮತ್ತು policy ನಿರ್ಧಾರಗಳು

ಈ ಪುಟದ ಉಳಿದ ಭಾಗವು ಪ್ರತಿ ಸಾಲನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಎರಡು ಬೇರೆ ಪ್ರಶ್ನೆಗಳು

ಬಾಟ್ ನಿರ್ವಹಣೆ ಒಂದು ರಕ್ಷಣಾ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಅದರ ಗುರಿ ದುರುಪಯೋಗಕಾರಿ ಸ್ವಯಂಚಾಲನೆಯನ್ನು ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯ, ನಿಮ್ಮ ಖಾತೆಗಳು ಮತ್ತು ನಿಮ್ಮ inventory ಯಿಂದ ದೂರವಿಡುವುದಾಗಿದೆ. ಅದು ಸಂಗ್ರಹಿಸುವ ಪ್ರತಿಯೊಂದು signal ಕೂಡ ಆ ಗುರಿಗೆ ಸೇವೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅದರ output ಒಂದು ನಿರ್ಧಾರ: request ಅನ್ನು ಒಳಗೆ ಬಿಡುವುದು, ಅದನ್ನು block ಮಾಡುವುದು, ಅಥವಾ ಅದರ ಮುಂದೆ challenge ಇಡುವುದು.

Proof of Actor ಒಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು interaction ಅನ್ನು ಯಾರು ಅಥವಾ ಏನು ಚಾಲನೆ ಮಾಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಹೇಳುವುದು ಇದರ ಗುರಿ, ώστε ನೀವು ಅದನ್ನು ಹೇಗೆ ಸೇವಿಸಬೇಕು ಎಂದು ನಿರ್ಧರಿಸಬಹುದು. ಇದರ output request ಕುರಿತ ತೀರ್ಪು ಅಲ್ಲ. ಇದು ಸಾಕ್ಷ್ಯದೊಂದಿಗೆ ಇರುವ ವರ್ಗೀಕರಣ:

Human: ಕಾಣಬಹುದಾದ signals ಮಾನವ-ನಿರ್ದೇಶಿತ interaction ಅನ್ನು ಸೂಚಿಸುತ್ತವೆ.
Human + AI: ವ್ಯಕ್ತಿ AI ಸಹಾಯದೊಂದಿಗೆ interaction ಅನ್ನು ನಡೆಸಿದ್ದಾರೆ, ಅದು declared ಅಥವಾ observed ಆಗಿದೆ.
Agent: ಸ್ವಯಂಚಾಲಿತ ಅಥವಾ ಏಜೆಂಟ್-ಮೂಲದ interaction, ಪರಿಶೀಲಿಸಬಹುದಾದ identity ಅಥವಾ ಅರ್ಹ inference ಮೂಲಕ ಬೆಂಬಲಿತ.
Unknown: ಸಾಕ್ಷ್ಯವು ನಂಬಬಹುದಾದ ನಿರ್ಧಾರವನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ.

ಪ್ರತಿಯೊಂದು ಫಲಿತಾಂಶವು ಅದರ evidence basis ಅನ್ನು ಕೂಡ ಹೇಳುತ್ತದೆ: verified, declared, inferred ಅಥವಾ unknown. ಇದು ಉತ್ಪನ್ನ ನಿರ್ಧಾರಕ್ಕೆ ಬೇಕಾಗಿರುವ ಮಾಹಿತಿ, ಮತ್ತು ರಕ್ಷಣಾ score ಅನ್ನು ಅದಕ್ಕೆ ತಕ್ಕಂತೆ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿಲ್ಲ.

ಪ್ರತಿಯೊಂದು ಎಲ್ಲಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ

ಬಾಟ್ ನಿರ್ವಹಣೆ ಸಾಮಾನ್ಯವಾಗಿ network edge ಅಥವಾ reverse proxy ನಲ್ಲಿ, ಇತರ ಎಲ್ಲದರ ಮುನ್ನ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ರಕ್ಷಣೆಗೆ ಅದು ಸರಿಯಾದ ಸ್ಥಾನ. ಅದು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮೊದಲೇ ನೋಡುತ್ತದೆ, ದಾಳಿಗಳನ್ನು ಅವು ನಿಮಗೆ ವೆಚ್ಚ ತರಿಸುವ ಮೊದಲು ಶೋಷಿಸುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ origin servers ಅನ್ನು ಸ್ವಚ್ಛವಾಗಿಟ್ಟುಕೊಳ್ಳುತ್ತದೆ.

Proof of Actor ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಲಾಜಿಕ್ ಇರುವ ಸ್ಥಳದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ: server middleware, Next.js, ನೀವು ನಿಯಂತ್ರಿಸುವ edge layer, ಅನುಮೋದಿತ browser integration, generic HTTP API, ಅಥವಾ ನಿಮ್ಮ MCP server. ಆ ಸ್ಥಾನವು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ತಿಳಿದಿರುವ ವಿಷಯಗಳಿಗೆ ಪ್ರವೇಶ ಕೊಡುತ್ತದೆ: ಯಾವ route ಅನ್ನು ಕರೆಲಾಗುತ್ತಿದೆ, ಅದು ಯಾವ workflow ಗೆ ಸೇರಿದೆ, ನಿಮ್ಮದೇ assistant ಒಂದು action ನಿರ್ವಹಿಸಿದ್ದೇ, ಮತ್ತು client ತನ್ನನ್ನು ತಾನೇ ಘೋಷಿಸಿದ್ದೇ ಎಂಬುದು. ಪೂರ್ಣ ಪಟ್ಟಿಗೆ integration paths ನೋಡಿ.

ಎರಡೂ ಬೇರೆ ಬೇರೆ ಸ್ಥಳಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದರಿಂದ, ಅವು ಒಂದೇ ಕೆಲಸಕ್ಕಾಗಿ ಸ್ಪರ್ಧಿಸುವುದಿಲ್ಲ. ಒಂದು request ನಿಮ್ಮ ಬಾಟ್ ನಿರ್ವಹಣೆಯನ್ನು ದಾಟಿ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ತಲುಪಿ, ನಂತರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ರೂಪಿಸುವ actor ಸಂದರ್ಭವನ್ನು ಪಡೆಯಬಹುದು.

score ಗಳ ವಿರುದ್ಧ ಸಾಕ್ಷ್ಯ

ಅನೇಕ ರಕ್ಷಣಾ ಉತ್ಪನ್ನಗಳು ತಮ್ಮ ತೀರ್ಮಾನವನ್ನು score ರೂಪದಲ್ಲಿ ವ್ಯಕ್ತಪಡಿಸುತ್ತವೆ. block ನಿರ್ಧಾರಕ್ಕೆ score ಪರಿಣಾಮಕಾರಿ: ಒಂದು threshold ಆಯ್ಕೆಮಾಡಿ, ಅದರ ಮೇಲಿದ್ದರೆ ಕ್ರಮ ಕೈಗೊಳ್ಳಿ. ಆದರೆ ಪ್ರಶ್ನೆ "ಈ actor ಗೆ ಯಾವ experience ಕೊಡಬೇಕು?" ಆಗಿದ್ದರೆ ಅದು ತುಂಬಾ ಕಡಿಮೆ ಉಪಯುಕ್ತ.

ಒಂದು score ನಿಮಗೆ ಕಡಿಮೆ ಅಪಾಯದ request ವ್ಯಕ್ತಿಯಿಂದ ಬಂದಿದೆಯೇ, assistant ಜೊತೆ ಕೆಲಸ ಮಾಡುವ ವ್ಯಕ್ತಿಯಿಂದ ಬಂದಿದೆಯೇ, ಅಥವಾ ಉತ್ತಮ ನಡತೆ ಹೊಂದಿರುವ agent ನಿಂದ ಬಂದಿದೆಯೇ ಎಂದು ಹೇಳುವುದಿಲ್ಲ. ನಿರ್ಣಯದ ಯಾವ ಭಾಗ verified ಆಗಿತ್ತು ಮತ್ತು ಯಾವುದು inferred ಆಗಿತ್ತು ಎಂಬುದನ್ನು ಅದು ಹೇಳುವುದಿಲ್ಲ. ಮತ್ತು ಸಂಖ್ಯೆಗೆ ಬಲವಂತವಾಗಿ ತಳ್ಳದೆ "ನಮಗೆ ತಿಳಿದಿಲ್ಲ" ಎನ್ನುವುದನ್ನು ಅದು ವ್ಯಕ್ತಪಡಿಸಲಾರದು.

Proof of Actor ಆ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಕಾಯ್ದುಕೊಳ್ಳುತ್ತದೆ. verified agent ಫಲಿತಾಂಶ ಎಂದರೆ request signature ಅನ್ನು ಪ್ರಕಟಿತ key ವಿರುದ್ಧ ಪರಿಶೀಲಿಸಲಾಗಿದೆ, ಉದಾಹರಣೆಗೆ HTTP Message Signatures ಮೂಲಕ. declared ಫಲಿತಾಂಶ ಎಂದರೆ client ಅಥವಾ ನಿಮ್ಮದೇ ಅಪ್ಲಿಕೇಶನ್ ಅದನ್ನು ಹೇಳಿದೆ. inferred ಫಲಿತಾಂಶವನ್ನು inference ಎಂದು ಲೇಬಲ್ ಮಾಡಲಾಗಿದೆ. ಮತ್ತು Unknown ಅಡಗಿದ default ಬದಲು ಮೊದಲ ದರ್ಜೆಯ ಉತ್ತರವಾಗಿದೆ. ನಿಮ್ಮ ತಂಡ ಪ್ರತಿಯೊಂದು ಫಲಿತಾಂಶವನ್ನೂ ಓದಿ, ಅದು ಯಾವ ಆಧಾರದ ಮೇಲೆ ನಿಂತಿದೆ ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ನೋಡಬಹುದು.

AI ಸಹಾಯ ಪಡೆದ ಜನರು bot ಗಳು ಅಲ್ಲ

ಬಹುತೇಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ವೇಗವಾಗಿ ಬೆಳೆಯುತ್ತಿರುವ ಗುಂಪು AI ಜೊತೆ ಕೆಲಸ ಮಾಡುವ ಜನರು. ಅವರು assistant ನೆರವಿನಿಂದ ಸಂದೇಶಗಳನ್ನು ಬರೆಯುತ್ತಾರೆ, ಸಹಾಯದಿಂದ forms ತುಂಬುತ್ತಾರೆ, ಮತ್ತು AI ಸಾಧನವನ್ನು ತಮ್ಮ ಪಕ್ಕದಲ್ಲಿಟ್ಟುಕೊಂಡು ನಿಮ್ಮ ಉತ್ಪನ್ನದ ಮೂಲಕ ಸಾಗುತ್ತಾರೆ. ರಕ್ಷಣಾ tooling ಅವರನ್ನು ಇತರ ಜನರಿಂದ ಬೇರ್ಪಡಿಸಲು ನಿರ್ಮಿಸಲ್ಪಟ್ಟಿಲ್ಲ, ಮತ್ತು ಅದಕ್ಕೆ ಅವಶ್ಯಕತೆಯೂ ಇಲ್ಲ.

ನಿಮ್ಮ ಉತ್ಪನ್ನಕ್ಕೆ ಅದು ಬಹುಸಾ ಬೇಕಾಗುತ್ತದೆ. ನೀವು AI ಮೂಲಕ ಬರೆಯಲ್ಪಟ್ಟ support tickets ಅನ್ನು ಲೇಬಲ್ ಮಾಡಲು ಬಯಸಬಹುದು, AI ಸಹಾಯ ಪಡೆದ ಬಳಕೆದಾರರು onboarding ಮೂಲಕ ಹೇಗೆ ಚಲಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ಅಳೆಯಬಹುದು, ಅಥವಾ ಅವರಿಗೆ ಇನ್ನೂ ಸುಗಮವಾದ ಮಾರ್ಗವನ್ನು ನೀಡಬಹುದು. Proof of Actor ಆ ಗುಂಪಿಗೆ ತನ್ನದೇ ವರ್ಗವಾದ Human + AI ಅನ್ನು ನೀಡುತ್ತದೆ, ಮತ್ತು ಸಹಾಯ declared ಆಗಿದ್ದಾಗ ಅಥವಾ ಬೆಂಬಲಿತ integration ಮೂಲಕ ಗಮನಿಸಬಹುದಾದಾಗ ಮಾತ್ರ ಅದನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. AI-assisted interaction glossary entry ಯಲ್ಲಿ ಇನ್ನಷ್ಟು ಓದಿ.

Unknown ಒಂದು ಉತ್ತರ, ಬೆದರಿಕೆ ಅಲ್ಲ

ಪ್ರತಿ classifier ಕೂಡ ಅದು ವಿವರಿಸಲಾರುವ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಕಾಣುತ್ತದೆ. ರಕ್ಷಣಾ ವ್ಯವಸ್ಥೆಗಳು ಎಚ್ಚರಿಕೆಯಿಂದಿರಲು ನಿರ್ಮಿತವಾಗಿರುವುದರಿಂದ, ಅಸ್ಪಷ್ಟ ಟ್ರಾಫಿಕ್ ಬಹುಶಃ challenge ಅನ್ನು ಎದುರಿಸುತ್ತದೆ. ಇದು ಎಡ್ಜ್‌ನಲ್ಲಿ ಸಮಂಜಸವಾದ ಆಯ್ಕೆ.

ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಒಳಗೆ, ಒಂದೇ ಎಚ್ಚರಿಕೆಯ default ಬಹಳಷ್ಟು ಬಾರಿ ತಪ್ಪು ಆಯ್ಕೆ ಆಗುತ್ತದೆ. ಸಾರ್ವಜನಿಕ documentation page ಗೆ ಬಂದ unknown request ಮತ್ತು account password ಬದಲಿಸುವ unknown request ಗೆ ಬಹಳ ಬೇರೆ ನಿರ್ವಹಣೆ ಬೇಕು. Proof of Actor Unknown ಅನ್ನು ತನ್ನದೇ ಫಲಿತಾಂಶವಾಗಿ ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಮತ್ತು route ಪ್ರತಿ fallback ಅನ್ನು ನೀವು ಹೊಂದಿಸಲು ಬಿಡುತ್ತದೆ: public pages ನಲ್ಲಿ ಅದನ್ನು allow ಮಾಡಿ, account ಬದಲಾವಣೆಗಳಲ್ಲಿ ನಿಮ್ಮ ಈಗಿನ checks ಉಳಿಸಿಕೊಳ್ಳಿ, ಹೆಚ್ಚಿನ ಪರಿಣಾಮದ actions ನಲ್ಲಿ review ಗೆ route ಮಾಡಿ. handling Unknown traffic ಮಾರ್ಗದರ್ಶಿ pattern ಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಯಾರು ನಿರ್ಧರಿಸುತ್ತಾರೆ

ಬಾಟ್ ನಿರ್ವಹಣೆಯಲ್ಲಿ, ಎಡ್ಜ್‌ನಲ್ಲಿರುವ rule set ನಿರ್ಧರಿಸುತ್ತದೆ. ಇದು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ ಮತ್ತು ನಿಮ್ಮ properties ಅಡ್ಡಲಾಗಿ ನಿರ್ಧಾರಗಳನ್ನು ಒಂದೇ ರೀತಿಯಲ್ಲಿ ಇಡುತ್ತದೆ.

Proof of Actor ನಲ್ಲಿ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ಧರಿಸುತ್ತದೆ. ಉತ್ಪನ್ನವು actor ಸಂದರ್ಭವನ್ನು ಒದಗಿಸುತ್ತದೆ; ನಿಮ್ಮ ಕೋಡ್ policy ಅನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ. verified agent ಗಳಿಗೆ pages ಬದಲು structured API ಸೇವಿಸಬಹುದು, ಮಾನವ sessions ಗೆ ಮಾನಕ experience ಅನ್ನು ಉಳಿಸಬಹುದು, AI ಸಹಾಯ ಪಡೆದ submissions ಅನ್ನು ಲೇಬಲ್ ಮಾಡಬಹುದು, ಮತ್ತು ನಿಮ್ಮದೇ ಷರತ್ತುಗಳು ಅಗತ್ಯವಿದ್ದಾಗ ಸಂವೇದನಾಶೀಲ actions ಗೆ stronger credentials ಕೇಳಬಹುದು. Policies ಅನ್ನು ಪ್ರತಿ route, ಪ್ರತಿ actor ವರ್ಗ ಮತ್ತು ಪ್ರತಿ basis ಪ್ರಕಾರ ಬರೆಯಲಾಗುತ್ತದೆ, ಮತ್ತು ಅವು ನಿಮ್ಮ ಇತರೆ business logic ನ ಪಕ್ಕದಲ್ಲೇ ಇರುತ್ತವೆ.

ಮೊದಲು observation

ಬಾಟ್ ನಿರ್ವಹಣೆ ಸಾಮಾನ್ಯವಾಗಿ enforce ಮಾಡಲು install ಮಾಡಲಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಅದರ ಸಂಪೂರ್ಣ ಮೌಲ್ಯವೇ ದುರುಪಯೋಗವನ್ನು ನಿಲ್ಲಿಸುವುದು.

Proof of Actor observation mode ನಲ್ಲಿ ಆರಂಭವಾಗುತ್ತದೆ. ಅದನ್ನು install ಮಾಡುವುದರಿಂದ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದರಲ್ಲಿ ಏನೂ ಬದಲಾವಣೆಯಾಗುವುದಿಲ್ಲ. route ಪ್ರಕಾರ ನಿಮ್ಮ ನೈಜ actor mix ಅನ್ನು ನೀವು ನೋಡುತ್ತೀರಿ, ಸಾಕ್ಷ್ಯವನ್ನು ಪರಿಶೀಲಿಸುತ್ತೀರಿ, ನಿಜವಾದ ಟ್ರಾಫಿಕ್ ವಿರುದ್ಧ policy ಯ ಪರಿಣಾಮವನ್ನು preview ಮಾಡುತ್ತೀರಿ, ಮತ್ತು ನೀವು ಸಿದ್ಧರಾದಾಗ ಮಾತ್ರ, ಒಂದೊಂದು route ಆಗಿ enforce ಮಾಡುತ್ತೀರಿ. rolling out actor-aware policies safely ಮಾರ್ಗದರ್ಶಿ ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಎರಡೂ ಹೇಗೆ ಒಟ್ಟಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ

ಅತ್ಯಂತ ಬಲವಾದ setup ಎರಡನ್ನೂ ಬಳಸುತ್ತದೆ, ತಲಾ ತನ್ನದೇ layer ನಲ್ಲಿ:

ಎಡ್ಜ್‌ನಲ್ಲಿ, ಬಾಟ್ ನಿರ್ವಹಣೆ ಕ್ರೆಡೆನ್ಷಿಯಲ್ ಸ್ಟಫಿಂಗ್, ಸ್ಕ್ರೇಪಿಂಗ್ ದುರುಪಯೋಗ ಮತ್ತು ವಾಲ್ಯೂಮೆಟ್ರಿಕ್ ದಾಳಿಗಳನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.
ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ, Proof of Actor ದಾಟಿ ಬಂದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಅದರ basis ಜೊತೆಗೆ Human, Human + AI, Agent ಅಥವಾ Unknown ಎಂದು ವರ್ಗೀಕರಿಸುತ್ತದೆ.
ನಿಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿ, policies ಆ ಸಂದರ್ಭವನ್ನು ಬಳಸಿ experience ಆಯ್ಕೆಮಾಡುತ್ತವೆ: verified agent ಗಾಗಿ structured API, ವ್ಯಕ್ತಿಗೆ ಸಾಮಾನ್ಯ flow, AI ಸಹಾಯ ಪಡೆದ submission ಗೆ ಒಂದು label, Unknown ಗಾಗಿ ಸ್ಪಷ್ಟ fallback.
ನಿಮ್ಮ analytics‌ನಲ್ಲಿ, ಯಾವ actor ವರ್ಗ ಯಾವ routes ಮತ್ತು workflows ಅನ್ನು ಬಳಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಮ್ಮ ತಂಡ ನೋಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಉತ್ಪನ್ನ ಮತ್ತು security ಒಂದೇ ಚಿತ್ರದಿಂದ ಕೆಲಸ ಮಾಡುತ್ತವೆ.

edge ನಿರ್ಧಾರವನ್ನು actor ಫಲಿತಾಂಶದ ಪಕ್ಕದಲ್ಲಿ ದಾಖಲಿಸುವುದು ಚಿತ್ರವನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ: ರಕ್ಷಣೆ ಏನು ಮಾಡಿತು, ಮತ್ತು ನಿಜವಾಗಿ ಯಾರು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರು ಎಂಬುದು.

ಯಾವಾಗ ಯಾವುದನ್ನು ಆಯ್ಕೆಮಾಡಬೇಕು

ನಿಮ್ಮ ಮುಖ್ಯ ಸಮಸ್ಯೆ ದುರುಪಯೋಗವಾಗಿದ್ದರೆ ಬಾಟ್ ನಿರ್ವಹಣೆ ಆಯ್ಕೆಮಾಡಿ: account takeover ಪ್ರಯತ್ನಗಳು, inventory hoarding, aggressive scraping ಅಥವಾ traffic floods.

ನಿಮ್ಮ ಮುಖ್ಯ ಪ್ರಶ್ನೆ ನಿಮ್ಮ ಬಳಕೆದಾರರ ಕುರಿತು ಆಗಿದ್ದರೆ Proof of Actor ಆಯ್ಕೆಮಾಡಿ: ಎಷ್ಟು ಭಾಗದ ಉತ್ಪನ್ನವನ್ನು ಏಜೆಂಟ್‌ಗಳು ಈಗಾಗಲೇ ಬಳಸುತ್ತಿದ್ದಾರೆ, ಯಾವ ಏಜೆಂಟ್‌ಗಳು ನಿಮ್ಮ API ಅಥವಾ MCP server ಅನ್ನು ಕರೆ ಮಾಡುತ್ತಿದ್ದಾರೆ, AI ಸಹಾಯ ಪಡೆದ ಜನರು ಎಲ್ಲಲ್ಲಿ struggle ಮಾಡುತ್ತಾರೆ, ಮತ್ತು ಯಾವ routes ಗೆ actor-aware policy ಬೇಕು.

production ಅಪ್ಲಿಕೇಶನ್, API ಅಥವಾ MCP server ಅನ್ನು ನಡೆಸುವ ಬಹುತೇಕ ತಂಡಗಳಿಗೆ ಎರಡೂ ಪ್ರಶ್ನೆಗಳಿಗೂ ಉತ್ತರ ಬೇಕಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಈ ಎರಡು ಒಂದೇ stack ನಲ್ಲಿ ಇರಬೇಕು.

ಪ್ರಾರಂಭಿಸಿ

Proof of Actor ಖಾಸಗಿ beta ಯಲ್ಲಿ ಇದೆ. ಆಯ್ಕೆಮಾಡಲಾದ founding developer ತಂಡಗಳಿಗೆ ಒಪ್ಪಂದಿತ ಬಳಕೆ ಮಿತಿಗಳ ಒಳಗೆ 12 ತಿಂಗಳುಗಳವರೆಗೆ ಉಚಿತ ಪ್ರವೇಶ ದೊರೆಯಬಹುದು, ಅದನ್ನು ನಿರ್ಮಿಸುವ ತಂಡದಿಂದ ನೇರ support ಸಹಿತ. early access ಗೆ ಅರ್ಜಿ ಸಲ್ಲಿಸಿ ಮತ್ತು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಬಯಸುವ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು interaction ಕುರಿತು ನಮಗೆ ತಿಳಿಸಿ.

DEVELOPERS ಗಾಗಿ

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: ಫಲಿತಾಂಶದ ಹಿಂದೆ ಇರುವ signals, ಇದರಿಂದ ನಿಮ್ಮ ತಂಡಕ್ಕೆ ಕಾರಣ ಕಾಣುತ್ತದೆ.

observation mode ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿ: ನಿಮ್ಮ logs ಗಳ ಪಕ್ಕದಲ್ಲಿ ಫಲಿತಾಂಶಗಳನ್ನು ದಾಖಲಿಸಿ ಮತ್ತು ನೀವು ಒಂದು policy ಆಯ್ಕೆ ಮಾಡುವವರೆಗೆ ಏನನ್ನೂ ಬದಲಾಯಿಸಬೇಡಿ. Node.js ಏಕೀಕರಣ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಓದಿ

ಪದೇಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

Proof of Actor ಬಾಟ್ ನಿರ್ವಹಣೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆಯೇ?

ಇಲ್ಲ. ಬಾಟ್ ನಿರ್ವಹಣೆ ಕ್ರೆಡೆನ್ಷಿಯಲ್ ಸ್ಟಫಿಂಗ್, ಸ್ಕ್ರೇಪಿಂಗ್ ದುರುಪಯೋಗ ಮತ್ತು ವಾಲ್ಯೂಮೆಟ್ರಿಕ್ ದಾಳಿಗಳಂತಹ ದುರುಪಯೋಗಕಾರಿ ಸ್ವಯಂಚಾಲನೆಯನ್ನು ಅದು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ತಲುಪುವುದಕ್ಕೂ ಮುನ್ನ ನಿಲ್ಲಿಸುತ್ತದೆ. Proof of Actor ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನೊಳಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಉತ್ಪನ್ನ ಹಾಗೂ ನೀತಿ ನಿರ್ಧಾರಗಳಿಗೆ actor ಸಂದರ್ಭವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಎರಡನ್ನೂ ಇರಿಸಿಕೊಳ್ಳಿ.

ಉತ್ಪನ್ನ ನಿರ್ಧಾರಗಳಿಗೆ bot score ಬಳಸುವುದೇಕೆ ಬೇಡ?

bot score ಅನ್ನು ಒಂದು ವಿನಂತಿಯನ್ನು ನಿಲ್ಲಿಸಬೇಕೇ ಎಂಬುದಕ್ಕೆ ಉತ್ತರಿಸಲು ನಿರ್ಮಿಸಲಾಗಿದೆ. ಅದು ಸಾಮಾನ್ಯವಾಗಿ ವ್ಯಕ್ತಿ AI ಜೊತೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆಯೇ, ಯಾವ ಏಜೆಂಟ್ ಕರೆ ಮಾಡುತ್ತಿದೆ, ಅಥವಾ ಆ score ಯಾವ ಸಾಕ್ಷ್ಯದ ಮೇಲೆ ನಿಂತಿದೆ ಎಂಬುದನ್ನು ಹೇಳುವುದಿಲ್ಲ. Proof of Actor ಒಂದು ವರ್ಗ ಮತ್ತು ಸ್ಪಷ್ಟ basis ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಅದೇ ಉತ್ಪನ್ನ ನಿರ್ಧಾರಗಳಿಗೆ ಅಗತ್ಯವಾಗಿರುವುದು.

ಈ ಎರಡೂ signals ಅನ್ನು ಹಂಚಿಕೊಳ್ಳಬಹುದೇ?

ಹೌದು. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ edge controls ಫಲಿತಾಂಶವನ್ನು Proof of Actor ಫಲಿತಾಂಶದ ಜೊತೆಗೆ ದಾಖಲಿಸಬಹುದು, ಆದ್ದರಿಂದ ನಿಮ್ಮ ತಂಡ ಒಂದೇ ವಿನಂತಿಗೆ ರಕ್ಷಣಾ ನಿರ್ಧಾರ ಮತ್ತು actor ಸಂದರ್ಭ ಎರಡನ್ನೂ ನೋಡುತ್ತದೆ.

Proof of Actor ಟ್ರಾಫಿಕ್ ಅನ್ನು ಬ್ಲಾಕ್ ಮಾಡುತ್ತದೆಯೇ?

ಇಲ್ಲ. ಇದು observation ಮೋಡ್‌ನಲ್ಲಿ ಆರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ನೀವು ಒಂದು policy ಬರೆಯುವವರೆಗೂ ಏನನ್ನೂ ಬದಲಾಯಿಸುವುದಿಲ್ಲ. enforcement ಸದಾ ನಿಮ್ಮದೇ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್‌ನಲ್ಲೇ ಇರುತ್ತದೆ.

ನಾನು ಮೊದಲು ಯಾವುದನ್ನು ಸೇರಿಸಬೇಕು?

ನೀವು ಸಕ್ರಿಯ ದುರುಪಯೋಗವನ್ನು ಎದುರಿಸುತ್ತಿದ್ದರೆ, ಮೊದಲು ಬಾಟ್ ನಿರ್ವಹಣೆಯಿಂದ ಆರಂಭಿಸಿ. ನಿಮ್ಮ ಉತ್ಪನ್ನವನ್ನು ಈಗಾಗಲೇ ಬಳಸುತ್ತಿರುವ ಜನರು, AI ಸಹಾಯ ಪಡೆದ ಬಳಕೆದಾರರು ಮತ್ತು ಏಜೆಂಟ್‌ಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಅವರಿಗೆ ಸೇವೆ ನೀಡಲು ಬಯಸಿದರೆ, Proof of Actor ಸೇರಿಸಿ. ಬಹುತೇಕ production ತಂಡಗಳು ಕೊನೆಗೆ ಎರಡನ್ನೂ ಬಳಸುತ್ತವೆ.

ನಿಮ್ಮ app ಅನ್ನು ಯಾರು ಬಳಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ತಿಳಿಯಿರಿ.

founding developers ನ ಸಣ್ಣ ಗುಂಪಿಗಾಗಿ private beta.

ಮುಂಗಡ ಪ್ರವೇಶ ಪಡೆಯಿರಿ ಮೌಲ್ಯವನ್ನು ವೀಕ್ಷಿಸಿ

ಮೊದಲು ಮಾತನಾಡಲು ಇಷ್ಟವಿದೆಯೆ? ಸ್ಥಾಪಕರೊಂದಿಗೆ ಮಾತನಾಡಿ