Chrome ਨੇ WebMCP ਲਈ ਸੁਰੱਖਿਆ ਮਾਰਗਦਰਸ਼ਨ (security guidance) ਜੋੜਿਆ ਹੈ, ਜੋ ਕਿ ਵੈੱਬਸਾਈਟਾਂ ਦੁਆਰਾ AI agents ਨੂੰ ਟੂਲ ਦਿਖਾਉਣ ਦਾ ਇੱਕ ਨਵਾਂ ਤਰੀਕਾ ਹੈ, ਅਤੇ ਇਹ ਉਹਨਾਂ ਟੂਲਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਵੈੱਬਸਾਈਟ ਮਾਲਕਾਂ 'ਤੇ ਪਾਉਂਦਾ ਹੈ। ਮਾਰਗਦਰਸ਼ਨ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ ਕਿ ਕੋਈ ਵੀ ਸਾਈਟ ਜੋ ਆਪਣੇ ਆਪ ਨੂੰ “agent-ready” ਘੋਸ਼ਿਤ ਕਰਦੀ ਹੈ, ਉਹ ਬਣੇ ਹੋਏ manifests ਜਾਂ ਦੂਸ਼ਿਤ ਆਊਟਪੁੱਟ (tainted output) ਰਾਹੀਂ agents ਨੂੰ ਹਾਈਜੈਕ ਕਰਨ ਲਈ ਮਾੜੇ ਇਰਾਦੇ ਵਾਲੇ ਲੋਕਾਂ (malicious actors) ਲਈ ਇੱਕ ਰਸਤਾ ਵੀ ਖੋਲ੍ਹ ਦਿੰਦੀ ਹੈ।

WebMCP ਹੁਣ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

ਡਿਵੈਲਪਰਾਂ ਨੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਪੁੱਛਿਆ ਹੈ: ਕੀ ਇੱਕ AI agent ਮੇਰੇ ਪੇਜ ਨੂੰ ਪੜ੍ਹ ਸਕਦਾ ਹੈ ਅਤੇ ਲੈਣ-ਦੇਣ (transaction) ਪੂਰਾ ਕਰ ਸਕਦਾ ਹੈ? WebMCP ਇਸ ਸਥਿਤੀ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਇੱਕ agent ਦੁਆਰਾ checkout ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਇਸਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਬਜਾਏ, ਸਾਈਟ ਇੱਕ manifest ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੀ ਹੈ ਜੋ agent ਨੂੰ ਸਹੀ ਤੌਰ 'ਤੇ ਦੱਸਦੀ ਹੈ ਕਿ ਉਹ ਕਿਹੜੇ ਕਾਰਜ ਕਰ ਸਕਦਾ ਹੈ—ਜਿਵੇਂ ਕਿ ਕੀਮਤ ਦੀ ਜਾਂਚ, ਕਾਰਟ ਅੱਪਡੇਟ, ਰਿਵਿਊ ਪ੍ਰਾਪਤ ਕਰਨਾ, ਅਤੇ ਹੋਰ ਬਹੁਤ ਕੁਝ। ਨਤੀਜਾ ਇੱਕ ਬਹੁਤ ਹੀ ਸਮਰੱਥ ਸਹਾਇਕ (assistant) ਵਜੋਂ ਨਿਕਲਦਾ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਨਵਾਂ attack surface ਵੀ ਬਣਦਾ ਹੈ: ਜਿਸ ਪਲ ਇੱਕ ਸਾਈਟ agent ਨੂੰ ਇੱਕ ਟੂਲ ਸੌਂਪਦੀ ਹੈ, ਉਹ agent ਨੂੰ ਹਦਾਇਤਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਸੌਂਪ ਦਿੰਦੀ ਹੈ ਜਿਸ ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਉਹ ਦੋ ਹਾਈਜੈਕ ਵੈਕਟਰ (hijack vectors) ਜਿਨ੍ਹਾਂ ਤੋਂ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਡਰਨਾ ਚਾਹੀਦਾ ਹੈ

