Agent ਅਧਿਕਾਰਕਰਨ ਦਾ ਕੀ ਅਰਥ ਹੈ
Agent ਅਧਿਕਾਰਕਰਨ ਇਹ ਫੈਸਲਾ ਹੈ ਕਿ ਇੱਕ AI agent ਨੂੰ ਕੀ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ: ਉਹ ਕਿਹੜੇ routes ਨੂੰ call ਕਰ ਸਕਦਾ ਹੈ, ਕਿਹੜਾ data ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਕਿਹੜੀਆਂ actions ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕਿਸ volume 'ਤੇ। ਇਹ agent ਪਛਾਣ ਤੋਂ ਵੱਖਰਾ ਹੈ, ਜੋ ਇਹ ਸਥਾਪਿਤ ਕਰਨ ਨਾਲ ਸਬੰਧਤ ਹੈ ਕਿ request ਕਿਹੜਾ agent, ਜਾਂ ਕਿਸ operator ਦਾ agent, ਕਰ ਰਿਹਾ ਹੈ।
ਦੋਵੇਂ ਨੂੰ ਅਕਸਰ ਇਕੱਠੇ ਆਉਣ ਕਰਕੇ ਵੱਖ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਕ signed request ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਕਿਸਨੇ ਭੇਜਿਆ। ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕੀ ਉਸ ਭੇਜਣ ਵਾਲੇ ਨੂੰ account ਬਦਲਣ, order place ਕਰਨ ਜਾਂ data export ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। Identity evidence ਹੈ; authorization policy ਹੈ। signed AI agent requests ਕੀ ਸਾਬਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਕੀ ਨਹੀਂ ਬਾਰੇ ਸਾਡੀ post ਇਹ ਫ਼ਰਕ ਖੋਲ੍ਹ ਕੇ ਸਮਝਾਉਂਦੀ ਹੈ।
ਇਹ ਫ਼ਰਕ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
Applications ਪਹਿਲਾਂ ਹੀ human users ਲਈ authentication ਅਤੇ authorization ਨੂੰ ਵੱਖ ਕਰਦੀਆਂ ਹਨ: login ਕਰਨਾ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੌਣ ਹੋ, ਅਤੇ roles ਅਤੇ permissions ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹੋ। Agents ਨੂੰ ਵੀ ਇਹੀ separation ਚਾਹੀਦੀ ਹੈ, ਵਾਧੂ ਸਾਵਧਾਨੀ ਦੇ ਇੱਕ ਹੋਰ ਪੱਧਰ ਨਾਲ:
- Identity ਮਜ਼ਬੂਤ ਹੋ ਸਕਦੀ ਹੈ ਪਰ permission ਨਾ ਹੋਵੇ। ਇੱਕ crawler ਕੋਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੈਧ HTTP message signature ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਉਸਨੂੰ write endpoint call ਕਰਨ ਦਾ ਕੋਈ ਮੂਲ ਅਧਿਕਾਰ ਨਹੀਂ ਹੁੰਦਾ।
- Permission ਮਜ਼ਬੂਤ identity ਤੋਂ ਬਿਨਾਂ ਵੀ ਹੋ ਸਕਦੀ ਹੈ। ਇੱਕ agent ਜੋ customer ਦੀ API key ਵਰਤ ਰਿਹਾ ਹੈ, ਉਸ key ਦੁਆਰਾ authorized ਹੈ, ਭਾਵੇਂ ਕੁਝ ਵੀ ਇਹ ਨਾ ਦੱਸਦਾ ਹੋਵੇ ਕਿ ਕਿਹੜਾ agent software ਇਸਨੂੰ hold ਕਰ ਰਿਹਾ ਹੈ।
- Agent ਦੇ ਪਿੱਛੇ ਵਾਲਾ ਵਿਅਕਤੀ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ agent ਕਿਸੇ ਦੇ ਲਈ act ਕਰਦਾ ਹੈ, ਤਾਂ ਸਵਾਲ ਇਹ ਬਣਦਾ ਹੈ ਕਿ ਕੀ ਉਸ ਵਿਅਕਤੀ ਨੇ ਉਸਨੂੰ authority ਦਿੱਤੀ ਸੀ (ਦੇਖੋ delegated authority).
ਇਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਹੀ check ਵਿੱਚ ਮਿਲਾ ਦੇਣ ਨਾਲ ਦੋ failure modes ਬਣਦੇ ਹਨ: legitimate automation ਨੂੰ ਇਸ ਲਈ block ਕਰਨਾ ਕਿ ਉਸ ਕੋਲ human login ਨਹੀਂ ਹੈ, ਜਾਂ ਇੱਕ well-identified agent 'ਤੇ ਉਹ actions ਭਰੋਸੇ ਨਾਲ ਕਰਨ ਦੇਣਾ ਜੋ ਉਸਨੂੰ ਕਦੇ ਕਰਨੇ ਹੀ ਨਹੀਂ ਸਨ।
ਆਮ ਤੌਰ 'ਤੇ ਅਧਿਕਾਰਕਰਨ ਕਿਵੇਂ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ
ਜ਼ਿਆਦਾਤਰ applications agents ਨੂੰ ਉਹਨਾਂ ਤਰੀਕਿਆਂ ਨਾਲ authorize ਕਰਦੀਆਂ ਹਨ ਜੋ ਉਨ੍ਹਾਂ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹੁੰਦੇ ਹਨ:
- Credentials ਅਤੇ scopes। API keys ਜਾਂ OAuth 2.0 tokens, ਜਿਨ੍ਹਾਂ ਦੇ scopes integration ਦੀ ਲੋੜ ਤੱਕ ਸੀਮਿਤ ਹੁੰਦੇ ਹਨ। MCP servers ਇਹੀ model ਵਰਤਦੇ ਹਨ: MCP authorization specification ਇੱਕ protected server ਨੂੰ OAuth 2.1 resource server ਵਜੋਂ treat ਕਰਦੀ ਹੈ।
- Route-level policy। Known agents ਲਈ read-only routes ਖੁੱਲ੍ਹੇ; write routes ਲਈ account ਨਾਲ ਜੁੜੀ credential ਦੀ ਲੋੜ।
- Risk tiers। ਘੱਟ ਪ੍ਰਭਾਵ ਵਾਲੀਆਂ actions ਵਿਆਪਕ ਤੌਰ 'ਤੇ allowed, ਉੱਚ ਪ੍ਰਭਾਵ ਵਾਲੀਆਂ actions ਲਈ ਮਜ਼ਬੂਤ credentials, confirmation ਜਾਂ review ਦੀ ਲੋੜ।
- Rate limits ਅਤੇ quotas ਪ੍ਰਤੀ operator, ਪ੍ਰਤੀ credential ਜਾਂ ਪ੍ਰਤੀ route।
Agent identity evidence ਇਹਨਾਂ ਫੈਸਲਿਆਂ ਵਿੱਚ ਇੱਕ input ਵਜੋਂ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਇੱਕ worked approach ਲਈ, humans ਅਤੇ AI agents ਲਈ app-level policies design ਕਰਨਾ ਵੇਖੋ। ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ verified operator ਨੂੰ ਇੱਕ anonymous client ਤੋਂ ਵੱਖ ਤਰੀਕੇ ਨਾਲ treat ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਪਰ permission ਫਿਰ ਵੀ ਤੁਹਾਡੀ policy ਤੋਂ ਹੀ ਆਉਂਦੀ ਹੈ।
ਆਮ ਗਲਤਫ਼ਹਿਮੀਆਂ
- "Verified agent means allowed." Verification request ਨੂੰ attribute ਕਰਦੀ ਹੈ। ਤੁਹਾਡੀ policy ਫਿਰ ਵੀ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ ਉਹ attributed party ਕੀ ਕਰ ਸਕਦੀ ਹੈ।
- "Agents ਨੂੰ block ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਦ ਤੱਕ human ਸਾਬਤ ਨਾ ਹੋਵੇ." ਬਹੁਤ ਸਾਰੇ agents legitimate participants ਹਨ। ਵਧੀਆ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਹਰ ਕਿਸਮ ਦਾ actor route by route ਕੀ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।
- "Authorization behavior ਤੋਂ infer ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ." Behavior ਇਹ confidence ਵਧਾ ਜਾਂ ਘਟਾ ਸਕਦਾ ਹੈ ਕਿ ਮੌਜੂਦ actor ਕਿਸ ਕਿਸਮ ਦਾ ਹੈ। ਇਸਨੂੰ ਆਪਣੇ ਆਪ permission ਨਹੀਂ ਦੇਣੀ ਚਾਹੀਦੀ।
Proof of Actor ਇਸਨੂੰ ਕਿਵੇਂ treat ਕਰਦਾ ਹੈ
Proof of Actor evidence ਦੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕਿਹੜਾ actor ਮੌਜੂਦ ਹੈ, ਕਿਸ basis 'ਤੇ (verified, declared, inferred ਜਾਂ unknown), ਅਤੇ ਕੀ ਜਾਣਿਆ ਗਿਆ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ। ਇਹ ਜਾਣਬੁੱਝ ਕੇ permission ਦਾ ਫੈਸਲਾ ਨਹੀਂ ਕਰਦਾ। ਇੱਕ Agent result, ਭਾਵੇਂ verified ਹੀ ਕਿਉਂ ਨਾ ਹੋਵੇ, ਕਦੇ ਵੀ authorization imply ਨਹੀਂ ਕਰਦਾ। Route ਵਿੱਚ, ਤੁਹਾਡੀ application actor result ਨੂੰ ਆਪਣੇ credentials, scopes ਅਤੇ risk tiers ਨਾਲ ਜੋੜਦੀ ਹੈ ਤਾਂ ਜੋ ਹਰ interaction ਨੂੰ allow, adapt, challenge, review ਜਾਂ limit ਕੀਤਾ ਜਾ ਸਕੇ, observation mode ਤੋਂ ਸ਼ੁਰੂ ਕਰਦਿਆਂ ਤਾਂ ਜੋ ਤੁਸੀਂ ਕੁਝ enforce ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ outcomes check ਕਰ ਸਕੋ।
decisions ਤੁਹਾਡੇ app ਵਿੱਚ ਕਿਵੇਂ fit ਹੁੰਦੇ ਹਨ ਬਾਰੇ ਹੋਰ ਜਾਣੋ, APIs ਅਤੇ MCP servers use cases ਵੇਖੋ, ਜਾਂ early access ਲਈ apply ਕਰੋ.
ਸ੍ਰੋਤ
- RFC 6749: The OAuth 2.0 Authorization Framework: clients ਲਈ scoped tokens
- MCP specification 2026-07-28: Authorization: MCP servers ਲਈ OAuth-based authorization
- RFC 9421: HTTP Message Signatures: ਇੱਕ signed request ਕੀ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