ಹಸ್ತಾಂತರಿತ ಅಧಿಕಾರ ಎಂದರೆ ಏನು
ಹಸ್ತಾಂತರಿತ ಅಧಿಕಾರ ಎಂದರೆ ಒಬ್ಬ ವ್ಯಕ್ತಿ (ಅಥವಾ ಸಂಸ್ಥೆ) ತನ್ನ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು AI ಏಜೆಂಟ್‌ಗೆ ನೀಡುವ ಅನುಮತಿ. ಒಂದು ಸಹಾಯಕ ನಿಮ್ಮ ಕ್ಯಾಲೆಂಡರ್‌ನಲ್ಲಿ ಸಭೆಯನ್ನು ಬುಕ್ ಮಾಡಿದಾಗ, ನಿಮ್ಮ ಹೆಸರಿನಲ್ಲಿ support ticket ಸಲ್ಲಿಸಿದಾಗ ಅಥವಾ ಪೂರೈಕೆದಾರರ ಪೋರ್ಟಲ್‌ನಿಂದ invoice ಪಡೆದುಕೊಂಡಾಗ, ಅದು ನಿಮ್ಮಿಂದಲೇ ಆರಂಭವಾದ ಅಧಿಕಾರವನ್ನು ಬಳಸುತ್ತಿದೆ.
ಉತ್ತಮ ಹಸ್ತಾಂತರದಲ್ಲಿ ಮೂರು ಗುಣಗಳಿವೆ: ಅದು ಸೀಮಿತ ವ್ಯಾಪ್ತಿಯಲ್ಲಿರುತ್ತದೆ (ಏಜೆಂಟ್ ಕೆಲವು ಕೆಲಸಗಳನ್ನು ಮಾತ್ರ ಮಾಡಬಹುದು, ಎಲ್ಲವನ್ನೂ ಅಲ್ಲ), ಸಮಯದ ಮಿತಿಯಲ್ಲಿರುತ್ತದೆ (ಅದು ಅವಧಿ ಮುಗಿಯುತ್ತದೆ ಅಥವಾ ರದ್ದುಗೊಳಿಸಬಹುದು) ಮತ್ತು ಆರೋಪಿಸಬಹುದಾದದ್ದಾಗಿರುತ್ತದೆ (ಸ್ವೀಕರಿಸುವ application ಯಾರ ಅಧಿಕಾರವನ್ನು ಬಳಸಲಾಗುತ್ತಿದೆ ಎಂದು ತಿಳಿಯಬಹುದು).
ಅದು application ಗಳಿಗೆ ಏಕೆ ಮುಖ್ಯ
ಒಂದು application ದೃಷ್ಟಿಯಿಂದ, agent ವಿನಂತಿ ಗರಿಷ್ಠ ಮೂರು ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆಗಳನ್ನು ಎತ್ತುತ್ತದೆ:
- ಈ ವಿನಂತಿಯನ್ನು ಯಾವ client ಕಳುಹಿಸಿದೆ? ಅದು agent ಗುರುತು, ಮತ್ತು signed requests ಅದನ್ನು ಸ್ಥಾಪಿಸಬಹುದು (ನೋಡಿ HTTP Message Signatures).
- ಇದು ಯಾರ ಅಧಿಕಾರದ ಅಡಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ? ಅದು delegation.
- ಈ action ಗೆ ಆ ಅಧಿಕಾರ ಸಾಕೇ? ಅದು authorization, application ನ ಸ್ವಂತ policy ಮೂಲಕ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ.
ಚಿರಪರಿಚಿತ assistant operator ನಿಂದ ಬಂದ signed request ಮೊದಲ ಪ್ರಶ್ನೆಗೆ ಚೆನ್ನಾಗಿ ಉತ್ತರಿಸುತ್ತದೆ. ಆದರೆ ಅದು ಎರಡನೆಯ ಪ್ರಶ್ನೆಯ ಬಗ್ಗೆ ಸ್ವತಃ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಸಹಾಯಕ ನಿಮ್ಮ ಬಳಕೆದಾರರಲ್ಲಿ ಒಬ್ಬರಿಗಾಗಿ, ನಿಮ್ಮ ಬಳಕೆದಾರರಲ್ಲದ ಯಾರಿಗೋಸ್ಕರ, ಅಥವಾ ಸಂಪೂರ್ಣವಾಗಿ ತನ್ನದೇ ಮುಂದಾಳತ್ವದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರಬಹುದು. client ಗುರುತನ್ನು ವ್ಯಕ್ತಿಯ ಒಪ್ಪಿಗೆಯ ಸಾಕ್ಷಿಯಾಗಿ ಕಾಣುವುದು agent-ಮುಖಿ design ನಲ್ಲಿ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ನೋಡಿ signed AI agent requests ಏನು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ ಮತ್ತು ಏನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
delegation ಸಾಮಾನ್ಯವಾಗಿ ಹೇಗೆ ವ್ಯಕ್ತವಾಗುತ್ತದೆ
- OAuth ಶೈಲಿಯ grants. ವ್ಯಕ್ತಿ ನಿಮ್ಮ application ಗೆ sign in ಮಾಡಿ, OAuth 2.0 (RFC 6749) ನಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಿದಂತೆ, ಸೀಮಿತ scopes ಹೊಂದಿರುವ token ಅನ್ನು agent ಗೆ ನೀಡುತ್ತಾನೆ. ನಂತರ ನಿಮ್ಮ application ಗೆ ಆ token ಯಾವ ಅಧಿಕಾರವನ್ನು ಹೊತ್ತುಕೊಂಡಿದೆ ಎಂಬುದು ನಿಖರವಾಗಿ ತಿಳಿಯುತ್ತದೆ, ಮತ್ತು grant ಅನ್ನು ರದ್ದುಗೊಳಿಸಬಹುದು (RFC 7009).
- Account-scoped API keys ಬಳಕೆದಾರನು ನಿರ್ದಿಷ್ಟ integration ಗಾಗಿ ಸೃಷ್ಟಿಸುವ keys, ಸಾಧ್ಯವಾದರೆ ಸೀಮಿತ ಅನುಮತಿಗಳೊಂದಿಗೆ.
- In-app ದೃಢೀಕರಣಗಳು ಹೆಚ್ಚು ಪ್ರಭಾವ ಬೀರುವ actions ಗಾಗಿ, ಅಲ್ಲಿ ವ್ಯಕ್ತಿ agent ಸಿದ್ಧಪಡಿಸಿದ ನಿರ್ದಿಷ್ಟ action ಅನ್ನು ಅನುಮೋದಿಸುತ್ತಾನೆ.
- Token ಮಟ್ಟದ delegation claims. OAuth 2.0 Token Exchange (RFC 8693) ಒಂದು
act(actor) claim ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಅದು ಒಬ್ಬ ಪಕ್ಷ ಇನ್ನೊಬ್ಬರ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವುದನ್ನು ದಾಖಲಿಸುತ್ತದೆ. requests ನಲ್ಲಿ agent delegation ಅನ್ನು ವ್ಯಕ್ತಪಡಿಸುವ ಹೊಸ ಕೆಲಸ ಇನ್ನೂ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿದೆ, ಮತ್ತು applications ಗಳು ಯಾವುದೇ delegation claim ಅನ್ನು ನೇರವಾಗಿ ಒಪ್ಪಿಕೊಳ್ಳುವ ಬದಲು ತಮ್ಮ ಸ್ವಂತ ದಾಖಲೆಗಳ ವಿರುದ್ಧ ಪರಿಶೀಲಿಸಬೇಕು.
ಸಾಮಾನ್ಯ ತಪ್ಪು ಕಲ್ಪನೆಗಳು
- "Agent verified ಆಗಿದ್ದರೆ, ಬಳಕೆದಾರರು ಅದನ್ನು ಅನುಮೋದಿಸಿದ್ದಾರೆ." Verification client ಅನ್ನು ಗುರುತಿಸುತ್ತದೆ. ಅನುಮೋದನೆ ವ್ಯಕ್ತಿಯಿಂದಲೇ, ನಿಮ್ಮ application ನಂಬುವ channel ಮೂಲಕ, ಬರಬೇಕು.
- "ನನ್ನ ಬಳಕೆದಾರರ session ಅನ್ನು agent ಬಳಸುವುದು ಸರಿ." ಅದು ಕೆಲ ಸಂದರ್ಭಗಳಲ್ಲಿ ಸರಿ ಇರಬಹುದು, ಆದರೆ ಆ session ಅನ್ನು interactive human ಬಳಕೆಗೆ ನೀಡಲಾಗಿತ್ತು. ಹಲವಾರು applications ಗಳಿಗೆ automation ಗಾಗಿ ಮೀಸಲಾದ, ಸೀಮಿತ grant ಇಷ್ಟವಾಗುತ್ತದೆ, ಇದರಿಂದ actions ಗಳು ಆರೋಪಿಸಬಹುದಾಗಿಯೂ ರದ್ದುಗೊಳಿಸಬಹುದಾಗಿಯೂ ಇರುತ್ತವೆ.
- "Delegation ಅಂದರೆ ಎಲ್ಲವನ್ನೂ ಅಥವಾ ಏನನ್ನೂ ಅಲ್ಲ." ಅತ್ಯಂತ ಸುರಕ್ಷಿತ delegations ಗಳು ಸೀಮಿತವಾಗಿರುತ್ತವೆ: ಸಾಮಾನ್ಯವಾಗಿ ಓದಲು ಮಾತ್ರ ಪ್ರವೇಶ, ನಿರ್ದಿಷ್ಟ actions ಗಾಗಿ ಮಾತ್ರ ಬರೆಯುವ ಪ್ರವೇಶ, ಮತ್ತು ಹಿಂತಿರುಗಿಸಲಾಗದ ಯಾವುದಕ್ಕೂ ದೃಢೀಕರಣ.
Proof of Actor ಇದರೊಂದಿಗೆ ಹೇಗೆ ಸಂಬಂಧಿಸುತ್ತದೆ
Proof of Actor interaction agent-ಚಾಲಿತವೇ ಅಥವಾ AI ನೆರವಿನಿಂದದೋ, ಮತ್ತು ಯಾವ ಆಧಾರದ ಮೇಲೆ: verified, declared, inferred ಅಥವಾ unknown ಎಂಬುದನ್ನು ನೋಡಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಆ ಸಂದರ್ಭ delegation ಪ್ರಶ್ನೆಗಳು ಎಲ್ಲೆಲ್ಲಿ ಉದ್ಭವಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ತಿಳಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ human account session ಒಳಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ autonomous agent. Proof of Actor delegation credentials ಅನ್ನು ನೀಡುವುದಿಲ್ಲ ಅಥವಾ ಮಾನ್ಯಗೊಳಿಸುವುದಿಲ್ಲ, ಮತ್ತು Agent ಫಲಿತಾಂಶವು ಎಂದಿಗೂ ವ್ಯಕ್ತಿಯು action ಅನ್ನು ಅನುಮೋದಿಸಿದ್ದಾನೆ ಎಂದು ಸೂಚಿಸುವುದಿಲ್ಲ. ಅದು ನಿಮ್ಮ application ನ ಸ್ವಂತ grants, scopes ಮತ್ತು confirmations ಮೂಲಕ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ನಿಜವಾದ traffic ಅನ್ನು ನೀವು ಗಮನಿಸಿದ ಬಳಿಕ Route ನಿಮಗೆ ಪ್ರತಿ route ಗೆ ಸರಿಯಾದ policy ಅನ್ವಯಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ. policy patterns ಗಾಗಿ, ನೋಡಿ humans ಮತ್ತು AI agents ಗಾಗಿ app-level policies ವಿನ್ಯಾಸಗೊಳಿಸುವುದು.
evidence ಏನು ಸ್ಥಾಪಿಸಬಹುದು ಮತ್ತು ಏನು ಸ್ಥಾಪಿಸಲಾರದು ಎಂಬುದನ್ನು ಓದಿ, ಅಥವಾ early access ಗಾಗಿ ಅರ್ಜಿ ಸಲ್ಲಿಸಿ.
ಮೂಲಗಳು
- RFC 6749: The OAuth 2.0 Authorization Framework: resource owner ನಿಂದ client ಗೆ ಸೀಮಿತ grants
- RFC 7009: OAuth 2.0 Token Revocation: ಹಸ್ತಾಂತರಿತ token ಅನ್ನು ರದ್ದುಪಡಿಸುವುದು
- RFC 8693: OAuth 2.0 Token Exchange: delegation ಗಾಗಿ
act(actor) claim