ಹೋಲಿಕೆ

Proof of Actor ವಿರುದ್ಧ user agent allowlist ಗಳು: ಒಂದು ಹೆಸರು ಒಂದು ದಾವೆ, ಸಾಕ್ಷ್ಯವಲ್ಲ

User-Agent string ಆಧಾರದ ಮೇಲೆ allowlisting ಮಾಡುವುದು ಆರಂಭಿಸಲು ವೇಗವಾದುದು ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭ. ಆದರೆ ಅದನ್ನು ಮೋಸಗೊಳಿಸುವುದೂ ಸುಲಭ, ಏಕೆಂದರೆ ಆ header ಎಂದರೆ client ಕಳುಹಿಸಲು ಆಯ್ಕೆ ಮಾಡುವದೇ. ಇಲ್ಲಿ user agent allowlist ನಿಜವಾಗಿ ನಿಮಗೆ ಏನು ಹೇಳುತ್ತದೆ, network checks ಯಾವಾಗ ಸಹಾಯ ಮಾಡುತ್ತವೆ, ಮತ್ತು Proof of Actor ಘೋಷಣೆಗಳನ್ನು verified ಸಾಕ್ಷ್ಯದಿಂದ ಹೇಗೆ ಬೇರ್ಪಡಿಸುತ್ತದೆ ಎಂಬುದು ಇದೆ.

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

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

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

ಒಂದು user agent allowlist client ತನ್ನ User-Agent header ನಲ್ಲಿ ಹಾಕುವ ಹೆಸರನ್ನೇ ನಂಬುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ client ಯಾವುದೇ ಹೆಸರನ್ನಾದರೂ ಟೈಪ್ ಮಾಡಬಹುದು. Reverse DNS ಮತ್ತು ಪ್ರಕಟಿಸಿದ IP ranges ಕೆಲವು operators ಗೆ ನಿಜವಾದ ಸಾಕ್ಷ್ಯವನ್ನು ಸೇರಿಸುತ್ತವೆ, ಆದರೆ ಅವುಗಳನ್ನು ಪ್ರಕಟಿಸುವವರು ಮಾತ್ರ ಅದನ್ನು ನೀಡುತ್ತಾರೆ. Proof of Actor header ಅನ್ನು declaration ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ, agents ತಮ್ಮ requests ಗೆ sign ಮಾಡಿದಾಗ signatures ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಮತ್ತು ಸಾಕ್ಷ್ಯ ಬಲಹೀನವಾಗಿರುವಾಗ Unknown ಅನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ code facts ಕಾಣುವ ಸ್ಥಿತಿಯಲ್ಲಿ ನಿರ್ಧರಿಸುತ್ತದೆ.

user agent allowlist ವೆಬ್‌ನಲ್ಲಿನ ಅತ್ಯಂತ ಹಳೆಯ patterns ಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ನೀವು ನಂಬುವ crawler ಮತ್ತು client ಹೆಸರುಗಳ ಪಟ್ಟಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತೀರಿ. ಒಂದು request ಹೊಂದಿಕೊಳ್ಳುವ User-Agent header ನೊಂದಿಗೆ ಬಂದಾಗ, ಅದನ್ನು ಒಳಗೆ ಬಿಡುತ್ತೀರಿ, ಒಂದು challenge ಅನ್ನು ಹಾರಿಸುತ್ತೀರಿ, ಅಥವಾ ಅದಕ್ಕೆ ಕಡಿಮೆ ಭಾರದ page ಅನ್ನು ನೀಡುತ್ತೀರಿ. ಇದನ್ನು ಸ್ಥಾಪಿಸಲು ನಿಮಿಷಗಳು ಸಾಕು, ಮತ್ತು ತಂಡದ ಎಲ್ಲರೂ ಇದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ.

ಮುಖ್ಯ automated visitors ಕೆಲವು search crawlers ಮತ್ತು ಕೆಲವು monitoring tools ಆಗಿದ್ದ ಕಾಲದಲ್ಲಿ ಈ pattern ಹೆಚ್ಚು ಅರ್ಥವತ್ತಾಗಿತ್ತು. ಇಂದು, AI agents, assistants ಮತ್ತು automated clients ಹೆಚ್ಚುತ್ತಿರುವ ಸಂಖ್ಯೆಯಲ್ಲಿ applications ಗೆ ಬರುತ್ತಿವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಅನೇಕವು ಒಂದು ಹೆಸರು ಪ್ರಕಟಿಸುತ್ತವೆ. ಆ ಹೆಸರುಗಳಲ್ಲಿ ಕೆಲವು ನಿಜ. ಕೆಲವು ನಕಲಿ. header ಯಾವುದು ಎಂದು ಹೇಳುವುದಿಲ್ಲ.

Proof of Actor ವಿಭಿನ್ನ ವಿಧಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಅದು User-Agent string ಅನ್ನು ಅದು ಏನೆಂಬುದಾಗಿ, ಅಂದರೆ declaration ಆಗಿ ಪರಿಗಣಿಸಿ, ಆ ಸಾಕ್ಷ್ಯ ಇದ್ದರೆ ಅದನ್ನು ಬಲವಾದ ಸಾಕ್ಷ್ಯದೊಂದಿಗೆ ವರದಿ ಮಾಡುತ್ತದೆ. ಈ page ಹೆಸರು ಆಧರಿಸಿ allowlisting ಮಾಡುವ ಮಿತಿಗಳನ್ನು, network-level checks ಯಾವಾಗ ಸಹಾಯ ಮಾಡುತ್ತವೆ, ಮತ್ತು verified signatures ಮತ್ತು ಸ್ಪಷ್ಟವಾದ Unknown class ದೃಶ್ಯವನ್ನು ಹೇಗೆ ಬದಲಾಯಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಸಂಕ್ಷಿಪ್ತವಾಗಿ

	User agent allowlist	Proof of Actor
ಮುಖ್ಯ ಸಾಕ್ಷ್ಯ	User-Agent header ನಲ್ಲಿ ಇರುವ ಹೆಸರು	Signatures, declarations ಮತ್ತು signals, ಪ್ರತಿಯೊಂದಕ್ಕೂ ಅದರ basis label ಇದೆ
client ಇದನ್ನು ನಕಲು ಮಾಡಬಹುದೇ?	ಹೌದು, ಅದೇ string ಕಳುಹಿಸುವ ಮೂಲಕ	declared basis ಅನ್ನು ಹೇಳಿಕೊಳ್ಳಬಹುದು; verified basis ಗೆ signing key ಬೇಕು
Output	ಪಟ್ಟಿಯಲ್ಲಿ ಇದೆಯೇ ಇಲ್ಲವೇ	Human, Human + AI, Agent ಅಥವಾ Unknown, ಜೊತೆಗೆ ಒಂದು basis
ಸ್ಪಷ್ಟವಲ್ಲದ traffic	allowlist ನಲ್ಲಿ ಇಲ್ಲವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ, ಅಥವಾ default ಆಗಿ ಅನುಮತಿಸಲಾಗುತ್ತದೆ	Unknown, ನೀವು ಪ್ರತಿ route ಗೆ ಆಯ್ಕೆ ಮಾಡುವ fallback ಜೊತೆಗೆ
AI ನೆರವಿನಿಂದ ಕೆಲಸ ಮಾಡುವ ಜನರು	ಕಾಣುವುದಿಲ್ಲ; ಅವರು ಸಾಮಾನ್ಯ browsers ಅನ್ನು ಬಳಸುತ್ತಾರೆ	declared ಅಥವಾ observed ಆಗಿದಾಗ ವಿಭಿನ್ನ class, Human + AI
ನಿರ್ವಹಣೆ	ಹೆಸರುಗಳು ಬದಲಾಗುವಾಗ ಕೈಯಾರೆ list updates	agent operators ಪ್ರಕಟಿಸುವ keys; ನಿಮ್ಮ code ನಲ್ಲಿನ policies
install ಮಾಡಿದಾಗ default	ಪಟ್ಟಿಯು ಅನುಮತಿಸುವದೇ	Observation; ನೀವು policy ಸೇರಿಸುವವರೆಗೂ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ
ಅತ್ಯುತ್ತಮವಾದುದು	ಚೆನ್ನಾಗಿ ನಡೆದುಕೊಳ್ಳುವ, known clients ಗಳ ಕಡಿಮೆ ವೆಚ್ಚದ routing	product ಮತ್ತು policy ನಿರ್ಧಾರಗಳಿಗೆ ಸಾಕ್ಷ್ಯ ಆಧಾರಿತ actor context

ಉಳಿದ page ಪ್ರತಿ ಸಾಲನ್ನು ವಿವರಿಸುತ್ತದೆ.

User-Agent ಆಧರಿಸಿ allowlisting ಮಾಡುವುದು ಏಕೆ spoof ಮಾಡಬಹುದಾಗಿದೆ

User-Agent header ಅನ್ನು client ಹೊಂದಿಸುತ್ತದೆ. Browser ಅದನ್ನು ಹೊಂದಿಸುತ್ತದೆ, script ಅದನ್ನು ಹೊಂದಿಸುತ್ತದೆ, ಮತ್ತು agent framework ಅದನ್ನು ಹೊಂದಿಸುತ್ತದೆ. HTTP ನಲ್ಲಿ value ನಿಜವೇ ಎಂದು ಪರಿಶೀಲಿಸುವುದು ಏನೂ ಇಲ್ಲ. ನಿಮ್ಮ allowlist ಒಂದು string ಅನ್ನು ನಂಬಿದರೆ, ಆ string ಅನ್ನು ನಕಲಿಸುವ ಯಾರಿಗಾದರೂ ಅದೇ treatment ಸಿಗುತ್ತದೆ.

ಇದನ್ನು user agent spoofing ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ, ಮತ್ತು ಇದು ಸರಳ ಕಾರಣದಿಂದ ಸಾಮಾನ್ಯವಾಗಿದೆ: ವೆಚ್ಚವೇ ಇಲ್ಲ. ಒಂದು challenge ತಪ್ಪಿಸಲು ಬಯಸುವ scraper ಗೆ ನೀವು ನಂಬುವ crawler ನ ಹೆಸರನ್ನು ಸಾಲವಾಗಿ ತೆಗೆದುಕೊಳ್ಳುವುದು ಸಾಕು. ಕೆಟ್ಟ ನಡೆ ತೋರಿಸುವ client ಜನಪ್ರಿಯ assistant ಎಂದು ಹೇಳಿಕೊಳ್ಳಬಹುದು. ಒಂದು legitimate tool ಕೂಡ library default ಹಾಗೆ ಸಾಮಾನ್ಯ browser string ಅನ್ನು ಕಳುಹಿಸಬಹುದು.

ಇದರಿಂದ user agent allowlist ಗೆ ಎರಡು failure modes ಇವೆ:

False trust: ನಂಬಲಾಗದ client trusted name ಅನ್ನು ಹೇಳಿಕೊಂಡು ಒಳಗೆ ಬರುತ್ತದೆ.
False doubt: legitimate client ಅನಿರೀಕ್ಷಿತ ಅಥವಾ ಸಾಮಾನ್ಯ string ಅನ್ನು ಕಳುಹಿಸಿ ವಿಫಲವಾಗುತ್ತದೆ.

ಈ ಎರಡೂ failure ಗಳೂ header ನಿಂದ ಮಾತ್ರ ಕಾಣುವುದಿಲ್ಲ. ಅದೇ ಮೂಲ ಮಿತಿ, ಮತ್ತು ಯಾವುದೇ list maintenance ಅದನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ.

ಇದರರ್ಥ ನೀವು User-Agent strings ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಬೇಕು ಎಂದಲ್ಲ. ಚೆನ್ನಾಗಿ ನಡೆದುಕೊಳ್ಳುವ crawlers ಮತ್ತು agents ನಿಷ್ಠೆಯಿಂದ ತಮ್ಮನ್ನು ಪರಿಚಯಿಸುತ್ತಾರೆ, ಮತ್ತು ಆ ಹೆಸರು routing, analytics ಮತ್ತು debugging ಗೆ ಉಪಯುಕ್ತ ಸೂಚನೆ. ಅದು client ತನ್ನ ಬಗ್ಗೆ ಏನು ಹೇಳುತ್ತಿದೆ ಎಂಬುದನ್ನು ನಿಮಗೆ ಹೇಳುತ್ತದೆ.

ಆ ಮಾಹಿತಿಗೆ ಸರಿಯಾದ ಸ್ಥಳ ಎಂದರೆ declaration ಆಗಿ, ಇತರ ಸಾಕ್ಷ್ಯಗಳೊಂದಿಗೆ ತೂಕ ಹಾಕಿ ನೋಡಬೇಕು, ಸ್ವತಃ access ಅನ್ಲಾಕ್ ಮಾಡುವ key ಆಗಿ ಅಲ್ಲ. Proof of Actor ಅದನ್ನು ನಿಖರವಾಗಿ ಆ ರೀತಿಯಲ್ಲಿ ದಾಖಲಿಸುತ್ತದೆ.

Reverse DNS ಮತ್ತು IP lists: ಭಾಗಶಃ ಕ್ರಮಗಳು

ಅನೇಕ ತಂಡಗಳು network checks ಮೂಲಕ ಒಂದು allowlist ಅನ್ನು ಬಲಪಡಿಸುತ್ತವೆ. ಅವು ಸಹಾಯ ಮಾಡುತ್ತವೆ, ಮತ್ತು ನಿಖರವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮೌಲ್ಯಯುತವಾಗಿದೆ.

Reverse DNS verification

ಕೆಲವು crawler operators ಒಂದು verification process ಅನ್ನು ದಾಖಲಿಸುತ್ತಾರೆ: request ನ IP address ಗೆ hostname ಅನ್ನು lookup ಮಾಡಿ, ಅದು operator ನ domain ಗೆ ಸೇರಿತೇ ಎಂದು ಪರಿಶೀಲಿಸಿ, ನಂತರ ಆ hostname ಅನ್ನು lookup ಮಾಡಿ ಅದು ಅದೇ IP ಗೆ ಮರಳುತ್ತದೆಯೇ ಎಂದು ದೃಢಪಡಿಸಿ. ಈ round trip ಯಶಸ್ವಿಯಾದರೆ, request operator ನ infrastructure ನಿಂದ ಬಂದಿತೆಂಬ ನಿಜವಾದ ಸಾಕ್ಷ್ಯ ನಿಮ್ಮ ಬಳಿ ಇರುತ್ತದೆ.

ಇದರ ಮಿತಿಗಳು ಪ್ರಾಯೋಗಿಕ. ಇದನ್ನು ದಾಖಲೆಮಾಡಿ ಬೆಂಬಲಿಸುವ operators ಗೆ ಮಾತ್ರ ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಇದಕ್ಕೆ cache ಮಾಡಬೇಕಾದ DNS lookups ಸೇರುತ್ತವೆ. ಮತ್ತು ಇದು network ಬಗ್ಗೆ ಹೇಳುತ್ತದೆ, ಆದರೆ ಆ network ನಲ್ಲಿ ಯಾವ product ಅಥವಾ agent request ಮಾಡಿತು ಎಂಬುದರ ಬಗ್ಗೆ ಅಲ್ಲ.

ಪ್ರಕಟಿಸಿದ IP ranges

ಇತರ operators ತಮ್ಮ automated clients ಬಳಸುವ IP ranges ಅನ್ನು ಪ್ರಕಟಿಸುತ್ತಾರೆ. request ಅನ್ನು ಆ ranges ಗೆ ಹೊಂದಿಸುವುದು ವೇಗವಾದುದು ಮತ್ತು reverse DNS ಗೆ ಸಮಾನವಾದ ಸಾಕ್ಷ್ಯವನ್ನು ನೀಡುತ್ತದೆ. IETF ನಲ್ಲಿ ಈ ranges ಪ್ರಕಟಿಸಲು standard format ಕುರಿತು ಮುಂದುವರಿಯುವ ಚರ್ಚೆ ಇದೆ, ಆದರೆ November 2026 ರವರೆಗೆ ಯಾವುದೇ ಸ್ಥಿರವಾದ standard ಇಲ್ಲ, ಮತ್ತು coverage ಪ್ರತಿಯೊಂದು operator ಪ್ರಕಟಿಸಲು ಆಯ್ಕೆಮಾಡುವುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ.

ಹೆಚ್ಚು agents shared cloud infrastructure ನಲ್ಲಿ, proxies ಹಿಂದೆ, ಅಥವಾ ಬಳಕೆದಾರರ ಸ್ವಂತ device ನಿಂದ ಕಾರ್ಯನಿರ್ವಹಿಸುವಂತೆ IP ಸಾಕ್ಷ್ಯ ಕೂಡ ದುರ್ಬಲವಾಗುತ್ತದೆ. ಒಂದು cloud address ಅನೇಕ ಸಂಬಂಧವಿಲ್ಲದ clients ಗಳನ್ನು ಹೊಂದಿರಬಹುದು, ಮತ್ತು ಒಬ್ಬ ವ್ಯಕ್ತಿಯ browser ನಿಂದ ಕಾರ್ಯನಿರ್ವಹಿಸುವ agent ಆ ವ್ಯಕ್ತಿಯ network ಹಾಗೆ ಕಾಣುತ್ತದೆ.

Network checks ಒಟ್ಟಾರೆ ಏನು ಸೇರಿಸುತ್ತವೆ

Reverse DNS ಮತ್ತು IP lists ಕೆಲವು declarations ಅನ್ನು well-known operators ನ ಒಂದು ಭಾಗಕ್ಕೆ ಇನ್ನಷ್ಟು ಬಲವಾದದ್ದಾಗಿ ಮಾಡುತ್ತವೆ. ಅವು agents ಮತ್ತು tools ಗಳ long tail ಅನ್ನು ಆವರಿಸುವುದಿಲ್ಲ, ಮತ್ತು AI ಜೊತೆಗೆ ಕೆಲಸ ಮಾಡುವ ಜನರಿಗೆ ಯಾವ ರೀತಿಯ ಸಹಾಯವೂ ಮಾಡುವುದಿಲ್ಲ. ಅವು ಭಾಗಶಃ ಕ್ರಮಗಳು: ಬಳಸಲು ಯೋಗ್ಯ, ಆದರೆ ಸ್ವತಃ ಸಾಕಾಗದು.

Signatures ವಿರುದ್ಧ declarations

ಸಾಕ್ಷ್ಯದ ಬಲವಾದ ರೂಪ cryptographic signature. HTTP Message Signatures ನಲ್ಲಿ, RFC 9421 ನಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಿದಂತೆ, client ಪ್ರತಿ request ನ ಆಯ್ದ ಭಾಗಗಳನ್ನು private key ಬಳಸಿ sign ಮಾಡುತ್ತದೆ. verifier operator ನ ಪ್ರಕಟಿಸಿದ public key ಅನ್ನು ಪಡೆಯುತ್ತದೆ ಮತ್ತು signature ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಅದು verify ಆದರೆ, request ಆ key ನ holder ಮೂಲಕ sign ಮಾಡಲಾಗಿದೆ, ಮತ್ತು signed parts ಮಾರ್ಗಮಧ್ಯೆ ಬದಲಾಗಿಲ್ಲ.

IETF Web Bot Auth working group automated clients ಈ signatures ಅನ್ನು ಹೇಗೆ ಬಳಸಬೇಕು ಮತ್ತು ತಮ್ಮ keys ಅನ್ನು ಹೇಗೆ ಪ್ರಕಟಿಸಬೇಕು ಎಂಬುದನ್ನು standardize ಮಾಡುತ್ತಿದೆ. Web Bot Auth for product teams ಕುರಿತ ನಮ್ಮ explainer ಇಂದಿನ ಸ್ಥಿತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ.

Proof of Actor ಮಾನ್ಯವಾದ signature ಅನ್ನು Verified ಸಾಕ್ಷ್ಯವಾಗಿ ಬಳಸುತ್ತದೆ. User-Agent string, client hint ಅಥವಾ request body ಯಲ್ಲಿನ self-description ಅನ್ನು Declared ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ. Behavioral ಮತ್ತು contextual signals ಅನ್ನು Inferred ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ, ಮತ್ತು ಅವುಗಳನ್ನು ಆ ರೀತಿಯಲ್ಲೇ label ಮಾಡುತ್ತದೆ. ಪ್ರತಿ result ಅದು ಯಾವ basis ಮೇಲೆ ನಿಂತಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ team ದಾವೆಯನ್ನು ಪರಿಶೀಲನೆಯೊಂದಿಗೆ ಗೊಂದಲಗೊಳಿಸುವುದಿಲ್ಲ. ಸಂಪೂರ್ಣ ವ್ಯಾಖ್ಯಾನಗಳಿಗಾಗಿ evidence basis entry ನೋಡಿ.

ಮಾನ್ಯ ಸಾಕ್ಷ್ಯಕ್ಕೂ ಒಂದು ಮಿತಿ ಅನ್ವಯಿಸುತ್ತದೆ. ಮಾನ್ಯ signature ಯಾವ key request ಗೆ sign ಮಾಡಿತು ಎಂಬುದನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಅದು agent ಕೇಳುತ್ತಿರುವ ಕ್ರಿಯೆಯನ್ನು ಮಾಡಲು ಅದು ಅನುಮತಿಸಲ್ಪಟ್ಟಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಅದು agent authorization ಪ್ರಶ್ನೆ, ಮತ್ತು ಅದು ನಿಮ್ಮ application ನಲ್ಲೇ ಉಳಿಯುತ್ತದೆ.

ಊಹಿಸುವ ಬದಲಿಗೆ Unknown ಅನ್ನು ನಿರ್ವಹಿಸುವುದು

ಒಂದು allowlist ಪ್ರತಿ request ಅನ್ನು ಎರಡು bucket ಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಬಲವಂತಪಡಿಸುತ್ತದೆ: ಪಟ್ಟಿಯಲ್ಲಿ ಅಥವಾ ಇಲ್ಲ. ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇದರರ್ಥ ಸ್ಪಷ್ಟವಲ್ಲದ traffic ಗೆ ನಿಮ್ಮ default ಏನಿದೆಯೋ ಅದೇ ಸಿಗುತ್ತದೆ, ಮತ್ತು default ಸಾಮಾನ್ಯವಾಗಿ ಸಂಪೂರ್ಣ site ಗೆ ಒಮ್ಮೆ ಮಾತ್ರ ಆಯ್ಕೆಮಾಡಲಾಗುತ್ತದೆ.

Proof of Actor Unknown ಅನ್ನು ಮೊದಲ ದರ್ಜೆಯ result ಆಗಿ ಪರಿಗಣಿಸುತ್ತದೆ. ಸಾಕ್ಷ್ಯ reliable ನಿರ್ಧಾರಕ್ಕೆ ಬೆಂಬಲಿಸದಾಗ, ಅದು ಊಹಿಸುವ ಬದಲಿಗೆ ಅದನ್ನು ಹೇಳುತ್ತದೆ. ನಂತರ ನಿಮ್ಮ policies ಪ್ರತಿ route ಗೆ Unknown ಎಂದರೆ ಏನು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ:

ಸಾರ್ವಜನಿಕ documentation ಅಥವಾ marketing pages ನಲ್ಲಿ, ಅದನ್ನು ಅನುಮತಿಸಿ.
search ಅಥವಾ listing endpoints ನಲ್ಲಿ, ನಿಮ್ಮ ಸಾಮಾನ್ಯ rate limits ಜೊತೆಗೆ ಅದನ್ನು ಅನುಮತಿಸಿ.
account changes ನಲ್ಲಿ, ನಿಮ್ಮ ಈಗಿನ checks ಗಳನ್ನು ಮುಂದುವರಿಸಿ.
ಹೆಚ್ಚು ಪರಿಣಾಮ ಬೀರುವ ಕ್ರಿಯೆಗಳಲ್ಲಿ, ಅದನ್ನು review ಗೆ ಕಳುಹಿಸಿ ಅಥವಾ ಬಲವಾದ signal ಕೇಳಿ.

handling Unknown traffic ಕುರಿತ guide ಮತ್ತು unknown classification entry ಈ patterns ಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ. ಸಮಯದೊಂದಿಗೆ ನಿಮ್ಮ Unknown rate ಅನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದರಿಂದ ನಿಮ್ಮ traffic ನ ಎಷ್ಟು ಭಾಗ ಇನ್ನೂ ದುರ್ಬಲ ಸಾಕ್ಷ್ಯಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ ಎಂಬುದೂ ತಿಳಿಯುತ್ತದೆ.

AI ನೆರವಿನಲ್ಲಿರುವ ಜನರ ಬಗ್ಗೆ ಏನು?

ಒಂದು user agent allowlist ಸಾಮಾನ್ಯ browser ಒಳಗೆ AI assistant ಬಳಸುವ ವ್ಯಕ್ತಿಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಅವರ User-Agent ಸಾಮಾನ್ಯ browser string ಆಗಿರುತ್ತದೆ. ಆದರೂ ಅನೇಕ products AI-drafted submissions ಅನ್ನು label ಮಾಡಲು ಅಥವಾ onboarding ನಲ್ಲಿ AI-assisted users ಹೇಗೆ ಸಾಗುತ್ತಾರೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಆ interaction ಅನ್ನು ಗುರುತಿಸಲು ಬಯಸುತ್ತವೆ.

ಬೆಂಬಲಿತ integration ಮೂಲಕ assistance declared ಆಗಿದಾಗ ಅಥವಾ observed ಆಗಿದಾಗ Proof of Actor ಈ interactions ಅನ್ನು Human + AI ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ. ಇದು ಬರವಣಿಗೆಯ ಶೈಲಿಯಿಂದ ಮಾತ್ರ ಊಹಿಸುವುದಿಲ್ಲ. AI-assisted interaction ನಲ್ಲಿ ಇನ್ನಷ್ಟು ಓದಿ.

Allowlist ನಿಂದ evidence-based policies ಗೆ ಸಾಗುವುದು

ಮೊದಲ ದಿನದಲ್ಲೇ ನಿಮ್ಮ allowlist ಅನ್ನು ತೆಗೆದುಹಾಕಬೇಕಾಗಿಲ್ಲ. ಸುರಕ್ಷಿತ ಮಾರ್ಗ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

Observation mode ನಲ್ಲಿ ಸ್ಥಾಪಿಸಿ. Proof of Actor ಏನನ್ನೂ ಬದಲಾಯಿಸುವುದಿಲ್ಲ. ನಿಮ್ಮ allowlist ಕೆಲಸ ಮಾಡುತ್ತಲೇ ಇರುತ್ತದೆ.
ಹೋಲಿಸಿ. ಪ್ರತಿ route ಗೆ, ಯಾವ allowlisted requests ಗಳು verified ಸಾಕ್ಷ್ಯವನ್ನು ಹೊರುತ್ತವೆ, ಯಾವವು ಕೇವಲ declaration ಅನ್ನು ಹೊರುತ್ತವೆ, ಮತ್ತು ಯಾವವು Unknown ಆಗಿ ಮುಗಿಯುತ್ತವೆ ಎಂಬುದನ್ನು ನೋಡಿ.
Policies preview ಮಾಡಿ. verified agents, declared agents ಮತ್ತು Unknown ಅನ್ನು ವಿಭಿನ್ನವಾಗಿ ಪರಿಗಣಿಸುವ policy ಯನ್ನು ರೂಪಿಸಿ, ಮತ್ತು ನಿಜವಾದ traffic ಮೇಲೆ ಅದರ ಪರಿಣಾಮವನ್ನು preview ಮಾಡಿ.
Route by route enforce ಮಾಡಿ. spoof ಮಾಡಿದ ಹೆಸರು ಅತ್ಯಂತ ಮುಖ್ಯವಾಗಿರುವ routes ಗಳಿಂದ ಆರಂಭಿಸಿ.
Allowlist ಅನ್ನು ಸೂಚನೆಯಾಗಿ ಇಟ್ಟುಕೊಳ್ಳಿ. ಹೆಸರುಗಳು routing ಮತ್ತು analytics ಗೆ ಇನ್ನೂ ಉಪಯುಕ್ತವಾಗಿವೆ, ಈಗ ಅವುಗಳ basis ಕಾಣುವಂತೆ.

rolling out actor-aware policies safely ಕುರಿತ guide ಪ್ರತಿಯೊಂದು ಹಂತವನ್ನೂ ಒಳಗೊಂಡಿದೆ, ಮತ್ತು verified automated requests signed clients ಹೇಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.

Allowlist ಸಾಕಾಗುವ ಸಂದರ್ಭ

ಕಡಿಮೆ ಪಣವಿರುವ routing ಗೆ, ಉದಾಹರಣೆಗೆ ಸಾರ್ವಜನಿಕ content ನಲ್ಲಿ known crawler ಗೆ ಹಗುರವಾದ page ನೀಡುವುದು, user agent allowlist ಆಗಾಗ್ಗೆ ಸರಿಯೇ ಇರುತ್ತದೆ. spoof ಮಾಡಿದ ಹೆಸರಿನ ವೆಚ್ಚ ಕಡಿಮೆ.

ನಿರ್ಧಾರಕ್ಕೆ ಪರಿಣಾಮಗಳಿದ್ದಾಗ, ಉದಾಹರಣೆಗೆ challenge ಹಾರಿಸುವುದು, richer data ತೋರಿಸುವುದು, ಅಥವಾ ಒಂದು write ಅನುಮತಿಸುವುದು, ನೀವು ಪರಿಶೀಲಿಸಬಹುದಾದ ಸಾಕ್ಷ್ಯ ಬಯಸುತ್ತೀರಿ. ಅದೇ Proof of Actor ನ ಸ್ಥಳ, ನೀವು ಈಗಾಗಲೇ ನಡೆಸುತ್ತಿರುವ network checks ಮತ್ತು edge controls ಜೊತೆಗೆ ಕೆಲಸ ಮಾಡುವಂತೆ.

ಪ್ರಾರಂಭಿಸಿ

Proof of Actor private beta ನಲ್ಲಿ ಇದೆ. ಆಯ್ಕೆಯಾದ founding developer ತಂಡಗಳು agreed usage limits ಒಳಗೆ up to 12 months free access ಪಡೆಯಬಹುದು, ಮತ್ತು automatic billing ಇರುವುದಿಲ್ಲ. early access ಗೆ ಅರ್ಜಿ ಸಲ್ಲಿಸಿ ಮತ್ತು ನೀವು ಇಂದು ಯಾವ clients ಗಳನ್ನು allowlist ಮಾಡುತ್ತೀರಿ, ಮತ್ತು ಯಾವ routes ಗಳನ್ನು ಉತ್ತಮ ಸಾಕ್ಷ್ಯದೊಂದಿಗೆ ರಕ್ಷಿಸಬೇಕೆಂದು ಬಯಸುತ್ತೀರಿ ಎಂದು ನಮಗೆ ತಿಳಿಸಿ.

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 ಏಕೀಕರಣ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಓದಿ

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

ಒಂದು user agent allowlist ನಿಷ್ಪ್ರಯೋಜಕವೇ?

ಇಲ್ಲ. ಅದು ಚೆನ್ನಾಗಿ ನಡೆದುಕೊಳ್ಳುವ clients ನಿಂದ ಬಂದ ಉಪಯುಕ್ತ declaration ಆಗಿದೆ ಮತ್ತು known crawlers ಗೆ ಮಾರ್ಗದರ್ಶನ ನೀಡುವ ಕಡಿಮೆ ವೆಚ್ಚದ ವಿಧಾನ. ಸಮಸ್ಯೆ ಅದನ್ನು ಸಾಕ್ಷ್ಯವೆಂದು ಪರಿಗಣಿಸುವುದು. ಯಾವುದೇ client ಯಾವುದೇ User-Agent string ಅನ್ನು ಕಳುಹಿಸಬಹುದು, ಆದ್ದರಿಂದ allowlist ಒಂದರಿಂದ ಮಾತ್ರ ಸಂವೇದನಾಶೀಲ ಕ್ರಿಯೆಗಳನ್ನು ಎಂದಿಗೂ ಅನ್ಲಾಕ್ ಮಾಡಬಾರದು.

Reverse DNS verification, User-Agent spoofing ಅನ್ನು ಸರಿಪಡಿಸುತ್ತದೆಯೇ?

ಅದನ್ನು ದಾಖಲೆ ಮಾಡಿರುವ operators ಗೆ ಇದು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಒಂದು reverse lookup ನಂತರ matching forward lookup request ನ IP address ಅನ್ನು operator ನ domain ಗೆ ಕೊಂಡಿಡುತ್ತದೆ. ಇದು ಅದನ್ನು ಬೆಂಬಲಿಸುವ operators ಗೆ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು shared cloud ಅಥವಾ residential addresses ನಿಂದ ಬರುವ traffic ಬಗ್ಗೆ ಇದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

Proof of Actor User-Agent header ಅನ್ನು ಹೇಗೆ ಪರಿಗಣಿಸುತ್ತದೆ?

Declaration ಆಗಿ. ಇದು declared basis ನೊಂದಿಗೆ ಫಲಿತಾಂಶಕ್ಕೆ ಕೊಡುಗೆ ನೀಡುತ್ತದೆ, ಎಂದಿಗೂ verified basis ಅಲ್ಲ. ಒಂದು verified basis ಗೆ ಪ್ರಕಟಿಸಲಾದ key ಗೆ ವಿರುದ್ಧವಾಗಿ ಪರಿಶೀಲಿಸಿದ HTTP Message Signature ಮುಂತಾದ ಸಾಕ್ಷ್ಯ ಬೇಕಾಗುತ್ತದೆ.

ಒಂದು verified signature ಏನನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ?

ಯಾವ key request ಗೆ sign ಮಾಡಿತು ಮತ್ತು signed parts ಬದಲಾಯಿಸಲ್ಪಟ್ಟಿರಲಿಲ್ಲ ಎಂಬುದನ್ನು ಅದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಆದರೆ ಆ agent ಆ action ಮಾಡಲು authorized ಆಗಿದೆ ಎಂದು ಅದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. Authorization ನಿಮ್ಮ application ನಲ್ಲೇ ಉಳಿಯುತ್ತದೆ.

ತಮ್ಮನ್ನು known agent ಎಂದು ಹೇಳಿಕೊಂಡರೂ verify ಮಾಡಲಾಗದ clients ಗೆ ಏನು ಆಗುತ್ತದೆ?

Proof of Actor ಸಾಕ್ಷ್ಯ ಬೆಂಬಲಿಸುವುದನ್ನೇ ವರದಿ ಮಾಡುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ declared ಅಥವಾ inferred result, ಅಥವಾ Unknown. ನಿಮ್ಮ policy ಆ route ಗೆ fallback ಏನು ಎಂಬುದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಹೇಳಿಕೊಂಡ ಹೆಸರನ್ನು ನಂಬುವುದಿಲ್ಲ.

Proof of Actor ಸೇರಿಸಿದರೆ ನನ್ನ ಈಗಿನ allowlist ವರ್ತನೆ ಬದಲಾಗುತ್ತದೆಯೇ?

ಇಲ್ಲ. ಇದು observation mode ನಲ್ಲಿ ಆರಂಭವಾಗುತ್ತದೆ. ಏನನ್ನೂ ಬದಲಾಯಿಸುವ ಮುನ್ನ ನಿಜವಾದ traffic ಮೇಲೆ ಇದರ ಫಲಿತಾಂಶಗಳನ್ನು ನಿಮ್ಮ allowlist ನಿರ್ಧಾರಗಳೊಂದಿಗೆ ಹೋಲಿಸಬಹುದು.

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

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

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

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