Malicious manifests – ਇੱਕ ਹਮਲਾਵਰ ਟੂਲ ਦੇ ਨਾਮਾਂ ਜਾਂ ਵੇਰਣਾਂ ਵਿੱਚ ਲੁਕੀਆਂ ਹੋਈਆਂ ਹਦਾਇਤਾਂ (commands) ਪਾ ਦਿੰਦਾ ਹੈ। ਕਿਉਂਕਿ agents ਟੈਕਸਟ ਦੀ ਹਰ ਲਾਈਨ ਨੂੰ ਸੰਭਾਵੀ ਹਦਾਇਤ ਵਜੋਂ ਮੰਨਦੇ ਹਨ, ਇੱਕ ਚਲਾਕੀ ਨਾਲ ਬਣਾਇਆ ਗਿਆ ਨਾਮ agent ਦੇ ਅਸਲ ਕੰਮ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ ਅਤੇ ਉਸਨੂੰ ਕੁਝ ਅਣਚਾਹਿਆ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰ ਸਕਦਾ ਹੈ।

Contaminated output – ਇਹ ਵਧੇਰੇ ਆਮ ਰਸਤਾ ਹੈ। ਇੱਕ ਜਾਇਜ਼ ਟੂਲ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਡਾਟਾ ਵਾਪਸ ਕਰਦਾ ਹੈ—ਜਿਵੇਂ ਕਿ ਉਤਪਾਦ ਰਿਵਿਊ, ਫੋਰਮ ਪੋਸਟਾਂ, ਕੁਮੈਂਟਸ। ਜੇਕਰ ਕੋਈ ਮਾੜਾ ਵਿਅਕਤੀ ਉਸ ਸਮੱਗਰੀ ਵਿੱਚ ਕੋਈ ਕਮਾਂਡ ਫਸਾ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਟੂਲ ਉਹ ਕਮਾਂਡ ਸਿੱਧੀ agent ਨੂੰ ਭੇਜ ਦਿੰਦਾ ਹੈ। Large language models (LLMs) ਡਾਟਾ ਅਤੇ ਹਦਾਇਤਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਵੱਖ ਨਹੀਂ ਕਰਦੇ; ਉਹ ਪੂਰੇ ਸਟ੍ਰੀਮ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਪ੍ਰੋਂਪਟ (prompt) ਵਜੋਂ ਦੇਖਦੇ ਹਨ।

ਆਪਣੇ manifest ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ ਵਿਵਹਾਰਕ ਕਦਮ

Chrome ਦਾ ਮਾਰਗਦਰਸ਼ਨ ਤਿੰਨ ਕੌਂਫਿਗਰੇਸ਼ਨ ਨਿਯਮਾਂ ਵਿੱਚ ਸਮੇਟਿਆ ਗਿਆ ਹੈ ਜੋ ਡਿਵੈਲਪਰ ਆਪਣੀਆਂ WebMCP manifest ਫਾਈਲਾਂ ਵਿੱਚ ਜੋੜ ਸਕਦੇ ਹਨ।

  • ਕੌਣ ਤੁਹਾਡੇ ਟੂਲਸ ਨੂੰ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ ਉਸ ਨੂੰ ਸੀਮਤ ਕਰੋ – ਭਰੋਸੇਯੋਗ agent ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ whitelist ਕਰਨ ਲਈ exposedTo ਨਿਯਮ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਉਦਾਹਰਣ ਵਜੋਂ, ਇੱਕ ਪੇਮੈਂਟ-ਪ੍ਰੋਸੈਸਿੰਗ ਟੂਲ ਵੈੱਬ 'ਤੇ ਹਰ AI agent ਨੂੰ ਦਿਖਾਈ ਨਹੀਂ ਦੇਣਾ ਚਾਹੀਦਾ। ਉਹਨਾਂ ਸਹੀ origins ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜੋ ਟੂਲ ਨੂੰ ਕਾਲ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਬਾਕੀ ਨੂੰ ਰੱਦ ਕਰ ਦਿਓ।

  • ਅਭਰੋਸੇਯੋਗ ਸਮੱਗਰੀ ਨੂੰ ਚਿੰਨ੍ਹਿਤ ਕਰੋ – ਕਿਸੇ ਵੀ ਅਜਿਹੇ ਟੂਲ ਵਿੱਚ untrustedContentHint ਫਲੈਗ ਜੋੜੋ ਜੋ ਅਜਿਹਾ ਡਾਟਾ ਵਾਪਸ ਕਰਦਾ ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਰਿਵਿਊ ਜਾਂ ਕੁਮੈਂਟਸ। ਇਹ agent ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ payload ਵਿੱਚ ਮਾੜੀਆਂ ਹਦਾਇਤਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਉਹ ਟੈਕਸਟ 'ਤੇ ਕਾਰਵਾਈ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਖ਼ਤ ਸੁਰੱਖਿਆ ਫਿਲਟਰ ਲਗਾਉਣ ਲਈ ਪ੍ਰੇਰਿਤ ਹੁੰਦਾ ਹੈ।

  • ਰੀਡ-ਓਨਲੀ (read-only) ਵਿਵਹਾਰ ਘੋਸ਼ਿਤ ਕਰੋ – readOnlyHint ਫਲੈਗ ਤੁਹਾਨੂੰ ਇਹ ਸੰਕੇਤ ਦੇਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਕਿ ਕੀ ਕੋਈ ਟੂਲ ਸਿਰਫ ਡਾਟਾ ਪੜ੍ਹਦਾ ਹੈ ਜਾਂ ਸਟੇਟ ਨੂੰ ਲਿਖ/ਬਦਲ ਵੀ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਟੂਲ read-only ਹੁੰਦਾ ਹੈ, ਤਾਂ agent ਵਾਧੂ ਉਪਭੋਗਤਾ ਪੁਸ਼ਟੀ ਤੋਂ ਬਿਨਾਂ ਅੱਗੇ ਵਧ ਸਕਦਾ ਹੈ; ਜਦੋਂ ਇਹ ਕੁਝ ਬਦਲ ਸਕਦਾ ਹੈ, ਤਾਂ agent ਨੂੰ ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਪੁੱਛਣਾ ਚਾਹੀਦਾ ਹੈ।

ਡਿਵੈਲਪਰ ਕਿਸ ਚੀਜ਼ ਦਾ ਵਿਰੋਧ ਕਰ ਸਕਦੇ ਹਨ

ਵਿਆਪਕ ਦਾਅਵੇ

ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ

ਨਿਚੋੜ

ਕਿਸੇ ਸਾਈਟ ਨੂੰ “agent-ready” ਬਣਾਉਣਾ ਹੁਣ ਸਿਰਫ ਦਿਖਾਈ ਦੇਣ (visibility) ਲਈ ਇੱਕ ਚੈੱਕਬਾਕਸ ਨਹੀਂ ਰਿਹਾ; ਇਹ ਸੁਰੱਖਿਆ ਲਈ ਇੱਕ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ। ਪਹੁੰਚ ਨੂੰ ਸੀਮਤ ਕਰਕੇ, ਅਭਰੋਸੇਯੋਗ ਆਊਟਪੁੱਟ ਨੂੰ ਫਲੈਗ ਕਰਕੇ, ਅਤੇ ਰੀਡ-ਓਨਲੀ ਟੂਲਸ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਚਿੰਨ੍ਹਿਤ ਕਰਕੇ, ਡਿਵੈਲਪਰ ਹਮਲਾਵਰਾਂ ਨੂੰ ਇੱਕ ਮਦਦਗਾਰ AI ਸਹਾਇਕ ਨੂੰ ਦੁਰਵਰਤੋਂ ਦੇ ਸਾਧਨ ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਰੋਕ ਸਕਦੇ ਹਨ। Manifest ਨੂੰ ਕਿਸੇ ਵੀ ਹੋਰ ਪਬਲਿਕ API ਵਾਂਗ ਸਮਝੋ: ਇਸਦਾ ਆਡਿਟ ਕਰੋ, ਇਸਦਾ ਵਰਜ਼ਨ ਬਣਾਓ, ਅਤੇ ਦੁਨੀਆ ਦੇ ਸਾਹਮਣੇ ਲਿਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰੋ।