ಪ್ರಮುಖ ವಿಷಯಕ್ಕೆ ಬಿಟ್ಟುಬಿಡಿ
ಗ್ಲಾಸರಿ

Agent authorization

Toshendra Sharma

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

ಯಾವ agent ಅಥವಾ operator ಎಂಬುದನ್ನು ಸ್ಥಾಪಿಸುವುದರಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ, AI agent ಗೆ application ನಲ್ಲಿ ಏನು ಮಾಡಲು ಅನುಮತಿ ಇದೆ ಎಂಬ ನಿರ್ಧಾರ.

Agent authorization ಎಂದರೇನು

Agent authorization ಎಂದರೆ AI agent ಏನು ಮಾಡಲು ಅನುಮತಿಸಲಾಗಿದೆ ಎಂಬ ನಿರ್ಧಾರ: ಅದು ಯಾವ routes ಅನ್ನು call ಮಾಡಬಹುದು, ಯಾವ data ಅನ್ನು read ಮಾಡಬಹುದು, ಯಾವ actions ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಮತ್ತು ಯಾವ ಪ್ರಮಾಣದಲ್ಲಿ. ಇದು agent identity ಯಿಂದ ವಿಭಿನ್ನವಾಗಿದೆ, ಏಕೆಂದರೆ agent identity ಎಂದರೆ ಯಾವ agent, ಅಥವಾ ಯಾವ operator ನ agent, request ಮಾಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ಸ್ಥಾಪಿಸುವುದು.

ಈ ಎರಡು ವಿಷಯಗಳು ಹೆಚ್ಚಾಗಿ ಒಟ್ಟಿಗೆ ಬರುತ್ತಿರುವುದರಿಂದ ಅವನ್ನು ಗೊಂದಲಪಡಿಸುವುದು ಸುಲಭ. Signed request ಯಾರಿಂದ ಬಂದಿದೆ ಎಂಬುದನ್ನು ನಿಮಗೆ ಹೇಳುತ್ತದೆ. ಆದರೆ ಆ sender ಗೆ account ಅನ್ನು change ಮಾಡಲು, order place ಮಾಡಲು ಅಥವಾ data export ಮಾಡಲು ಅನುಮತಿ ಇರಬೇಕೇ ಎಂಬುದನ್ನು ಅದು ಹೇಳುವುದಿಲ್ಲ. Identity ಎಂದರೆ evidence; authorization ಎಂದರೆ policy. ನಮ್ಮ signed AI agent requests ಏನು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ, ಮತ್ತು ಏನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ ಎಂಬ ಲೇಖನ ಈ ವ್ಯತ್ಯಾಸವನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಈ ವ್ಯತ್ಯಾಸ ಏಕೆ ಮಹತ್ವದ್ದು

Applications ಈಗಾಗಲೇ human users ಗಾಗಿ authentication ಮತ್ತು authorization ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತವೆ: login ಆಗುವುದರಿಂದ ನೀವು ಯಾರು ಎಂಬುದು ಸಾಬೀತಾಗುತ್ತದೆ, ಮತ್ತು roles ಮತ್ತು permissions ನೀವು ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. Agents ಗಳಿಗೂ ಇದೇ ರೀತಿಯ separation ಬೇಕು, ಆದರೆ ಹೆಚ್ಚುವರಿ ಎಚ್ಚರಿಕೆಯೊಂದಿಗೆ:

  • Identity strong ಆಗಿರಬಹುದು ಆದರೆ permission ಇರದೇ ಇರಬಹುದು. Perfectವಾಗಿ valid ಇರುವ HTTP message signature ಹೊಂದಿರುವ crawler ಗೆ write endpoint ಅನ್ನು call ಮಾಡಲು ಸ್ವಾಭಾವಿಕ ಹಕ್ಕಿಲ್ಲ.
  • Permission strong identity ಇಲ್ಲದೇ ಇರಬಹುದು. Customer ನ API key ಬಳಸುವ agent ಆ key ಮೂಲಕ authorized ಆಗಿರುತ್ತದೆ, ಆ key ಯನ್ನು ಯಾವ agent software ಹಿಡಿದಿದೆ ಎಂಬುದನ್ನು ಏನೂ ಗುರುತಿಸದಿದ್ದರೂ ಸಹ.
  • Agent ಹಿಂದೆ ಇರುವ ವ್ಯಕ್ತಿ ಮಹತ್ವದವನು. Agent ಯಾರಿಗೋ behalf ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿದಾಗ, ಆ ವ್ಯಕ್ತಿ ಅದಕ್ಕೆ authority ನೀಡಿದ್ದಾನೆಯೇ ಎಂಬ ಪ್ರಶ್ನೆ ಬರುತ್ತದೆ (delegated authority ನೋಡಿ).

ಇವುಗಳನ್ನು ಒಂದೇ check ಗೆ ಕುಗ್ಗಿಸಿದರೆ ಎರಡು ರೀತಿಯ failure ಬರುತ್ತದೆ: human login ಇಲ್ಲದ ಕಾರಣ legit automation ಅನ್ನು block ಮಾಡುವುದು, ಅಥವಾ ಚೆನ್ನಾಗಿ ಗುರುತಿಸಲ್ಪಟ್ಟ agent ಗೆ ಅದು ಮಾಡಲು ಉದ್ದೇಶಿಸಲ್ಪಟ್ಟಿರದ actions ಗಳಿಗೆ trust ನೀಡುವುದು.

Authorization ಸಾಮಾನ್ಯವಾಗಿ ಹೇಗೆ ವ್ಯಕ್ತವಾಗುತ್ತದೆ

