ಪರಿಶೀಲಿತ ಸ್ವಯಂಚಾಲನೆ

ಪರಿಶೀಲಿತ ಸ್ವಯಂಚಾಲಿತ ವಿನಂತಿಗಳನ್ನು ಗುರುತಿಸಿ

ಸ್ವಯಂಚಾಲಿತ ಕ್ಲೈಂಟ್ ತನ್ನ ವಿನಂತಿಗಳಿಗೆ ಸಹಿ ಹಾಕಿದಾಗ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಆ ಸಹಿಯನ್ನು ಪರಿಶೀಲಿಸಿ ಕರೆ ಮಾಡಿದವರನ್ನು ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ನಿರ್ವಹಿಸಬಹುದು. Proof of Actor ಆ ಪರಿಶೀಲನೆಯನ್ನು ಸ್ಪಷ್ಟ, ಮಾರ್ಗಗೊಳಿಸಬಹುದಾದ ಫಲಿತಾಂಶವಾಗಿ ರೂಪಿಸುತ್ತದೆ.

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

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

ಎಲ್ಲಾ ಸ್ವಯಂಚಾಲಿತ ಟ್ರಾಫಿಕ್ ಒಂದೇ ತರಹದದ್ದಲ್ಲ

ಸ್ವಯಂಚಾಲಿತ ಕ್ಲೈಂಟ್‌ಗಳು ಪ್ರತಿಮಿನಿಟಿಗೂ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಬರುತ್ತವೆ: ಹುಡುಕಾಟ ಕ್ರಾಲರ್‌ಗಳು, ಮಾನಿಟರಿಂಗ್ ಸಾಧನಗಳು, ಬಳಕೆದಾರರಿಗಾಗಿ ಪುಟಗಳನ್ನು ತರಿಸುವ ಪಾಲುದಾರ ಇಂಟಿಗ್ರೇಶನ್‌ಗಳು, AI ಸಹಾಯಕರು, ಮತ್ತು ಕಾರ್ಯಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸುವ ಸ್ವಾಯತ್ತ ಏಜೆಂಟ್‌ಗಳು. ವರ್ಷಗಳ ಕಾಲ, ಹೆಚ್ಚಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಅವುಗಳನ್ನು ಬೇರ್ಪಡಿಸಲು ಬಳಸಬಹುದಾದ ಏಕೈಕ ವಿಧಾನ ಎಂದರೆ user-agent header, ಅದು ಯಾವುದೇ ಕ್ಲೈಂಟ್‌ಗೂ ಯಾವುದೇ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿಸಬಹುದಾದ string ಆಗಿತ್ತು.

ಇದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ತಂಡಗಳು ಕಷ್ಟಕರ ಸ್ಥಿತಿಯಲ್ಲಿ ಸಿಲುಕುತ್ತವೆ. ಎಲ್ಲಾ automation ಅನ್ನು ಅನುಮಾನದಿಂದ ನೋಡಿದರೆ, ನಿಮ್ಮ ಗ್ರಾಹಕರು ಅವಲಂಬಿಸಿರುವ ನಿಜವಾದ ಏಜೆಂಟ್‌ಗಳ ಅನುಭವ ಹದಗೆಡುತ್ತದೆ. header ಮೇಲೆ ನಂಬಿಕೆ ಇಟ್ಟರೆ, ಯಾರು ಬೇಕಾದರೂ ತಾವು ಪ್ರಸಿದ್ಧ ಕ್ರಾಲರ್ ಎಂದು ಹೇಳಿಕೊಳ್ಳಬಹುದು.

ಪರಿಶೀಲಿತ ಸ್ವಯಂಚಾಲಿತ ವಿನಂತಿಗಳು ಈ ಸಮೀಕರಣವನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ. ಸ್ವಯಂಚಾಲಿತ ಕ್ಲೈಂಟ್ ತನ್ನ ಪ್ರಕಟಿತ ಕೀಲಿಯೊಂದಿಗೆ ತನ್ನ ವಿನಂತಿಗಳಿಗೆ ಸಹಿ ಹಾಕಿದಾಗ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಸಹಿಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ರೀತಿಯಲ್ಲಿ, ಯಾವ ಕ್ಲೈಂಟ್ ವಿನಂತಿಗೆ ಸಹಿ ಹಾಕಿತು ಎಂಬುದನ್ನು ತಿಳಿಯಬಹುದು. Proof of Actor ಆ ಪರಿಶೀಲನೆಯನ್ನು ನಿಮ್ಮ ಕೋಡ್ ಮಾರ್ಗಗೊಳಿಸಬಹುದಾದ ಒಂದೇ, ಸಮ್ಮತ actor result‌ನ ಭಾಗವಾಗಿಸುತ್ತದೆ. ಆ ಪರಿಶೀಲನೆ ಏನು ಸ್ಥಾಪಿಸುತ್ತದೆ ಮತ್ತು ಏನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಹತ್ತಿರದಿಂದ ತಿಳಿಯಲು signed AI agent requests ಏನು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಓದಿ.

ವಿನಂತಿ ಸಹಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ

ಸ್ವಯಂಚಾಲಿತ ಟ್ರಾಫಿಕ್‌ಗಾಗಿ ಹೊರಹೊಮ್ಮುತ್ತಿರುವ ವಿಧಾನ HTTP message signatures ಅನ್ನು ಬಳಸುತ್ತದೆ, ಇದನ್ನು RFC 9421 ನಲ್ಲಿ ಪ್ರಮಾಣೀಕರಿಸಲಾಗಿದೆ. ಇದು HTTP ಸಂದೇಶದ ಘಟಕಗಳ ಮೇಲೆ ಸಹಿಗಳನ್ನು ಹೇಗೆ ರಚಿಸಬೇಕು, ಎನ್‌ಕೋಡ್ ಮಾಡಬೇಕು ಮತ್ತು ಪರಿಶೀಲಿಸಬೇಕು ಎಂದು ವಿವರಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಪ್ರತಿ ವಿನಂತಿಯ ಆಯ್ದ ಭಾಗಗಳಿಗೆ ಖಾಸಗಿ ಕೀಲಿಯೊಂದಿಗೆ ಸಹಿ ಹಾಕಿ, ಸಹಿ ಮತ್ತು ಅದರ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು header‌ಗಳಲ್ಲಿ ಸೇರಿಸುತ್ತದೆ. ಅದು ಸಂಬಂಧಿತ ಸಾರ್ವಜನಿಕ ಕೀಲಿಯನ್ನು ಅದು ನಿಯಂತ್ರಿಸುವ ಗುರುತಿಗೆ ಜೋಡಿಸಲಾದ ಸ್ಥಳದಲ್ಲಿ, ಸಾಮಾನ್ಯವಾಗಿ ತನ್ನ ಡೊಮೇನ್‌ನಲ್ಲಿ, ಪ್ರಕಟಿಸುತ್ತದೆ.

ವಿನಂತಿ ಬಂದಾಗ, ಸ್ವೀಕರಿಸುವವರು ಪ್ರಕಟಿತ ಕೀಲಿಯನ್ನು ಪಡೆದು ಅಥವಾ ಹುಡುಕಿ, ಸಹಿ ಹಾಕಿದ ವಿಷಯವನ್ನು ಮರುರಚಿಸಿ, ಮತ್ತು ಸಹಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತಾರೆ. ಅದು ಮಾನ್ಯವಾದರೆ, ವಿನಂತಿಗೆ ಆ ಕೀಲಿಯ ಮಾಲೀಕನೇ ಸಹಿ ಹಾಕಿದ್ದಾನೆ. ಸ್ವಯಂಚಾಲಿತ ಟ್ರಾಫಿಕ್‌ಗೆ ಸಹಿ ಹಾಕುವ ಕೆಲಸ IETF Web Bot Auth working group ನಲ್ಲಿ ಮುಂದುವರಿದಿದೆ, ಇದರ charter ಕ್ರಾಲರ್‌ಗಳು ಮತ್ತು ಅಂತಿಮ ಬಳಕೆದಾರರ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ AI ಏಜೆಂಟ್‌ಗಳಂತಹ ಸ್ವಯಂಚಾಲಿತ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ರೀತಿಯಲ್ಲಿ ಪ್ರಮಾಣೀಕರಿಸುವುದನ್ನು ಒಳಗೊಂಡಿದೆ; Web Bot Auth glossary entry ಇದನ್ನು ಸಾರಾಂಶಗೊಳಿಸುತ್ತದೆ. signed AI agent requests ಏನು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ ಎಂಬ blog post ಪರಿಶೀಲಿತ ವಿನಂತಿಯನ್ನು ಅಂತ್ಯದಿಂದ ಅಂತ್ಯದವರೆಗೆ ತೋರಿಸುತ್ತದೆ, ಮತ್ತು APIs use case ಪರಿಶೀಲನೆ ಮೊದಲಿಗೆ ಎಲ್ಲಿ ಮೌಲ್ಯ ನೀಡುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.

signed agent requests ಅನ್ನು ಪರಿಶೀಲಿಸುವ guide ಸಮಯಮುದ್ರೆ, replay windowಗಳು ಮತ್ತು key caching ಸೇರಿದಂತೆ ಯಾಂತ್ರಿಕ ವಿವರಗಳನ್ನು ಆಳವಾಗಿ ವಿವರಿಸುತ್ತದೆ.

ಪರಿಶೀಲಿತ ಸಹಿ ಏನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಏನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ

ಪರಿಶೀಲಿತ ಸ್ವಯಂಚಾಲಿತ ವಿನಂತಿಗಳನ್ನು ಸರಿಯಾಗಿ ನಿರ್ವಹಿಸುವಲ್ಲಿ ಈ ಭೇದವೇ ಅತ್ಯಂತ ಮುಖ್ಯ ಭಾಗ.

ಮಾನ್ಯ ಸಹಿ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ: ವಿನಂತಿಗೆ ಪ್ರಕಟಿತ ಗುರುತಿಗೆ ಸಂಬಂಧಿಸಿದ ಕೀಲಿಯೊಂದಿಗೆ ಸಹಿ ಹಾಕಲಾಗಿದೆ. ಆ ಕೀ ನಿರ್ವಾಹಕರ ಡೊಮೇನ್‌ಗೆ ಸೇರಿದ್ದರೆ, ವಿನಂತಿ ಆ ನಿರ್ವಾಹಕರ ಕೀಲಿಯನ್ನು ಹಿಡಿದಿರುವ ಕ್ಲೈಂಟ್‌ನಿಂದ ಬಂದಿದೆ.

ಮಾನ್ಯ ಸಹಿ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ:

ಏಜೆಂಟ್‌ಗೆ ಯಾರು ಸೂಚನೆ ನೀಡಿದರು, ಅಥವಾ ಯಾವುದೇ ವ್ಯಕ್ತಿ ಈ ಕ್ರಮವನ್ನು ಕೇಳಿದ್ದಾರೆಯೇ ಎಂಬುದು;
ವ್ಯಕ್ತಿಯೊಬ್ಬರು ಏಜೆಂಟ್‌ಗೆ ಅಧಿಕಾರವನ್ನು ನಿಯೋಜಿಸಿದ್ದಾರೆಯೇ ಎಂಬುದು;
ನಿರ್ವಾಹಕರ ಹಿಂದೆ ಇರುವ ನೈಜ ಜಗತ್ತಿನ ಕಾನೂನು ಗುರುತು;
ವಿನಂತಿಸಿದ ಕ್ರಮವು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಸುರಕ್ಷಿತ ಅಥವಾ ಅನುಮತಿತವೇ ಎಂಬುದು.

ಅವು ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆಗಳು. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅವುಗಳಿಗೆ ತನ್ನದೇ credentials, authorization model ಮತ್ತು policy ಮೂಲಕ ಉತ್ತರಿಸುತ್ತದೆ. Proof of Actor ಅವುಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಬೇರ್ಪಡಿಸಿ ಇಡುತ್ತದೆ, ಮತ್ತು Detection & Limitations ಪುಟವು ಯಾವ ರೀತಿಯ ಸಾಕ್ಷ್ಯವು ಏನು ಸ್ಥಾಪಿಸಬಹುದು ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ವಿವರಿಸುತ್ತದೆ.

ಪರಿಶೀಲಿತ ಸ್ವಯಂಚಾಲಿತ ವಿನಂತಿಗಳನ್ನು Proof of Actor ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ

Detect

ನಿಮ್ಮ ಇಂಟಿಗ್ರೇಶನ್ ಯಾವುದೇ signature headerಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ವಿನಂತಿಯ context ಅನ್ನು Proof of Actor‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಸಹಿಗಳನ್ನು ಪ್ರಕಟಿತ ಕೀಲಿಗಳ ವಿರುದ್ಧ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ. ಮಾನ್ಯವಾಗುವ ವಿನಂತಿಗಳನ್ನು ಪರಿಶೀಲಿತ ಆಧಾರದೊಂದಿಗೆ ದಾಖಲಿಸಲಾಗುತ್ತದೆ. ತಮ್ಮನ್ನು ಮಾತ್ರ ಹೆಸರಿಸುವ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಘೋಷಿತ ಎಂದು ದಾಖಲಿಸಲಾಗುತ್ತದೆ. ವರ್ತನಾ ಮಾದರಿಗಳನ್ನು ನಿರ್ಗಮಿತ ಎಂದು ದಾಖಲಿಸಲಾಗುತ್ತದೆ. ಸಾಕ್ಷ್ಯ ಸಾಲದಿದ್ದರೆ, ಫಲಿತಾಂಶ Unknown ಆಗಿರುತ್ತದೆ. ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಪರಿಶೀಲನೆ ಯಶಸ್ವಿಯಾಗದಿದ್ದರೆ ಯಾವುದನ್ನೂ ಪರಿಶೀಲಿತ ಎಂದು ಉತ್ತೀರ್ಣಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ.

Understand

ಯಾವ ಪರಿಶೀಲಿತ ನಿರ್ವಾಹಕರು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಕರೆ ಮಾಡುತ್ತಾರೆ, ಅವರು ಯಾವ route‌ಗಳನ್ನು ಬಳಸುತ್ತಾರೆ, ಎಷ್ಟು ಬಾರಿ ಬಳಸುತ್ತಾರೆ, ಮತ್ತು ಅದು ಘೋಷಿತ ಮತ್ತು Unknown automation ಜೊತೆ ಹೇಗೆ ಹೋಲುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಿ. ಪ್ರತಿಯೊಂದು ಫಲಿತಾಂಶದ evidence summary ಯಾವ key ಮತ್ತು ಗುರುತು ಒಳಗೊಂಡಿತ್ತು ಎಂಬುದನ್ನು ತಿಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ತಂಡ ಯಾವುದೇ ವಿನಂತಿಯನ್ನು ಶೀಘ್ರವಾಗಿ ಪರಿಶೀಲಿಸಬಹುದು.

Route

ನಿಮ್ಮ policyಗಳಲ್ಲಿ ಆಧಾರವನ್ನು ಬಳಸಿ. ಸಾಮಾನ್ಯ ಮಾದರಿಗಳು ಇವು:

ಪರಿಶೀಲಿತ ಏಜೆಂಟ್‌ಗಳಿಗೆ ಓದಲು ಮಾತ್ರ ಇರುವ route‌ಗಳಲ್ಲಿ, ಉದಾಹರಣೆಗೆ API ಅಥವಾ ಪುಟದ Markdown ಆವೃತ್ತಿಯಲ್ಲಿ, ರಚಿತ ಪ್ರತಿಕ್ರಿಯೆ ನೀಡಿ.
ನೀವು ಗುರುತಿಸುವ ಪರಿಶೀಲಿತ ನಿರ್ವಾಹಕರಿಗೆ rate limits ಹೆಚ್ಚಿಸಿ, ಆದರೆ ಘೋಷಿತ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಮಾನಕ ಮಿತಿಗಳನ್ನು ಉಳಿಸಿ.
ಸಹಿ ಏನೇ ಹೇಳಿದರೂ, ಪ್ರತಿಯೊಂದು write route‌ನಲ್ಲೂ ನಿಮ್ಮ ಇತ್ತೀಚಿನ authorization ಅನ್ನು ಉಳಿಸಿ.
ಪ್ರತಿ route‌ನಲ್ಲೂ unsigned ಮತ್ತು Unknown ಕರೆಕರ್ತರಿಗೆ ಸ್ಪಷ್ಟ fallback ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿ.

ನಿಮ್ಮ policyಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ; Proof of Actor ಸಾಕ್ಷ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ.

user-agent header ಏಕೆ ಸಾಕಾಗುವುದಿಲ್ಲ

user-agent stringಗಳು ಘೋಷಣೆಗಳು. ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಯಾವುದೇ ಮೌಲ್ಯವನ್ನು ಕಳುಹಿಸಬಹುದು, ಮತ್ತು user-agent spoofing ಗೆ ಯಾವುದೇ ವಿಶೇಷ ಕೌಶಲ್ಯ ಬೇಕಾಗುವುದಿಲ್ಲ. ಅದಕ್ಕಾಗಿಯೇ ಕ್ರಾಲರ್ ನಿರ್ವಾಹಕರು ತಮ್ಮದೇ ಪರಿಶೀಲನೆಗಳನ್ನು ಪ್ರಕಟಿಸುತ್ತಾರೆ: Google Verifying Googlebotಗಾಗಿ reverse ಮತ್ತು forward DNS lookupಗಳು ಮತ್ತು ಪ್ರಕಟಿತ IP rangeಗಳನ್ನು ದಾಖಲಿಸಿದೆ, Bing Verifying Bingbotಗಾಗಿ DNS ಪರಿಶೀಲನೆಯನ್ನು ದಾಖಲಿಸಿದೆ, ಮತ್ತು OpenAI ತನ್ನ crawlers and user agentsಗೆ IP range fileಗಳನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆ. Proof of Actor user-agent claim ಅನ್ನು ಘೋಷಿತ ಸಾಕ್ಷ್ಯವಾಗಿ ಕಾಣುತ್ತದೆ, ಪರಿಶೀಲನೆಯಾಗಿ ಎಂದಿಗೂ ಅಲ್ಲ. ಇದರರ್ಥ, ಮಾನ್ಯ ಸಹಿಯಿಲ್ಲದೆ ಪ್ರಸಿದ್ಧ ಕ್ರಾಲರ್ ಎಂದು ಹೇಳಿಕೊಳ್ಳುವ ಕ್ಲೈಂಟ್ ಅನ್ನು ಘೋಷಿತ ಅಥವಾ ನಿರ್ಗಮಿತ ಆಧಾರದೊಂದಿಗೆ ವರದಿಮಾಡಲಾಗುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ policy ಅದನ್ನು ತನ್ನ ಗುರುತನ್ನು ಸಾಬೀತುಪಡಿಸಿದ ಕ್ಲೈಂಟ್‌ನಿಂದ ವಿಭಿನ್ನವಾಗಿ ನಿರ್ವಹಿಸಬಹುದು.

ಇದೇ ಪರಿಶೀಲಿತ ಸ್ವಯಂಚಾಲಿತ ವಿನಂತಿಗಳನ್ನು ಮೌಲ್ಯಯುತವಾಗಿಸುವುದು: ತನ್ನ header ಅನ್ನು ನಕಲು ಮಾಡುವ ಎಲ್ಲರಿಗೂ trust ಅನ್ನು ವಿಸ್ತರಿಸದೇ, ಅದನ್ನು ಗಳಿಸಿದ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ trust ವಿಸ್ತರಿಸಲು ಇದು ವಿಶ್ವಾಸಾರ್ಹ ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತದೆ.

