ਨਵਾਂ ਖੋਜ ਦੱਸਦੀ ਹੈ ਕਿ Model Context Protocol (MCP)—ਉਹ ਇੰਟਰਫੇਸ ਜੋ large-language-model (LLM) agents ਨੂੰ ਬਾਹਰੀ ਟੂਲਸ (tools) ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ—"tool-poisoning" ਹਮਲਿਆਂ ਰਾਹੀਂ ਹਾਈਜੈਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜੋ ਇੱਕ ਤਿਹਾਈ ਤੋਂ ਵੱਧ ਸਮੇਂ ਵਿੱਚ ਸਫਲ ਹੁੰਦੇ ਹਨ। 20 ਪ੍ਰਸਿੱਧ agents ਵਿੱਚ ਔਸਤ ਸਫਲਤਾ ਦਰ 36.5% ਸੀ; o1-mini ਮਾਡਲ 72.8% ਕੋਸ਼ਿਸ਼ਾਂ ਵਿੱਚ ਫਸ ਗਿਆ, ਜਦੋਂ ਕਿ Claude-3.7-Sonnet ਨੇ 3% ਤੋਂ ਵੀ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਮਾੜੇ (malicious) ਕਾਲਾਂ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ। ਜੋ ਕੋਈ ਵੀ MCP 'ਤੇ ਨਿਰਭਰ LLM agents ਨੂੰ ਤੈਅ (deploy) ਕਰ ਰਿਹਾ ਹੈ, ਉਸ ਲਈ ਇਹ ਖੋਜ ਇੱਕ ਸਹੂਲਤ ਵਾਲੇ ਫੀਚਰ ਨੂੰ ਸਪਲਾਈ-ਚੇਨ ਜੋਖਮ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ ਜਿਸਦਾ ਕੋਈ ਵੀ ਕੋਡ ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਇਸਦਾ ਫਾਇਦਾ ਉਠਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
ਅੱਜ ਦੇ ਡਿਵੈਲਪਰਾਂ ਲਈ MCP ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
MCP ਇਸ ਗੱਲ ਨੂੰ ਮਿਆਰੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ agents ਕਿਵੇਂ ਫਾਈਲ ਰੀਡਰਸ (file readers), web APIs, ਜਾਂ ਈਮੇਲ ਭੇਜਣ ਵਾਲੇ (email senders) ਵਰਗੇ ਟੂਲਸ ਨੂੰ ਲੱਭਦੇ, ਰਜਿਸਟਰ ਕਰਦੇ ਅਤੇ ਵਰਤਦੇ ਹਨ। ਇੱਕ ਟੂਲ ਦਾ ਨਾਮ, input schema ਅਤੇ ਇੱਕ ਸੰਖੇਪ ਵੇਰਵਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਕੇ, ਇੱਕ ਸਰਵਰ ਉਸ ਕਾਬਲੀਅਤ ਨੂੰ ਕਿਸੇ ਵੀ ਕਲਾਇੰਟ ਲਈ ਉਪਲਬਧ ਕਰਵਾਉਂਦਾ ਹੈ ਜੋ ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਸਮਝਦਾ ਹੈ। ਇਸ ਦਾ ਵਾਅਦਾ ਸਰਲ ਹੈ: ਇੱਕ agent ਹਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ (integration) ਨੂੰ ਹਾਰਡ-ਕੋਡ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਟੂਲ ਲੱਭ ਸਕਦਾ ਹੈ, ਬੇਨਤੀ ਭੇਜ ਸਕਦਾ ਹੈ, ਅਤੇ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ।
ਉਹ ਲਚਕਤਾ ਇੱਕ ਅਸਪਸ਼ਟ ਵਿਸ਼ਵਾਸ ਸਬੰਧ ਵੀ ਬਣਾਉਂਦੀ ਹੈ। ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਕਲਾਇੰਟਸ ਨੂੰ ਕਹਿੰਦੀ ਹੈ ਕਿ ਟੂਲ ਦੇ ਵੇਰਵਿਆਂ ਨੂੰ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਭਰੋਸੇਯੋਗ ਮੰਨਿਆ ਜਾਵੇ ਜੇਕਰ ਉਹ ਅਜਿਹੇ ਸਰਵਰ ਤੋਂ ਆਉਂਦੇ ਹਨ ਜਿਸ 'ਤੇ ਕਲਾਇੰਟ ਪਹਿਲਾਂ ਹੀ ਭਰੋਸਾ ਕਰਦਾ ਹੈ। ਨਵੀਂ ਖੋਜ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਇਸ ਭਰੋਸੇ ਦੀ ਦੁਰਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।
Tool-poisoning ਆਮ prompt injection ਤੋਂ ਕਿਵੇਂ ਵੱਖਰਾ ਹੈ
ਰਵਾਇਤੀ prompt injection ਉਸ ਟੈਕਸਟ ਵਿੱਚ ਮਾੜੇ ਨਿਰਦੇਸ਼ ਪਾ ਦਿੰਦਾ ਹੈ ਜੋ ਮਾਡਲ runtime ਦੌਰਾਨ ਬਣਾਉਂਦਾ ਹੈ ਜਾਂ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ। ਫਿਰ ਮਾਡਲ ਉਹਨਾਂ ਨਿਰਦੇਸ਼ਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਉਪਭੋਗਤਾ ਦੀ ਬੇਨਤੀ ਦੇ ਸਮਾਨ ਟੋਕਨ ਸਟ੍ਰੀਮ (token stream) ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ।
ਇਸਦੇ ਉਲਟ, tool-poisoning ਪੇਲੋਡ (payload) ਨੂੰ ਟੂਲ ਦੇ metadata—ਨਾਮ, ਵੇਰਵਾ, ਜਾਂ ਪੈਰਾਮੀਟਰ schema ਵਿੱਚ ਲੁਕਾ ਦਿੰਦਾ ਹੈ ਜੋ ਕਿਸੇ ਵੀ agent ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ ਰਜਿਸਟਰ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ agent ਬਾਅਦ ਵਿੱਚ ਟੂਲ ਦੀ ਚੋਣ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਵੇਰਵੇ ਨੂੰ "ਭਰੋਸੇਯੋਗ ਸੰਦਰਭ" (trusted context) ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਮੰਨਦਾ ਹੈ ਅਤੇ ਬਿਨਾਂ ਕਿਸੇ runtime ਚੈੱਕ ਦੇ ਲੁਕੇ ਹੋਏ ਨਿਰਦੇਸ਼ ਦੀ ਪਾਲਣਾ ਕਰ ਸਕਦਾ ਹੈ। ਕਿਉਂਕਿ ਇੰਜੈਕਸ਼ਨ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਦੌਰਾਨ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਫਲੋਅ ਵਿੱਚ ਅਜਿਹਾ ਕੋਈ ਮੋੜ ਨਹੀਂ ਹੁੰਦਾ ਜਿੱਥੇ ਮਾਡਲ ਪੇਲੋਡ ਨੂੰ ਸ਼ੱਕੀ ਵਜੋਂ ਫਲੈਗ ਕਰ ਸਕੇ।
ਸਮੱਸਿਆ ਦਾ ਪੈਮਾਨਾ – MCPTox benchmark
MCPTox (arXiv:2508.14925) ਦੇ ਪਿੱਛੇ ਖੋਜਕਰਤਾਵਾਂ ਨੇ ਕੁੱਲ 353 ਵੱਖ-ਵੱਖ ਟੂਲਸ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਨ ਵਾਲੇ 45 MCP ਸਰਵਰਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕੀਤਾ। ਉਹਨਾਂ ਨੇ 20 ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤੇ ਜਾਣ ਵਾਲੇ LLM agents ਵਿਰੁੱਧ ਹਮਲੇ ਤਿਆਰ ਕੀਤੇ, ਅਤੇ ਮਾਪਿਆ ਕਿ agents ਨੇ ਜ਼ਹਿਰੀਲੇ (poisoned) ਟੂਲ ਕਾਲ ਨੂੰ ਕਿੰਨੀ ਵਾਰ ਐਗਜ਼ੀਕਿਊਟ ਕੀਤਾ।
- ਔਸਤ ਸਫਲਤਾ ਦਰ: 36.5%
- ਚੋਟੀ ਦੀ ਸਫਲਤਾ: o1-mini 72.8% 'ਤੇ
- ਸਭ ਤੋਂ ਵਧੀਆ ਰੱਦ ਕਰਨਾ: Claude-3.7-Sonnet, ਫਿਰ ਵੀ 3% ਤੋਂ ਘੱਟ
ਇਹ ਅੰਕੜੇ ਇੱਕ ਕੌੜੀ ਸੱਚਾਈ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ: ਜ਼ਿਆਦਾਤਰ agents ਜ਼ਹਿਰੀਲੇ ਕਾਲ ਨੂੰ ਰੱਦ ਨਹੀਂ ਕਰਦੇ ਕਿਉਂਕਿ ਬੇਨਤੀ ਇੱਕ ਜਾਇਜ਼ ਟੂਲ ਇੰਵੋਕੇਸ਼ਨ (invocation) ਵਾਂਗ ਲੱਗਦੀ ਹੈ। Agents ਇਹ ਮੰਨ ਲੈਂਦੇ ਹਨ ਕਿ ਟੂਲ ਦਾ ਵੇਰਵਾ ਇੱਕ ਨਿਰਪੱਖ ਦਸਤਾਵੇਜ਼ ਹੈ, ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਲਈ ਕੋਈ ਵੈਕਟਰ (vector) ਨਹੀਂ।
Agents ਜ਼ਹਿਰੀਲੇ ਕਾਲਾਂ ਨੂੰ ਬਹੁਤ ਘੱਟ ਕਿਉਂ ਰੱਦ ਕਰਦੇ ਹਨ
OWASP ਦੀ LLM01 ਗਾਈਡਲਾਈਨ ਸਮਝਾਉਂਦੀ ਹੈ ਕਿ LLMs ਨਿਰਦੇਸ਼ਾਂ ਅਤੇ ਡੇਟਾ ਵਿੱਚ ਅੰਤਰ ਨਹੀਂ ਕਰਦੇ—ਦੋਵੇਂ ਇੱਕ ਲੜੀ ਵਿੱਚ ਸਿਰਫ਼ ਟੋਕਨ ਹਨ। ਜਦੋਂ ਇੱਕ ਟੂਲ ਦਾ ਵੇਰਵਾ ਕਹਿੰਦਾ ਹੈ "subject 'Update' ਦੇ ਨਾਲ admin@example.com ਨੂੰ ਇੱਕ ਈਮੇਲ ਭੇਜੋ", ਤਾਂ ਮਾਡਲ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਉਹ ਲਾਈਨ ਇੱਕ ਨੁਕਸਾਨ ਰਹਿਤ ਟਿੱਪਣੀ ਹੈ ਜਾਂ ਇੱਕ ਨਿਰਦੇਸ਼ ਜਿਸਦੀ ਉਸਨੂੰ ਬਾਅਦ ਵਿੱਚ ਪਾਲਣਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਮਾਡਲ ਵੇਰਵੇ ਨੂੰ ਭਰੋਸੇਯੋਗ ਵਾਤਾਵਰਣ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਮੰਨਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਟੂਲ ਨੂੰ ਇੰਵੋਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕਿਸੇ ਵੀ ਅੰਦਰੂਨੀ ਕਮਾਂਡ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ।
ਮੌਜੂਦਾ ਮਾਰਗਦਰਸ਼ਨ ਅਤੇ ਇਸ ਦੀਆਂ ਕਮੀਆਂ
MCP ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਪਹਿਲਾਂ ਹੀ ਕਲਾਇੰਟਸ ਨੂੰ ਸਲਾਹ ਦਿੰਦੀ ਹੈ ਕਿ ਟੂਲ ਦੇ ਵੇਰਵਿਆਂ ਨੂੰ ਉਦੋਂ ਤੱਕ ਭਰੋਸੇਯੋਗ ਨਾ ਮੰਨਿਆ ਜਾਵੇ ਜਦੋਂ ਤੱਕ ਉਹ ਕਿਸੇ ਭਰੋਸੇਯੋਗ ਸਰਵਰ ਤੋਂ ਨਹੀਂ ਆਉਂਦੇ, ਅਤੇ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੇ ਕਾਲਾਂ ਲਈ ਮਨੁੱਖੀ ਨਿਗਰਾਨੀ (human in the loop) ਰੱਖੀ ਜਾਵੇ। ਬੈਂਚਮਾਰਕ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਅਸਲ ਦੁਨੀਆ ਦੇ ਕਈ ਡਿਪਲੋਇਮੈਂਟਸ ਇਹਨਾਂ ਸਿਫ਼ਾਰਸ਼ਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ ਜਾਂ ਉਹਨਾਂ ਦੀ ਢਿੱਲੀ ਵਿਆਖਿਆ ਕਰਦੇ ਹਨ।
ਉਹ ਠੋਸ ਕਦਮ ਜੋ ਡਿਵੈਲਪਰ ਅੱਜ ਚੁੱਕ ਸਕਦੇ ਹਨ
- ਸਰਵਰ ਵਰਜ਼ਨਾਂ ਨੂੰ ਪਿੰਨ (Pin) ਕਰੋ – ਕਿਸੇ ਬਦਲਦੇ ਹੋਏ ਟੈਗ ਦੀ ਬਜਾਏ ਇੱਕ ਖਾਸ, ਅਟੱਲ (immutable) ਸਰਵਰ ਇਮੇਜ ਜਾਂ ਹੈਸ਼ (hash) ਦਾ ਹਵਾਲਾ ਦਿਓ। ਇਹ ਡਿਪਲਾਈਮੈਂਟ ਤੋਂ ਬਾਅਦ ਕਿਸੇ ਹਮਲਾਵਰ ਨੂੰ ਸਾਫ਼ ਰਜਿਸਟਰੀ ਨੂੰ ਜ਼ਹਿਰੀਲੀ (poisoned) ਰਜਿਸਟਰੀ ਨਾਲ ਬਦਲਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
- ਖਾਲੀ allowlist ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰੋ – ਸਿਰਫ਼ ਉਹਨਾਂ ਟੂਲਜ਼ ਨੂੰ ਹੀ ਚਾਲੂ ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੀ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਜਾਂਚ ਕੀਤੀ ਗਈ ਹੋਵੇ। ਸੂਚੀ ਵਿੱਚ ਨਾ ਹੋਣ ਵਾਲੀ ਕੋਈ ਵੀ ਚੀਜ਼ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਰੋਕ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।
- ਸਟੇਟ-ਬਦਲਣ ਵਾਲੇ ਟੂਲਜ਼ 'ਤੇ ਰੋਕ ਲਗਾਓ – ਕਿਸੇ ਵੀ ਅਜਿਹੇ ਟੂਲ ਲਈ ਵਾਧੂ ਪ੍ਰਵਾਨਗੀ ਦੀ ਲੋੜ ਹੋਵੇ ਜੋ ਡੇਟਾ ਲਿਖਦਾ ਹੈ, ਭੇਜਦਾ ਹੈ, ਜਾਂ ਡਿਲੀਟ ਕਰਦਾ ਹੈ। ਸਕੀਮਾ ਵਿੱਚ "read-only" ਨੂੰ "write-capable" ਸਮਰੱਥਾਵਾਂ ਤੋਂ ਵੱਖ ਕਰੋ।
- ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੀਆਂ ਕਾਲਾਂ ਲਈ ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਜੋੜੋ – ਉਹਨਾਂ ਕਾਰਵਾਈਆਂ ਲਈ ਜੋ ਬਾਹਰੀ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ (ਜਿਵੇਂ ਕਿ ਈਮੇਲ ਭੇਜਣਾ, ਕਮਾਂਡਾਂ ਚਲਾਉਣਾ, ਫਾਈਲਾਂ ਨੂੰ ਸੋਧਣਾ), ਕਾਲ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਮਨੁੱਖੀ ਰਿਵਿਊਅਰ (reviewer) ਨੂੰ ਪੁੱਛੋ।
- ਹਰ ਟੂਲ ਦੀ ਵਰਤੋਂ (invocation) ਨੂੰ ਲੌਗ ਕਰੋ – ਟੂਲ ਦਾ ਨਾਮ, ਆਰਗੂਮੈਂਟਸ, ਟਾਈਮਸਟੈਂਪ, ਅਤੇ ਸ਼ੁਰੂਆਤ ਕਰਨ ਵਾਲੇ ਏਜੰਟ ਨੂੰ ਰਿਕਾਰਡ ਕਰੋ। ਇੱਕ ਅਟੱਲ ਆਡਿਟ ਟ੍ਰੇਲ (audit trail) ਮੌਤ-ਉਪਰੰਤ ਵਿਸ਼ਲੇਸ਼ਣ (post-mortem analysis) ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਹਮਲਾਵਰਾਂ ਨੂੰ ਰੋਕ ਸਕਦੀ ਹੈ ਜੋ ਜਾਣਦੇ ਹਨ ਕਿ ਉਹਨਾਂ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਦਿਖਾਈ ਦੇਣਗੀਆਂ।
ਹਰ ਟੂਲ ਦੇ ਵੇਰਵੇ ਨੂੰ ਸੋਰਸ ਕੋਡ ਵਾਂਗ ਮੰਨੋ—ਜੋ ਕਿ ਲਿੰਟਿੰਗ (linting), ਕੋਡ ਰਿਵਿਊ, ਅਤੇ ਵਰਜ਼ਨ ਕੰਟਰੋਲ ਦੇ ਅਧੀਨ ਹੋਵੇ—ਤਾਂ ਜੋ MCP ਸਪਲਾਈ ਚੇਨ ਨੂੰ ਮਿਆਰੀ ਸਾਫਟਵੇਅਰ-ਡਿਵੈਲਪਮੈਂਟ ਅਭਿਆਸਾਂ ਨਾਲ ਜੋੜਿਆ ਜਾ ਸਕੇ।
ਵਿਰੋਧੀ ਦਲੀਲਾਂ ਅਤੇ ਖੁੱਲ੍ਹੇ ਸਵਾਲ
ਹਾਲਾਂਕਿ, ਬੈਂਚਮਾਰਕ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਅਧਿਐਨ ਵਿੱਚ ਸਭ ਤੋਂ ਉੱਨਤ ਮਾਡਲ ਨੇ ਵੀ ਤਿੰਨ ਪ੍ਰਤੀਸ਼ਤ ਤੋਂ ਘੱਟ ਜ਼ਹਿਰੀਲੀਆਂ (poisoned) ਕਾਲਾਂ ਨੂੰ ਰੱਦ ਕੀਤਾ। ਫਾਈਨ-ਟਿਊਨਿੰਗ (Fine-tuning) ਡਿਟੈਕਸ਼ਨ ਵਿੱਚ ਸੁਧਾਰ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਸਕੀਮਾ ਫੀਲਡਾਂ ਵਿੱਚ ਇਨਬੈਡ ਕੀਤੇ ਨਵੇਂ ਪੇਲੋਡਸ (payloads) ਦੇ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦੇ ਸਕਦੀ ਜੋ ਮਾਡਲ ਨੇ ਪਹਿਲਾਂ ਕਦੇ ਨਹੀਂ ਦੇਖੇ।
ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ
- ਉੱਭਰਦੇ ਮਿਆਰ – ਟੂਲ ਸਕੀਮਾ 'ਤੇ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਸਿਗਨੇਚਰਾਂ ਦੀ ਮੰਗ ਕਰਨ ਲਈ LLM ਸੁਰੱਖਿਆ ਭਾਈਚਾਰੇ ਦੇ ਪ੍ਰਸਤਾਵਾਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ।
- ਟੂਲ-ਰਜਿਸਟਰੀ ਹਾਰਡਨਿੰਗ – ਵੈਂਡਰ ਇੱਕ ਸੇਵਾ ਵਜੋਂ ਅਟੱਲ, ਰੀਡ-ਓਨਲੀ ਰਜਿਸਟਰੀਆਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਹਮਲੇ ਦੀ ਸਤ੍ਹਾ (attack surface) ਘਟ ਜਾਵੇਗੀ।
- ਮਾਡਲ-ਪੱਧਰ ਦੀਆਂ ਰੱਖਿਆਵਾਂ – ਪ੍ਰੌਮਪਟਿੰਗ ਤਕਨੀਕਾਂ ਜਾਂ ਸਹਾਇਕ ਮਾਡਲਾਂ ਵਿੱਚ ਖੋਜ ਜੋ ਸ਼ੱਕੀ ਟੂਲ ਮੈਟਾਡਾਟਾ ਨੂੰ ਫਲੈਗ ਕਰਦੇ ਹਨ, ਹੋਸਟ-ਸਾਈਡ ਸੁਰੱਖਿਆਵਾਂ ਦੇ ਪੂਰਕ ਹੋ ਸਕਦੇ ਹਨ।
ਵਿਵਹਾਰਕ ਸਿੱਖਿਆ ਸਪੱਸ਼ਟ ਹੈ: ਕਿਸੇ ਵੀ MCP-ਅਧਾਰਤ ਡਿਪਲਾਈਮੈਂਟ ਨੂੰ ਟੂਲ ਵੇਰਵਿਆਂ ਦੀ ਜਾਂਚ ਉਨੀ ਹੀ ਸਖ਼ਤੀ ਨਾਲ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜਿੰਨੀ ਤੀਜੀ-ਪਾਰਟੀ ਲਾਇਬ੍ਰੇਰੀਆਂ 'ਤੇ ਲਾਗੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਸਪਲਾਈ-ਚੇਨ ਜੋਖਮ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਇੱਕ ਸੁਵਿਧਾਜਨਕ ਅਬਸਟਰੈਕਸ਼ਨ (abstraction) ਨੂੰ ਇੱਕ ਚੁੱਪ ਬੈਕਡੋਰ (backdoor) ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਸਰਵਰਾਂ ਨੂੰ ਪਿੰਨ ਕਰਕੇ, ਘੱਟਤਮ ਮਨਜ਼ੂਰੀ ਵਾਲੀਆਂ (least-privilege) allowlists ਨੂੰ ਲਾਗੂ ਕਰਕੇ, ਸਟੇਟ-ਬਦਲਣ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ 'ਤੇ ਰੋਕ ਲਗਾ ਕੇ, ਲੋੜ ਪੈਣ 'ਤੇ ਮਨੁੱਖਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਕੇ, ਅਤੇ ਇੱਕ ਅਟੱਲ ਲੌਗ ਰੱਖ ਕੇ, ਡਿਵੈਲਪਰ ਆਪਣੇ LLM ਏਜੰਟਾਂ ਨੂੰ ਅਣਚਾਹੇ ਸਾਥੀਆਂ ਬਣਨ ਤੋਂ ਰੋਕ ਸਕਦੇ ਹਨ।