ಬಹುತೇಕ applications ಈಗಾಗಲೇ ಇರುವ mechanisms ಮೂಲಕ agents ಗಳನ್ನು authorize ಮಾಡುತ್ತವೆ:

  • Credentials ಮತ್ತು scopes. API keys ಅಥವಾ OAuth 2.0 tokens, integration ಗೆ ಬೇಕಾದಷ್ಟರ ಮಟ್ಟಿಗೆ ಮಾತ್ರ scopes ಹೊಂದಿರುತ್ತವೆ. MCP servers ಕೂಡ ಇದೇ model ಬಳಸುತ್ತವೆ: MCP authorization specification protected server ಅನ್ನು OAuth 2.1 resource server ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ.
  • Route-level policy. Known agents ಗೆ open ಇರುವ read-only routes; account ಗೆ tied ಆಗಿರುವ credential ಬೇಕಾದ write routes.
  • Risk tiers. ಕಡಿಮೆ ಪರಿಣಾಮದ actions ಅನ್ನು ವ್ಯಾಪಕವಾಗಿ ಅನುಮತಿಸುವುದು, ಹೆಚ್ಚಿನ ಪರಿಣಾಮದ actions ಗೆ ಬಲವಾದ credentials, confirmation ಅಥವಾ review ಅಗತ್ಯವಾಗುವುದು.
  • Rate limits ಮತ್ತು quotas ಪ್ರತಿ operator, ಪ್ರತಿ credential ಅಥವಾ ಪ್ರತಿ route ಗೆ.

Agent identity evidence ಈ ನಿರ್ಧಾರಗಳಿಗೆ ಒಂದು input ಆಗಿ ಸೇರುತ್ತದೆ. ಕಾರ್ಯಗತವಾದ approach ಗಾಗಿ humans ಮತ್ತು AI agents ಗಾಗಿ app-level policies ವಿನ್ಯಾಸಗೊಳಿಸುವುದು ನೋಡಿ. ಇದು verified operator ಅನ್ನು anonymous client ಗಿಂತ ವಿಭಿನ್ನವಾಗಿ ಪರಿಗಣಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಆದರೆ permission ಸ್ವತಃ ಇನ್ನೂ ನಿಮ್ಮ policy ಯಿಂದಲೇ ಬರುತ್ತದೆ.

ಸಾಮಾನ್ಯ ತಪ್ಪು ಕಲ್ಪನೆಗಳು

  • "Verified agent ಎಂದರೆ allowed." Verification request ಅನ್ನು attribute ಮಾಡುತ್ತದೆ. ಆ attributed party ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಿಮ್ಮ policy ಇನ್ನೂ ನಿರ್ಧರಿಸುತ್ತದೆ.
  • "Proven human ಅಲ್ಲದಿದ್ದರೆ agents ಗಳನ್ನು block ಮಾಡಬೇಕು." ಅನೇಕ agents legitimate participants ಆಗಿರುತ್ತಾರೆ. ಉತ್ತಮ ಪ್ರಶ್ನೆ ಎಂದರೆ route by route ಪ್ರತಿ kind of actor ಗೆ ಏನು ಮಾಡಲು ಅನುಮತಿ ಇರಬೇಕು ಎಂಬುದು.
  • "Behavior ನಿಂದ authorization ಅನ್ನು infer ಮಾಡಬಹುದು." Behavior ಯಾವ kind of actor ಇದೆ ಎಂಬ confidence ಅನ್ನು ಹೆಚ್ಚಿಸಬಹುದು ಅಥವಾ ಕಡಿಮೆ ಮಾಡಬಹುದು. ಅದು ತಾನಾಗಿಯೇ permission ನೀಡಬಾರದು.

Proof of Actor ಇದನ್ನು ಹೇಗೆ ನೋಡುತ್ತದೆ

Proof of Actor evidence ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಯಾವ kind of actor ಇದೆ, ಯಾವ basis ಮೇಲೆ (verified, declared, inferred ಅಥವಾ unknown), ಮತ್ತು ಏನು known ಆಗಿದೆ ಮತ್ತು ಏನು known ಆಗಿಲ್ಲ. ಇದು deliberatively permission ನಿರ್ಧರಿಸುವುದಿಲ್ಲ. Agent result, verified ಆಗಿದ್ದರೂ ಸಹ, ಎಂದಿಗೂ authorization ಅನ್ನು imply ಮಾಡುವುದಿಲ್ಲ. Route ನಲ್ಲಿ, ನಿಮ್ಮ application actor result ಅನ್ನು ತನ್ನದೇ credentials, scopes ಮತ್ತು risk tiers ಜೊತೆಗೆ ಸೇರಿಸಿ ಪ್ರತಿ interaction ಅನ್ನು allow, adapt, challenge, review ಅಥವಾ limit ಮಾಡುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ enforcement ಗೆ ಮುನ್ನ ಫಲಿತಾಂಶಗಳನ್ನು ಪರಿಶೀಲಿಸಲು observation mode ನಿಂದ ಆರಂಭಿಸುತ್ತದೆ.

ನಿಮ್ಮ app ನಲ್ಲಿ decisions ಹೇಗೆ fit ಆಗುತ್ತವೆ ಎಂಬುದನ್ನು learn more, APIs ಮತ್ತು MCP servers use cases ನೋಡಿ, ಅಥವಾ early access ಗೆ apply ಮಾಡಿ.

Sources

ನಿಮ್ಮ own app ನಲ್ಲಿ actor intelligence ನೋಡಿ.

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

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