ಗುರುತು ಸಾಕ್ಷ್ಯ, credentials ಮತ್ತು authorization

ಸ್ವಯಂಚಾಲಿತ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸೇವೆ ನೀಡುವ ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಮೂರು ಪದರಗಳು ಒಟ್ಟಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ:

ಗುರುತು ಸಾಕ್ಷ್ಯ: ಈ ವಿನಂತಿಗೆ ಯಾವ ಕ್ಲೈಂಟ್ ಸಹಿ ಹಾಕಿತು? ಪರಿಶೀಲಿತ ಸಹಿ ಇದಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ.
Credentials: ಯಾವ account ಹೊಣೆಗಾರವಾಗಿದೆ? ನಿಮ್ಮ API key, token ಅಥವಾ session ಇದಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ.
Authorization: ಈ ಕರೆಕರ್ತನು ಇದನ್ನು ಮಾಡಬಹುದೇ? ನಿಮ್ಮ permission model ಇದಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ.

Proof of Actor ಮೊದಲ ಪದರವನ್ನು ಬಲಪಡಿಸಿ ಅದನ್ನು ಕಾಣುವಂತೆ ಮಾಡುತ್ತದೆ. ಇದು ಗುರುತು ಅಥವಾ delegation credentials ಅನ್ನು ನೀಡುವುದಿಲ್ಲ, ಮತ್ತು ನಿಮ್ಮ authorization ಅನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಪದರಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡುವುದೇ ಕಡಿಮೆ ಅಪಾಯದ route‌ಗಳಲ್ಲಿ ಪರಿಶೀಲಿತ ಏಜೆಂಟ್‌ಗಳಿಗೆ ಉದಾರವಾಗಿರಲು ಮತ್ತು ಹೆಚ್ಚಿನ ಪ್ರಭಾವ ಇರುವವುಗಳಲ್ಲಿ ಎಚ್ಚರಿಕೆಯಿಂದ ಇರಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.

ಇದು ಎಲ್ಲಿ ಹೊಂದುತ್ತದೆ

Proof of Actor ನಿಮ್ಮ gateway, authentication ಮತ್ತು rate limiting ಜೊತೆಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇಂಟಿಗ್ರೇಶನ್‌ಗಳು server-side middleware ಆಗಿ, edge‌ನಲ್ಲಿ, ನಿಮ್ಮ MCP server‌ನಲ್ಲಿ ಅಥವಾ ಸಾಮಾನ್ಯ HTTP integration ಮೂಲಕ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಪ್ರತಿಯೊಂದು founding ತಂಡದೊಂದಿಗೆ ಕೈಹಿಡಿದ ಮಾರ್ಗದರ್ಶನದೊಂದಿಗೆ ಒದಗಿಸಲಾಗುತ್ತದೆ. ನಿಮ್ಮ ಟ್ರಾಫಿಕ್ ಹೆಚ್ಚಾಗಿ APIs ಮತ್ತು tools ಆಗಿದ್ದರೆ, APIs ಮತ್ತು MCP Servers use caseಗಳು ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ಮಾದರಿಗಳನ್ನು ತೋರಿಸುತ್ತವೆ.

observation mode ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿ

ಪ್ರತಿ ಇಂಟಿಗ್ರೇಶನ್ observation mode ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಫಲಿತಾಂಶಗಳು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರತಿಕ್ರಿಯಿಸುವ ವಿಧಾನವನ್ನು ಬದಲಾಯಿಸದೇ ದಾಖಲಿಸಲಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಸ್ವಯಂಚಾಲಿತ ಟ್ರಾಫಿಕ್‌ನ ಎಷ್ಟು ಭಾಗ ಪರಿಶೀಲಿತವಾಗಿದೆ, ಯಾವ ನಿರ್ವಾಹಕರು ಸಹಿ ಹಾಕುತ್ತಿದ್ದಾರೆ, ಮತ್ತು Unknown rate ಎಲ್ಲಿ ಹೆಚ್ಚು ಇದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಬಹುದು. ನಂತರ, ಸಾಕ್ಷ್ಯ ಅವುಗಳನ್ನು ಬೆಂಬಲಿಸಿದಾಗ route-by-route policyಗಳು ಬರುತ್ತವೆ. How It Works ಸಂಪೂರ್ಣ flow ಅನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಪರಿಶೀಲನೆಯನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿಸುವ ಪ್ರಾಯೋಗಿಕ ವಿವರಗಳು

ಸಹಿ ಪರಿಶೀಲನೆ ಅದರ ಸುತ್ತಲಿನ ವಿವರಗಳಷ್ಟೇ ಉತ್ತಮ. ಕೆಲವು ಅಭ್ಯಾಸಗಳು ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಪರಿಶೀಲಿತ ಸ್ವಯಂಚಾಲಿತ ವಿನಂತಿಗಳನ್ನು ನಂಬಿಗಸ್ತವಾಗಿರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತವೆ.

تازಾಗಿರುವುದನ್ನು ಪರಿಶೀಲಿಸಿ

RFC 9421 created ಮತ್ತು expires ಸಹಿ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಸಹಿ ಹಾಕಿದ ವಿನಂತಿಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಅವುಗಳನ್ನು ಹೊರುತ್ತವೆ. ಹಿಡಿದಿಟ್ಟುಕೊಂಡ ವಿನಂತಿಯನ್ನು ನಂತರ replay ಮಾಡಲಾಗದಂತೆ, ಸಣ್ಣ window ಹೊರಗಿನ ಸಹಿಗಳನ್ನು ತಿರಸ್ಕರಿಸಿ.

ಕೀಲಿಗಳನ್ನು ಸಮಂಜಸವಾಗಿ cache ಮಾಡಿ

ಪ್ರತಿ ವಿನಂತಿಗೂ ನಿರ್ವಾಹಕರ ಪ್ರಕಟಿತ ಕೀಲಿಗಳನ್ನು ಪಡೆಯುವುದರಿಂದ latency ಹೆಚ್ಚುತ್ತದೆ. ಅವುಗಳನ್ನು ಸಮಂಜಸ ಅವಧಿಗೆ cache ಮಾಡಿ ಮತ್ತು ಅಜ್ಞಾತ key identifier ಜೊತೆಗೆ ಸಹಿ ವಿಫಲವಾದಾಗ refresh ಮಾಡಿ, ώστε key rotation false failureಗಳಿಗೆ ಕಾರಣವಾಗದಂತೆ.

ವಿನಂತಿಯ ಸರಿಯಾದ ಭಾಗಗಳಿಗೆ ಸಹಿ ಹಾಕಿ

ಕೇವಲ timestamp ಅನ್ನು ಒಳಗೊಂಡಿರುವ ಸಹಿ ಬಹಳ ಕಡಿಮೆ ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಸಹಿಯಾದ ಘಟಕಗಳಲ್ಲಿ method, path ಮತ್ತು host ಸೇರಿವೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ, ಇದರಿಂದ ಸಹಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾಗಿ ಸ್ವೀಕರಿಸಿದ ವಿನಂತಿಗೆ ಜೋಡಿಸುತ್ತದೆ.

ಸಾಕ್ಷ್ಯವನ್ನು ದಾಖಲಿಸಿ

ಪ್ರತಿ ಪರಿಶೀಲಿತ ವಿನಂತಿಯೊಂದಿಗೆ key identifier, ಪ್ರಕಟಿತ ಗುರುತು ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಉಳಿಸಿ. ಅಸಾಮಾನ್ಯ ಏನಾದರೂ ಸಂಭವಿಸಿದಾಗ, ಯಾವ ಕ್ಲೈಂಟ್ ಏನು ಮತ್ತು ಯಾವಾಗ ಸಹಿ ಹಾಕಿತು ಎಂಬುದನ್ನು ನಿಮ್ಮ ತಂಡ ನಿಖರವಾಗಿ ನೋಡಬಹುದು.

Proof of Actor ಈ ಪರಿಶೀಲನೆಗಳನ್ನು Detect ಹಂತದ ಭಾಗವಾಗಿ ನಿರ್ವಹಿಸಿ, ನಿಮ್ಮ policyಗಳು ಓದಬಹುದಾದ ಆಧಾರದಾಗಿ ಫಲಿತಾಂಶವನ್ನು ವರದಿಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ಸರಳವಾಗಿಯೇ ಇರುತ್ತದೆ.

founding developer program‌ಗೆ ಸೇರಿ

Proof of Actor private beta ಯಲ್ಲಿ ಇದೆ. ಆಯ್ಕೆಯಾದ founding development ತಂಡಗಳು ಒಪ್ಪಿಗೆಯ ಬಳಕೆ ಮಿತಿಗಳ ಒಳಗೆ, ನಮ್ಮ engineer‌ಗಳ ನೇರ ಇಂಟಿಗ್ರೇಶನ್ ಬೆಂಬಲದೊಂದಿಗೆ, 12 ತಿಂಗಳುಗಳವರೆಗೆ ಉಚಿತ ಪ್ರವೇಶವನ್ನು ಪಡೆಯಬಹುದು.

ಸ್ವಯಂಚಾಲಿತ ಕ್ಲೈಂಟ್‌ಗಳು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಬರುತ್ತಿದ್ದರೆ ಮತ್ತು ಪರಿಶೀಲಿತವಾಗಿರುವವುಗಳನ್ನು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ನಿರ್ವಹಿಸಲು ಬಯಸಿದರೆ, ಆರಂಭಿಕ ಪ್ರವೇಶಕ್ಕಾಗಿ ಅರ್ಜಿ ಸಲ್ಲಿಸಿ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ನೀವು ಕಾಣುವ ಸ್ವಯಂಚಾಲಿತ ಕರೆಕರ್ತರ ಬಗ್ಗೆ ನಮಗೆ ತಿಳಿಸಿ, Proof of Actor ಹೇಗೆ ಹೊಂದುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ತೋರಿಸುತ್ತೇವೆ.

ಮೂಲಗಳು

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
Verifying Googlebot and other Google crawlers, Google Search Central.
How to verify that Bingbot is Bingbot, Bing Webmaster Blog.
Overview of OpenAI crawlers, OpenAI.

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 ಅವುಗಳನ್ನು ಇನ್ನೂ ವರ್ಗೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಸಾಕ್ಷ್ಯ ಸಾಲದಾಗ Unknown ಅನ್ನು ವರದಿಮಾಡುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಫಲಿತಾಂಶವೂ ತನ್ನ ಆಧಾರವನ್ನು ಹೇಳುತ್ತದೆ.

user-agent string ಒಂದು ಕ್ಲೈಂಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಬಹುದೇ?

ಇಲ್ಲ. user-agent stringಗಳನ್ನು ಸುಲಭವಾಗಿ ನಕಲು ಮಾಡಬಹುದು, ಆದ್ದರಿಂದ ಅವು ಪರಿಶೀಲನೆ ಅಲ್ಲ, ಘೋಷಣೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ವಿನಂತಿಯನ್ನು ಪರಿಶೀಲಿಸಬಹುದಾಗಿಸುವುದು ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಸಹಿಗಳೇ.

ನಾನು ಹೇಗೆ ಆರಂಭಿಸಬೇಕು?

ಆರಂಭಿಕ ಪ್ರವೇಶಕ್ಕಾಗಿ ಅರ್ಜಿ ಸಲ್ಲಿಸಿ. Founding ತಂಡಗಳು observation mode ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸುತ್ತವೆ ಮತ್ತು ಆಯ್ಕೆಯಾದ ತಂಡಗಳು ಒಪ್ಪಿಗೆಯ ಬಳಕೆ ಮಿತಿಗಳ ಒಳಗೆ 12 ತಿಂಗಳುಗಳವರೆಗೆ ಉಚಿತವಾಗಿ ಪಡೆಯಬಹುದು.

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

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

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

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