MCP ਨੇ ਇੱਕ ਸਥਿਰ “Enterprise-Managed Authorization” spec ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ ਹੈ; ਹੋਰ machine-to-machine identity drafts—ਜਿਸ ਵਿੱਚ ਇੱਕ OAuth client-credentials draft ਅਤੇ ਦੋ ਖੁੱਲ੍ਹੇ ਪ੍ਰਸਤਾਵ ਸ਼ਾਮਲ ਹਨ—ਅਜੇ ਵੀ ਅਧੂਰੇ ਹਨ। Model Context Protocol ਦੇ ਨਾਲ autonomous agents ਚਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵਾਲੇ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਲਈ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅੱਜ ਦਾ ਪ੍ਰੋਟੋਕੋਲ ਇੱਕ ਮਨੁੱਖੀ ਉਪਭੋਗਤਾ ਦੀ ਪਛਾਣ ਤਾਂ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਸਾਬਤ ਕਰਨ ਲਈ ਕੋਈ ਤਿਆਰ-ਵਰਤੋਂ ਵਾਲਾ ਤਰੀਕਾ ਨਹੀਂ ਦਿੰਦਾ ਕਿ ਇੱਕ unattended process ਉਹੀ ਹੈ ਜੋ ਉਹ ਦਾਅਵਾ ਕਰ ਰਹੀ ਹੈ।
ਰੋਡਮੈਪ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
Model Context Protocol (MCP) ਰੋਡਮੈਪ ਏਜੰਟ ਦੀ ਪਛਾਣ ਅਤੇ ਸੁਰੱਖਿਆ ਨੂੰ ਆਪਣੀਆਂ ਪ੍ਰਮੁੱਖ ਤਰਜੀਹਾਂ ਵਿੱਚ ਰੱਖਦਾ ਹੈ। ਚਾਰ ਚੀਜ਼ਾਂ ਜਾਰੀ ਕਰਨ ਲਈ ਤੈਅ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ: ਇੱਕ ਮਨੁੱਖ-ਕੇਂਦ੍ਰਿਤ browser flow, ਸੇਵਾਵਾਂ ਲਈ ਇੱਕ OAuth client-credentials flow, ਇੱਕ DPoP-ਅਧਾਰਤ token binding, ਅਤੇ ਇੱਕ workload-identity federation ਵਿਧੀ। ਸਿਰਫ਼ ਪਹਿਲੀ—Enterprise-Managed Authorization—ਹੀ ਸਥਿਰ ਸਥਿਤੀ ਤੱਕ ਪਹੁੰਚੀ ਹੈ।
ਸਥਿਰ spec ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ
Enterprise-Managed Authorization IT ਐਡਮਿਨਾਂ ਨੂੰ ਹਰ ਕਰਮਚਾਰੀ ਤੋਂ ਹਰ ਕਨੈਕਸ਼ਨ ਨੂੰ ਮਨਜ਼ੂਰੀ ਲੈਣ ਦੀ ਬਜਾਏ, ਇੱਕ ਸਿੰਗਲ ਕੰਸੋਲ ਤੋਂ ਸਰਵਰ ਐਕਸੈਸ ਦੇਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਇਹ flow ਇੱਕ browser redirect ਅਤੇ ਯੂਜ਼ਰ ਲੌਗਇਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਤਾਂ ਜੋ ਲੈਪਟਾਪ 'ਤੇ ਬੈਠਾ ਵਿਅਕਤੀ authenticate ਕਰ ਸਕੇ ਅਤੇ ਫਿਰ ਸਰਵਰ ਉਸ ਯੂਜ਼ਰ ਦੇ session 'ਤੇ ਭਰੋਸਾ ਕਰਦਾ ਹੈ।
ਸੀਮਾ ਸਪੱਸ਼ਟ ਹੈ: ਇਸ ਪ੍ਰਕਿਰਿਆ ਲਈ ਕੀਬੋਰਡ 'ਤੇ ਇੱਕ ਮਨੁੱਖ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕ agent ਜੋ ਰਾਤ ਭਰ ਚੱਲਦਾ ਹੈ, ਡੇਟਾ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ, ਜਾਂ alerts ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਉਸ ਕੋਲ ਲੌਗਇਨ ਬਟਨ 'ਤੇ ਕਲਿੱਕ ਕਰਨ ਲਈ ਕੋਈ ਨਹੀਂ ਹੁੰਦਾ। ਨਤੀਜੇ ਵਜੋਂ, ਕੋਈ ਵੀ deployment ਜੋ unattended agents 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਉਸ ਇਕਲੌਤੇ spec ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜੋ MCP ਵਰਤਮਾਨ ਵਿੱਚ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ।
ਡਰਾਫਟ ਵਿਕਲਪ ਅਤੇ ਉਹਨਾਂ ਦੇ ਨੁਕਸਾਨ
ਦੋ ਡਰਾਫਟ extensions ਦਾ ਉਦੇਸ਼ agents ਨੂੰ ਆਪਣੀ ਪਛਾਣ ਦੇਣਾ ਹੈ:
- SEP-1932 (DPoP) – tokens ਨੂੰ ਇੱਕ public-private key pair ਨਾਲ ਜੋੜਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਚੋਰੀ ਕੀਤੇ ਗਏ tokens ਬੇਕਾਰ ਹੋ ਜਾਂਦੇ ਹਨ।
- SEP-1933 (Workload Identity Federation) – agents ਨੂੰ cloud platforms ਵਿੱਚ ਪਹਿਲਾਂ ਤੋਂ provision ਕੀਤੀਆਂ ਪਛਾਣਾਂ ਨੂੰ ਅਪਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।
ਦੋਵੇਂ open pull requests ਵਜੋਂ ਮੌਜੂਦ ਹਨ; ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਅਧਿਕਾਰਤ spec ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸ ਦੌਰਾਨ, ਇਕਲੌਤਾ ਦੂਜਾ ਦਸਤਾਵੇਜ਼ੀ ਵਿਕਲਪ ਇੱਕ OAuth client-credentials flow ਹੈ ਜਿਸ ਲਈ pre-registered secrets ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਉਹਨਾਂ secrets ਨੂੰ ਉੱਥੇ ਸਟੋਰ ਕਰਨਾ ਜਿੱਥੇ ਇੱਕ agent ਉਹਨਾਂ ਨੂੰ ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਇੱਕ ਰਵਾਇਤੀ attack surface ਬਣਾਉਂਦਾ ਹੈ: ਜੇਕਰ secret ਲੀਕ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕੋਈ ਵੀ attacker agent ਦਾ ਰੂਪ ਧਾਰ ਸਕਦਾ ਹੈ।
ਅੱਜ ਦੇ production ਲਈ ਵਿਵਹਾਰਕ ਕਦਮ
ਕਿਉਂਕਿ ਪ੍ਰੋਟੋਕੋਲ ਅਜੇ ਤੱਕ ਇੱਕ native agent identity ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਟੀਮਾਂ ਪਛਾਣ ਪ੍ਰਬੰਧਨ (identity management) ਨੂੰ MCP ਤੋਂ ਬਾਹਰ ਲੈ ਕੇ ਅਜੇ ਵੀ agents ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰ ਸਕਦੀਆਂ ਹਨ:
- Workload layer 'ਤੇ verifiable identities ਜਾਰੀ ਕਰੋ। SPIRE ਵਰਗੇ ਸਿਸਟਮ host ਦੇ trust root ਨਾਲ ਜੁੜੇ ਹੋਏ short-lived certificates ਤਿਆਰ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ static secrets ਖਤਮ ਹੋ ਜਾਂਦੇ ਹਨ।
- Gateway 'ਤੇ credentials ਨੂੰ ਸਮਾਪਤ ਕਰੋ। ਇੱਕ front-end service API key ਜਾਂ token ਨੂੰ ਰੱਖਦੀ ਹੈ ਅਤੇ agent ਦੀ ਤਰਫੋਂ requests ਨੂੰ ਅੱਗੇ ਭੇਜਦੀ ਹੈ, ਜਿਸ ਨਾਲ secret runtime environment ਤੋਂ ਬਾਹਰ ਰਹਿੰਦਾ ਹੈ।
- Verified identity ਦੇ ਅਧਾਰ 'ਤੇ authorize ਕਰੋ, ਨਾ ਕਿ token content ਦੇ ਅਧਾਰ 'ਤੇ। Authentication (ਕੌਣ ਕਾਲ ਕਰ ਰਿਹਾ ਹੈ) ਨੂੰ authorization (ਉਹ ਕੀ ਕਰ ਸਕਦੇ ਹਨ) ਤੋਂ ਵੱਖ ਕਰੋ ਤਾਂ ਜੋ ਜੇਕਰ authentication ਵਿਧੀ ਬਦਲ ਵੀ ਜਾਵੇ, ਤਾਂ ਵੀ policy ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕੇ।
ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ
ਦੋ open pull requests – DPoP binding ਅਤੇ workload-identity federation – MCP ਦੇ ਅੰਦਰ ਇੱਕ ਅਸਲੀ machine-to-machine identity standard ਤੱਕ ਪਹੁੰਚਣ ਦੇ ਇਕਲੌਤੇ ਰਸਤੇ ਹਨ। ਜੇਕਰ ਕਮਿਊਨਿਟੀ ਉਹਨਾਂ ਨੂੰ merge ਕਰ ਦਿੰਦੀ ਹੈ, ਤਾਂ agents secrets ਨੂੰ ਪ੍ਰਗਟ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ private key ਦੀ ਮਲਕੀਅਤ ਸਾਬਤ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਗੇ ਜਾਂ cloud-issued identities ਨੂੰ ਅਪਣਾਉਣ ਦੇ ਯੋਗ ਹੋਣਗੇ। ਉਦੋਂ ਤੱਕ, ਕਿਸੇ ਵੀ production deployment ਨੂੰ ਬਾਹਰੀ identity frameworks 'ਤੇ ਨਿਰਭਰ ਕਰਨਾ ਪਵੇਗਾ ਜਾਂ static credentials ਦੇ ਜੋਖਮ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਪਵੇਗਾ।
ਸਿੱਟਾ ਸਪੱਸ਼ਟ ਹੈ: MCP ਵਰਤਮਾਨ ਵਿੱਚ ਬੇਨਤੀ ਦੇ ਪਿੱਛੇ ਵਾਲੇ ਵਿਅਕਤੀ ਨੂੰ authenticate ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਅਜੇ ਤੱਕ ਬੇਨਤੀ ਕਰਨ ਵਾਲੇ software ਨੂੰ authenticate ਨਹੀਂ ਕਰਦਾ ਹੈ। ਜਿਨ੍ਹਾਂ ਟੀਮਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ autonomous agents ਦੀ ਲੋੜ ਹੈ, ਉਹਨਾਂ ਨੂੰ spec ਦੇ ਆਉਣ ਦੀ ਉਡੀਕ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ; ਉਹਨਾਂ ਨੂੰ ਅੱਜ ਹੀ workload layer 'ਤੇ identity ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਲੰਬਿਤ DPoP ਅਤੇ federation ਪ੍ਰਸਤਾਵਾਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ।