ವ್ಯಾಖ್ಯಾನ
ಒಂದು actor ಫಲಿತಾಂಶದ ಸಾಕ್ಷ್ಯ ಆಧಾರವು ಅದರ ಹಿಂದೆ ಇರುವ ಸಾಕ್ಷ್ಯದ ರೀತಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ. Proof of Actor ನಾಲ್ಕು ಮೌಲ್ಯಗಳನ್ನು ಬಳಸುತ್ತದೆ:
- verified: ಒಂದು cryptographic ಅಥವಾ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಪರಿಶೀಲಿಸಬಹುದಾದ assertion ಯಶಸ್ವಿಯಾಯಿತು.
- declared: actor ಅಥವಾ application ಅದನ್ನು ಹೇಳಿದೆ.
- inferred: ನಿಷ್ಕರ್ಷೆಯನ್ನು ವರ್ತನಾ ಅಥವಾ ಸಂದರ್ಭಾತ್ಮಕ ಸಂಕೇತಗಳಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ.
- unknown: ನಿರ್ಧಾರಕ್ಕೆ ಸಾಕಷ್ಟು ಸಾಕ್ಷ್ಯ ಇರಲಿಲ್ಲ.
ಪ್ರತಿ ಫಲಿತಾಂಶವೂ ಒಂದು ವರ್ಗವನ್ನು ಹೊಂದಿರುತ್ತದೆ (Human, Human + AI, Agent ಅಥವಾ Unknown, ಇದನ್ನು application traffic ಗಾಗಿ ನಮ್ಮ taxonomy ನಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ) ಮತ್ತು ಒಂದು ಆಧಾರವನ್ನು ಹೊಂದಿರುತ್ತದೆ. "Agent, verified" ಮತ್ತು "Agent, inferred" ವಿಭಿನ್ನ ಫಲಿತಾಂಶಗಳಾಗಿವೆ ಮತ್ತು ಅವುಗಳನ್ನು ವಿಭಿನ್ನವಾಗಿ ಪರಿಗಣಿಸಬೇಕು.
ಆಧಾರ ಏಕೆ ಮುಖ್ಯ
ಆಧಾರವಿಲ್ಲದೆ, ಒಂದು ವರ್ಗೀಕರಣವು ಅದು ಎಷ್ಟು ಹೊರೆ ಹೊರುವಂತೆ ಇರಬಹುದು ಎಂಬುದನ್ನು ಮುಚ್ಚಿಡುತ್ತದೆ. ಒಂದು dashboard ನಲ್ಲಿ ಸಹಿ ಮಾಡಿದ request ಗೆ "Agent" ಮತ್ತು request timing ಆಧಾರದ ಮೇಲೆ ತೆಗೆದುಕೊಂಡ ಊಹೆಗೆ "Agent" ತೋರಿಸಿದರೆ, ತಂಡಗಳು ಎರಡಕ್ಕೂ ಒಂದೇ policy ಅನ್ನು ಅನ್ವಯಿಸುವಂತೆ ಮಾಡುತ್ತದೆ. ವಿಶೇಷವಾಗಿ security-ಸಂವೇದನಶೀಲ application ಗಳಲ್ಲಿ, ಒಂದು inference ಎಂದಿಗೂ cryptographic verification ನಂತೆ ಕಾಣಬಾರದು.
ವರ್ಗವನ್ನು ಆಧಾರದಿಂದ ಬೇರ್ಪಡಿಸುವುದರಿಂದ policy ಗಳು ಸಾಕ್ಷ್ಯದ ಬಲಕ್ಕೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ:
- ಒಂದು read-only route ಯಾವುದೇ Agent ಫಲಿತಾಂಶವನ್ನು allow ಮಾಡಬಹುದು.
- ಹೆಚ್ಚಿನ ಪರಿಣಾಮ ಇರುವ route ನಿಜವಾದ operators ಎಂದು ಕೇವಲ verified agents ಅನ್ನು ಮಾತ್ರ ಪರಿಗಣಿಸಿ, ಉಳಿದ ಎಲ್ಲರಿಂದ ಇನ್ನಷ್ಟು ಬಲವಾದ credentials ಅನ್ನು ಕೇಳಬಹುದು.
ನಾಲ್ಕು ಮೌಲ್ಯಗಳು ವಿವರವಾಗಿ
Verified
ಏನೋ ಪರಿಶೀಲಿಸಲ್ಪಟ್ಟು ಯಶಸ್ವಿಯಾಯಿತು. ಅತ್ಯಂತ ಸ್ಪಷ್ಟ ಉದಾಹರಣೆ ಎಂದರೆ agent ನ operator ಪ್ರಕಟಿಸಿದ key ವಿರುದ್ಧ ಮಾನ್ಯವಾಗುವ ಒಂದು HTTP message signature (RFC 9421). Verified evidence ನಿರ್ದಿಷ್ಟ ಪರಿಶೀಲನೆಯನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಅದಕ್ಕಿಂತ ಹೆಚ್ಚೇನೂ ಅಲ್ಲ: ಮಾನ್ಯ signature request ಗೆ ಯಾವ key ಸಹಿ ಮಾಡಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಆದರೆ ಆ action authorized ಆಗಿದೆ ಎಂದು ತೋರಿಸುವುದಿಲ್ಲ.
Declared
ಯಾರೋ ಅದನ್ನು ಹೇಳಿದ್ದಾರೆ. ತಾನು ತಾನೇ agent ಎಂದು ಹೆಸರಿಸುವ client, MCP client name, ಅಥವಾ ನಿಮ್ಮ own application ಒಳಗಿನ AI-assistance disclosure ಗಳು declarations ಆಗಿವೆ. ಅವು ಉಪಯುಕ್ತ, ಬಹುಸಾರಿಗೆ ಸತ್ಯ, ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ತಪ್ಪು ಕೂಡ ಆಗಿರುತ್ತವೆ. User-agent spoofing ತಪ್ಪಾದ declaration ಗೆ ಶಾಶ್ವತ ಉದಾಹರಣೆ. User-Agent header ವಿನ್ಯಾಸದ ಪ್ರಕಾರ self-reported ಆಗಿದೆ.
Inferred
ಸಿಸ್ಟಮ್ ಸಂಕೇತಗಳಿಂದ ತಾರ್ಕಿಕವಾಗಿ ನಿರ್ಣಯ ಮಾಡಿದೆ: browser session ನಲ್ಲಿನ interaction patterns, request timing, browser context ಇಲ್ಲದಿರುವುದು, protocol ವಿವರಗಳು. Inference ಗಳು ತಪ್ಪಾಗಬಹುದು, ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು ಯಾವಾಗಲೂ inference ಎಂದೇ ಲೇಬಲ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಜನರಿಗೆ ಸಂಬಂಧಿಸಿದ ಪರಿಣಾಮಕಾರಿ ನಿರ್ಧಾರಗಳು ಅವುಗಳ ಮೇಲೆ ಮಾತ್ರ ನಿಲ್ಲಬಾರದು.
Unknown
ಸಾಕ್ಷ್ಯವು ನಿರ್ಧಾರಕ್ಕೆ ಬೆಂಬಲ ನೀಡಲಿಲ್ಲ. ಇದು Unknown classification ಜೊತೆಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ policy ಯಲ್ಲಿ ಸ್ಪಷ್ಟ fallback ಗೆ ಮ್ಯಾಪ್ ಆಗಬೇಕು. AI traffic ಅನ್ನು ವರ್ಗೀಕರಿಸುವಾಗ Unknown ಮಾನ್ಯ ಫಲಿತಾಂಶ ಏಕೆ ಎಂಬ ನಮ್ಮ ಲೇಖನ ಇದನ್ನು ವಿವರಿಸುತ್ತದೆ.
ಆಧಾರ ವಿರುದ್ಧ confidence scores
ಅನೇಕ ವ್ಯವಸ್ಥೆಗಳು ಸಾಕ್ಷ್ಯವನ್ನು ಒಂದು ಸಂಖ್ಯೆಗೆ ಕುಗ್ಗಿಸುತ್ತವೆ. ಒಂದು score ಅದು cryptographic ಪರಿಶೀಲನೆಯಿಂದ ಬಂದಿತ್ತೇ ಅಥವಾ heuristic ನಿಂದ ಬಂದಿತ್ತೇ ಎಂಬುದನ್ನು ಮರೆಮಾಡುತ್ತದೆ, ಮತ್ತು calibration ಇಲ್ಲದ percentage ಅಸ್ತಿತ್ವದಲ್ಲೇ ಇಲ್ಲದ ನಿಖರತೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಹೆಸರಿತ ಆಧಾರಗಳ ಸಣ್ಣ ಸಮೂಹವನ್ನು ತಾರ್ಕಿಕವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಸುಲಭ, ಪರಿಶೀಲನೆ ಮಾಡುವುದು ಸುಲಭ, ಮತ್ತು ದುರುಪಯೋಗ ಮಾಡುವುದೂ ಕಷ್ಟ.
ಸಾಮಾನ್ಯ ತಪ್ಪು ಕಲ್ಪನೆಗಳು
"Declared ಎಂದರೆ ನಂಬಲರ್ಹವಲ್ಲ." Declarations ಬಹುಸಾರಿಗೆ ನಿಖರವಾಗಿರುತ್ತವೆ ಮತ್ತು AI-assistance disclosure ನಂತಹ ಕೆಲವು ಪ್ರಶ್ನೆಗಳಿಗೆ ಲಭ್ಯವಿರುವ ಏಕೈಕ ಸಾಕ್ಷ್ಯವಾಗಿರುತ್ತವೆ. ಅವುಗಳನ್ನು ಕೇವಲ verification ಎಂದು ಪರಿಗಣಿಸಬಾರದು ಅಷ್ಟೇ.
"Verified ಎಂದರೆ ಸುರಕ್ಷಿತ." Verification ಎಂದರೆ ಸಹಿ ಮಾಡಿದವರ identity ಬಗ್ಗೆ, ಉದ್ದೇಶ ಅಥವಾ ಅನುಮತಿ ಬಗ್ಗೆ ಅಲ್ಲ.
Proof of Actor ನಲ್ಲಿ ಸಾಕ್ಷ್ಯ ಆಧಾರ
ಪ್ರತಿ Proof of Actor ಫಲಿತಾಂಶವೂ ತನ್ನ ಆಧಾರವನ್ನು ಮತ್ತು ಸಾಕ್ಷ್ಯದ ಮಾನವ-ಓದಬಹುದಾದ ಸಾರಾಂಶವನ್ನು ಸೂಚಿಸುತ್ತದೆ. Policies ನಿಮ್ಮ application ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಮತ್ತು ವರ್ಗ ಮತ್ತು ಆಧಾರವನ್ನು ಒಟ್ಟಿಗೆ ಬಳಸಬಹುದು. Detection & Limitations ನೋಡಿ ಅಥವಾ early access ಗೆ ಅರ್ಜಿ ಸಲ್ಲಿಸಿ.
ಮೂಲಗಳು
- RFC 9421: HTTP Message Signatures: verified ಸಾಕ್ಷ್ಯದ ಅತ್ಯಂತ ಸ್ಪಷ್ಟ ಮೂಲ
- RFC 9110: HTTP Semantics, User-Agent: self-reported, declared ಗುರುತು