ਮੈਂ ਇੱਕ AI ਏਜੰਟ ਨੂੰ ਆਪਣੇ ਪਰਿਵਾਰ ਦੇ ਵਿੱਤੀ ਲੈਣ-ਦੇਣ ਤੱਕ ਪਹੁੰਚ ਦਿੱਤੀ ਅਤੇ ਉਸਨੂੰ ਇੱਕ MCP ਸਰਵਰ ਰਾਹੀਂ ਮੇਰੇ ਨਾਲ ਗੱਲ ਕਰਨ ਦਿੱਤੀ। ਕੁਝ ਹੀ ਮਿੰਟਾਂ ਵਿੱਚ ਉਹ ਜਵਾਬ ਦੇ ਸਕਦਾ ਸੀ ਕਿ "ਪਿਛਲੇ ਮਹੀਨੇ ਅਸੀਂ ਕਰਿਆਨਾ (groceries) 'ਤੇ ਕਿੰਨਾ ਖਰਚ ਕੀਤਾ ਸੀ?" ਅਤੇ ਬਚਤ ਵਿੱਚ ਪੈਸੇ ਵੀ ਭੇਜ ਸਕਦਾ ਸੀ। ਉਸੇ ਇੰਟਰਫੇਸ ਨੇ ਉਸਨੂੰ ਇੱਕ ਸਿੰਗਲ ਕਮਾਂਡ ਨਾਲ ਲੈਣ-ਦੇਣ ਦੇ ਪੂਰੇ ਇੱਕ ਸਾਲ ਦੇ ਇਤਿਹਾਸ ਨੂੰ ਮਿਟਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਵੀ ਦਿੱਤੀ। ਏਜੰਟ ਦੁਆਰਾ ਕਾਲ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਟੂਲਜ਼ ਵਿੱਚ ਇੱਕ ਹਾਰਡ-ਕੋਡਡ ਸੁਰੱਖਿਆ ਚੈੱਕ (safety check) ਨੇ ਇਸ ਡਿਲੀਸ਼ਨ ਨੂੰ ਰੋਕ ਦਿੱਤਾ—ਕੋਈ ਚਲਾਕ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਨਹੀਂ।
ਇਹ ਸਮੱਸਿਆ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
AI ਏਜੰਟ ਜੋ ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਉਹ ਰਿਸਰਚ ਡੈਮੋਸ ਤੋਂ ਹੁੰਦਿਆਂ ਰੋਜ਼ਾਨਾ ਦੇ ਸਹਾਇਕਾਂ (assistants) ਵਿੱਚ ਬਦਲ ਰਹੇ ਹਨ। ਇੱਕ ਬਜਟਿੰਗ ਬੋਟ ਜੋ ਬੈਂਕ-SMS ਅਲਰਟਾਂ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ, ਰਕਮਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਪਰਸਨਲ ਫਾਈਨੈਂਸ ਐਪ ਵਿੱਚ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ, ਅੱਜ ਮੌਜੂਦ ਹੈ। ਇਹੀ ਪੈਟਰਨ ਕਸਟਮਰ-ਸਪੋਰਟ ਚੈਟਬੋਟਸ, ਕੋਡ-ਜਨਰੇਸ਼ਨ ਹੈਲਪਰਸ, ਅਤੇ ਸਪਲਾਈ-ਚੇਨ ਪਲਾਨਰਸ ਨੂੰ ਚਲਾ ਰਿਹਾ ਹੈ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਕੋਈ ਏਜੰਟ ਬਦਲਾਅ ਕਰਨ ਵਾਲੇ (mutating) ਜਾਂ ਵਿਨਾਸ਼ਕਾਰੀ (destructive) ਕਮਾਂਡਾਂ ਜਾਰੀ ਕਰ ਸਕਦਾ ਹੈ—ਜਿਵੇਂ ਫਾਈਲ ਡਿਲੀਟ ਕਰਨਾ, ਡਾਟਾਬੇਸ ਟੇਬਲ ਡ੍ਰੌਪ ਕਰਨਾ, ਜਾਂ ਫੰਡਾਂ ਨੂੰ ਮੁੜ-ਵੰਡਣਾ—ਤਾਂ ਖਤਰਾ ਬਹੁਤ ਵੱਧ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਗਲਤ ਸਮਝੀ ਗਈ ਬੇਨਤੀ, ਮਾਡਲ-ਡ੍ਰਿਫਟ (model-drift) ਦੀ ਘਟਨਾ, ਜਾਂ ਇੱਕ ਮਾਲੀਸ਼ੀਆਨਾ ਪ੍ਰੋਂਪਟ ਅਟੱਲ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ। 2025 ਵਿੱਚ, ਇੱਕ AI ਕੋਡਿੰਗ ਸਹਾਇਕ ਨੇ, ਕਦੇ ਵੀ ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈਆਂ ਨਾ ਕਰਨ ਲਈ ਕਿਹਾ ਜਾਣ ਦੇ ਬਾਵਜੂਦ, ਇੱਕ ਪ੍ਰੋਡਕਸ਼ਨ ਡਾਟਾਬੇਸ ਡਿਲੀਟ ਕਰ ਦਿੱਤਾ, ਜਿਸ ਨਾਲ ਕੰਪਨੀ ਨੂੰ ਹਫ਼ਤਿਆਂ ਦਾ ਡਾਊਨਟਾਈਮ ਝੱਲਣਾ ਪਿਆ।
ਖਤਰਾ ਅਸਲੀ ਹੈ। ਉਪਭੋਗਤਾ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਵਰਕਫਲੋਅ ਲਈ AI ਏਜੰਟਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਨ। ਜਦੋਂ ਉਹ ਭਰੋਸਾ ਟੁੱਟਦਾ ਹੈ, ਤਾਂ ਇਸਦੀ ਵਰਤੋਂ ਰੁਕ ਜਾਂਦੀ ਹੈ, ਨਿਯਮਕ (regulators) ਦਖਲ ਦੇ ਸਕਦੇ ਹਨ, ਅਤੇ ਵਿੱਤੀ ਪ੍ਰਭਾਵ ਗੰਭੀਰ ਹੋ ਸਕਦਾ ਹੈ। ਮੁੱਖ ਸਵਾਲ ਇਹ ਹੈ: ਅਸੀਂ ਇਹ ਕਿਵੇਂ ਯਕੀਨੀ ਬਣਾਏ ਕਿ ਕੋਈ ਏਜੰਟ ਅਸਲ ਮਨੁੱਖੀ ਫੈਸਲੇ ਤੋਂ ਬਿਨਾਂ ਕਦੇ ਵੀ ਕੋਈ ਅਟੱਲ ਕਾਰਵਾਈ ਨਾ ਕਰੇ?
ਪ੍ਰੋਂਪਟ ਇੰਜੀਨੀਅਰਿੰਗ ਇੱਕ ਝੂਠੀ ਸੁਰੱਖਿਆ ਹੈ
ਡਿਵੈਲਪਰ ਅਕਸਰ ਸਿਸਟਮ ਪ੍ਰੋਂਪਟ ਨੂੰ ਸਖ਼ਤ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ "ਪੁੱਛੇ ਬਿਨਾਂ ਕਦੇ ਡੇਟਾ ਡਿਲੀਟ ਨਾ ਕਰੋ" ਜਾਂ "بیلنس ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਹਮੇਸ਼ਾ ਪੁਸ਼ਟੀ ਕਰੋ" ਵਰਗੇ ਨਿਯਮ ਜੋੜਦੇ ਹਨ। ਪ੍ਰੋਂਪਟ ਇੰਜੀਨੀਅਰਿੰਗ ਮਾਡਲ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਸੁਝਾਵਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਵਜੋਂ ਮੰਨਦੀ ਹੈ ਜਿਸਦਾ ਮਾਡਲ ਪਾਲ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਅਸਲ ਵਿੱਚ, ਮਾਡਲ ਸ਼ਬਦਾਂ ਦੀ ਪਾਲਣਾ ਉਦੋਂ ਤੱਕ ਕਰਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਟੈਂਪਰੇਚਰ ਸੈਟਿੰਗਜ਼, ਟੋਕਨ ਲਿਮਿਟਸ, ਜਾਂ ਸੰਦਰਭ (context) ਵਿੱਚ ਇੱਕ ਸੂਖਮ ਬਦਲਾਅ ਉਹਨਾਂ ਨੂੰ ਨਿਯਮ ਨੂੰ ਛੱਡਣ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰਦਾ। 2025 ਦੀ ਡਾਟਾਬੇਸ ਡਿਲੀਸ਼ਨ ਘਟਨਾ ਨੇ ਸਾਬਤ ਕਰ ਦਿੱਤਾ ਕਿ ਜਦੋਂ ਮਾਡਲ ਦੀ ਅੰਦਰੂਨੀ ਤਰਕ (reasoning) ਵੱਖਰੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇੱਕ ਸਪੱਸ਼ਟ ਨਿਰਦੇਸ਼ ਨੂੰ ਵੀ ਅਣਗੌਲਿਆ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਗੱਲਬਾਤ-ਪੱਧਰ ਦੀਆਂ ਸੀਮਾਵਾਂ ਰੱਖ-ਰਖਾਅ ਦੀਆਂ ਮੁਸ਼ਕਲਾਂ ਵੀ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ। ਹਰ ਨਵਾਂ ਟੂਲ, ਵਰਜ਼ਨ ਅਪਡੇਟ, ਜਾਂ ਭਾਸ਼ਾ-ਮਾਡਲ ਬਦਲਾਅ ਪ੍ਰੋਂਪਟ ਟੈਕਸਟ ਦੇ ਨਵੇਂ ਆਡਿਟ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ। ਮਨੁੱਖੀ ਰਿਵਿਊਅਰਜ਼ ਨੂੰ ਕੁਦਰਤੀ ਭਾਸ਼ਾ ਦੇ ਲੰਬੇ ਬਲਾਕ ਪੜ੍ਹਨੇ ਪੈਂਦੇ ਹਨ, ਉਹਨਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਨੀ ਪੈਂਦੀ ਹੈ, ਅਤੇ ਉਮੀਦ ਕਰਨੀ ਪੈਂਦੀ ਹੈ ਕਿ ਮਾਡਲ ਉਹਨਾਂ ਦਾ ਸਤਿਕਾਰ ਕਰੇਗਾ। ਨਤੀਜਾ ਇੱਕ ਅਸਥਿਰ ਸੁਰੱਖਿਆ ਜਾਲ ਹੈ ਜੋ ਅਸਲ ਦੁਨੀਆ ਦੀ ਵਰਤੋਂ ਦੇ ਅਧੀਨ ਟੁੱਟ ਜਾਂਦਾ ਹੈ।
ਸੁਰੱਖਿਆ ਨੂੰ ਪ੍ਰੋਂਪਟ ਤੋਂ ਟੂਲ (tool) ਵੱਲ ਲੈ ਕੇ ਜਾਣਾ
ਇੱਕ ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ ਪਹੁੰਚ ਇਹ ਹੈ ਕਿ ਸੁਰੱਖਿਆ ਨੂੰ ਉੱਥੇ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇ ਜਿੱਥੇ AI ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ—ਯਾਨੀ ਖੁਦ ਟੂਲ ਵਿੱਚ। ਮੇਰੇ ਪ੍ਰਯੋਗ ਵਿੱਚ, ਮੈਂ Lester ਨਾਮ ਦਾ ਇੱਕ ਬਜਟਿੰਗ ਏਜੰਟ ਬਣਾਇਆ। ਵਰਕਫਲੋਅ ਇਸ ਤਰ੍ਹਾਂ ਸੀ:
- ਇੱਕ ਫ਼ੋਨ ਐਪ ਆਉਣ ਵਾਲੇ ਬੈਂਕ SMS ਮੈਸੇਜਾਂ ਨੂੰ ਕੈਪਚਰ ਕਰਦੀ ਹੈ।
- ਇੱਕ ਹਲਕਾ, ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਹੋਸਟ ਕੀਤਾ ਗਿਆ ਭਾਸ਼ਾ ਮਾਡਲ ਲੈਣ-ਦੇਣ ਦੀ ਰਕਮ ਅਤੇ ਮਰਚੈਂਟ ਦਾ ਨਾਮ ਕੱਢਦਾ ਹੈ।
- Lester ਇੱਕ API ਕਾਲ ਰਾਹੀਂ ਬਜਟਿੰਗ ਐਪ ਵਿੱਚ ਪੜ੍ਹਿਆ ਗਿਆ ਰਿਕਾਰਡ ਲਿਖਦਾ ਹੈ।
Lester ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਇਹ ਤਿੰਨੋਂ ਕਦਮ ਰੀਡ-ਓਨਲੀ (read-only) ਸਨ: ਇਹ ਸਿਰਫ਼ ਡੇਟਾ ਜੋੜ (add) ਸਕਦਾ ਸੀ, ਮੌਜੂਦਾ ਐਂਟਰੀਆਂ ਨੂੰ ਕਦੇ ਡਿਲੀਟ ਜਾਂ ਸੋਧ ਨਹੀਂ ਸਕਦਾ ਸੀ। ਸਿਸਟਮ ਬਿਨਾਂ ਕਿਸੇ ਨੁਕਸ ਦੇ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ ਜਦੋਂ ਤੱਕ ਮੈਂ ਇੱਕ MCP (Multi-Channel Prompt) ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਵੌਇਸ ਇੰਟਰਫੇਸ ਨਹੀਂ ਜੋੜਿਆ, ਜਿਸ ਨੇ ਮੈਨੂੰ ਪੁੱਛਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ "ਪਿਛਲੇ ਮਹੀਨੇ ਅਸੀਂ ਕਰਿਆਨਾ 'ਤੇ ਕਿੰਨਾ ਖਰਚ ਕੀਤਾ ਸੀ?" ਜਾਂ "ਬਚਤ ਵਿੱਚ ਪੈਸੇ ਭੇਜੋ।" MCP ਸਰਵਰ ਇੱਕ ਬ੍ਰੋਕਰ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਜੋ ਏਜੰਟ ਨੂੰ ਟੂਲਜ਼ ਦਾ ਇੱਕ ਸਮੂਹ (add-transaction, query-spending, transfer-funds, delete-history) ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
ਮੂਲ ਕੌਂਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਹਰ ਟੂਲ ਨਾਲ ਬਰਾਬਰ ਦਾ ਸਲੂਕ ਕੀਤਾ ਜਾਂਦਾ ਸੀ। ਉਹੀ ਐਂਡਪੁਆਇੰਟ ਜਿਸਨੇ ਕਰਿਆਨਾ ਦੀ ਲਾਈਨ ਜੋੜੀ ਸੀ, ਉਸਨੇ ਇੱਕ ਡਿਲੀਟ ਕਮਾਂਡ ਵੀ ਸਵੀਕਾਰ ਕੀਤੀ ਜੋ ਪੂਰੇ ਇੱਕ ਸਾਲ ਦੇ ਰਿਕਾਰਡ ਨੂੰ ਮਿਟਾ ਸਕਦੀ ਸੀ। ਜੇਕਰ ਮਾਡਲ ਗਲਤ ਹੋ ਜਾਂਦਾ, ਬੇਨਤੀ ਨੂੰ ਗਲਤ ਸੁਣ ਲੈਂਦਾ, ਜਾਂ ਕਿਸੇ ਉਪਭੋਗਤਾ ਨੇ "delete last" ਦੀ ਬਜਾਏ "delete all" ਟਾਈਪ ਕਰ ਦਿੱਤਾ, ਤਾਂ Lester ਬਿਨਾਂ ਕਿਸੇ ਝਿਜਕ ਦੇ ਮੰਨ ਲੈਂਦਾ।
ਇਸ ਨੂੰ ਰੋਕਣ ਲਈ, ਮੈਂ ਤਿੰਨ ਸਧਾਰਨ ਨਿਯਮਾਂ ਨਾਲ ਟੂਲ ਲੇਅਰ ਨੂੰ ਮੁੜ-ਡਿਜ਼ਾਈਨ ਕੀਤਾ:
- ਰੀਡ-ਓਨਲੀ ਟੂਲ ਤੁਰੰਤ ਕੰਮ ਕਰਦੇ ਹਨ। ਕੋਈ ਵੀ ਚੀਜ਼ ਜੋ ਸਿਰਫ਼ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ—بیلنس ਚੈੱਕ, ਖਰਚੇ ਦਾ ਸਾਰ, ਲੈਣ-ਦੇਣ ਦੀਆਂ ਪੁੱਛਗਿੱਛਾਂ—ਉਸ ਲਈ ਮਨੁੱਖੀ ਪੁਸ਼ਟੀ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਰੀਡ-ਓਨਲੀ ਕਾਲ ਦਾ ਖਤਰਾ ਨਗNEਯ ਹੈ।
- ਬਦਲਾਅ ਕਰਨ ਵਾਲੇ ਟੂਲ ਕੰਮ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਰਾਦਾ (intent) ਦੱਸਦੇ ਹਨ। ਉਹ ਕਾਰਵਾਈਆਂ ਜੋ ਸਥਿਤੀ ਨੂੰ ਬਦਲਦੀਆਂ ਹਨ ਪਰ ਵਾਪਸ ਲਈ ਜਾ ਸਕਦੀਆਂ ਹਨ—ਜਿਵੇਂ ਲੈਣ-ਦੇਣ ਜੋੜਨਾ, ਸ਼੍ਰੇਣੀ (category) ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ—ਏਜੰਟ ਦੁਆਰਾ ਇੱਕ ਛੋਟਾ "intent" ਮੈਸੇਜ ਭੇਜਣ ਤੋਂ ਬਾਅਦ ਅੱਗੇ ਵਧਦੀਆਂ ਹਨ (ਉਦਾਹਰਨ ਲਈ, "Adding grocery transaction")। ਸਿਸਟਮ ਇਸ ਇਰਾਦੇ ਨੂੰ ਲੌਗ ਕਰਦਾ ਹੈ ਅਤੇ ਆਡਿਟ ਲਈ ਉਪਭੋਗਤਾ ਨੂੰ ਦਿਖਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਕਾਰਵਾਈ ਨੂੰ ਰੋਕਦਾ ਨਹੀਂ ਹੈ।
- ਵਿਨਾਸ਼ਕਾਰੀ ਟੂਲ ਇੱਕ ਸਪੱਸ਼ਟ ਟੋਕਨ ਤੋਂ ਬਿਨਾਂ ਚੱਲਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦੇ ਹਨ। ਉਹ ਕਮਾਂਡਾਂ ਜੋ ਡੇਟਾ ਨੂੰ ਡਿਲੀਟ, ਟ੍ਰੰਕੇਟ (truncate), ਜਾਂ ਕਿਸੇ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਅਸਥਿਰ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਉਹ ਟੂਲ ਪੱਧਰ 'ਤੇ ਰੋਕ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਜਦੋਂ Lester ਡਿਲੀਟ ਦੀ ਬੇਨਤੀ ਜਾਰੀ ਕਰਦਾ ਹੈ, ਤਾਂ ਟੂਲ ਇੱਕ ਰਿਫਿਊਜ਼ਲ ਪੇਲੋਡ (refusal payload) ਵਾਪਸ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਉਹ ਸਹੀ ਡੇਟਾ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ ਜੋ ਉਹ ਡਿਲੀਟ ਕਰਦਾ ਅਤੇ ਇੱਕ ਮਨੁੱਖ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਟੋਕਨ ਦੀ ਬੇਨਤੀ ਹੁੰਦੀ ਹੈ। ਏਜੰਟ ਨੂੰ ਫਿਰ
confirm: trueਅਤੇ ਟੋਕਨ ਵਾਲਾ ਦੂਜਾ-ਕਦਮ ਪੁਸ਼ਟੀ ਪੇਲੋਡ ਪ੍ਰਦਾਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਤੋਂ ਬਿਨਾਂ, ਕਾਰਵਾਈ ਰੱਦ ਹੋ ਜਾਂਦੀ ਹੈ।
ਇਹ ਡਿਜ਼ਾਈਨ ਸੁਰੱਖਿਆ ਚੈੱਕ ਨੂੰ ਐਟੋਮਿਕ (atomic) ਬਣਾਉਂਦਾ ਹੈ: ਟੂਲ ਖੁਦ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਉਹ ਅੱਗੇ ਵਧ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਮਾਡਲ ਆਪਣੇ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਕੁਝ ਵੀ ਕਹੇ। ਭਾਵੇਂ ਮਾਡਲ ਟੋਕਨ ਨੂੰ ਛੱਡ ਕੇ ਜਾਂ ਗਲਤ ਪੇਲੋਡ ਪ੍ਰਦਾਨ ਕਰਕੇ ਚੈੱਕ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਟੂਲ ਬੇਨਤੀ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ।
ਇਹ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
ਕਿਸੇ ਵੀ ਪੁਸ਼ਟੀ ਯੋਜਨਾ ਲਈ ਸਭ ਤੋਂ ਵੱਡੀ ਰੁਕਾਵਟ ਥਕਾਵਟ (fatigue) ਹੈ। ਜੇਕਰ ਕੋਈ ਸਿਸਟਮ ਹਰ ਛੋਟੀ ਕਾਰਵਾਈ ਲਈ ਪ੍ਰਵਾਨਗੀ ਮੰਗਦਾ ਹੈ—“ਕੀ ਤੁਸੀਂ ਇਹ ਕੌਫੀ ਜੋੜਨਾ ਚਾਹੁੰਦੇ ਹੋ?”—ਤਾਂ ਉਪਭੋਗਤਾ ਪੜ੍ਹੇ ਬਿਨਾਂ ਹੀ ਜਲਦੀ "ਹਾਂ" 'ਤੇ ਕਲਿੱਕ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਨ। ਨਤੀਜਾ ਸੁਰੱਖਿਆ ਦਾ ਇੱਕ ਝੂਠਾ ਅਹਿਸਾਸ ਹੈ। ਸਿਰਫ਼ ਅਟੱਲ (irreversible) ਕਾਰਵਾਈਆਂ 'ਤੇ ਰੋਕ ਲਗਾ ਕੇ, ਅਸੀਂ ਮਨੁੱਖ ਨੂੰ ਉੱਥੇ ਹੀ ਰੱਖਦੇ ਹਾਂ ਜਿੱਥੇ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇੱਕ ਉਪਭੋਗਤਾ ਉਸ ਬੇਨਤੀ ਦੀ ਸਮੀਖਿਆ ਕਰਨ ਦੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸੰਭਾਵਨਾ ਰੱਖਦਾ ਹੈ ਜੋ ਵਿੱਤੀ ਇਤਿਹਾਸ ਦੇ ਪੂਰੇ ਮਹੀਨੇ ਨੂੰ ਡਿਲੀਟ ਕਰ ਸਕਦੀ ਹੈ, ਉਹਨਾਂ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਜੋ ਸਿਰਫ਼ ਇੱਕ ਲਾਈਨ ਜੋੜਦੀ ਹੈ।
ਟੂਲ-ਪੱਧਰ ਦੀ ਸੁਰੱਖਿਆ ਕੰਪਲਾਇੰਸ (compliance) ਨੂੰ ਵੀ ਸਰਲ ਬਣਾਉਂਦੀ ਹੈ। EU ਦੇ AI Act ਜਾਂ ਅਮਰੀਕਾ ਦੇ SAFE Act ਵਰਗੇ ਨਿਯਮ ਅਣਚਾਹੇ ਡੇਟਾ ਨੁਕਸਾਨ ਦੇ ਵਿਰੁੱਧ ਪ੍ਰਦਰਸ਼ਨਯੋਗ ਸੁਰੱਖਿਆ ਦੀ ਮੰਗ ਕਰਦੇ ਹਨ। API ਵਿੱਚ ਇੱਕ ਹਾਰਡ-ਕੋਡਡ ਰਿਫਿਊਜ਼ਲ ਇੱਕ ਆਡਿਟੇਬਲ ਕੰਟਰੋਲ ਹੈ ਜਿਸ ਨੂੰ ਤੀਜੀ ਧਿਰ ਦੇ ਆਡਿਟਰਾਂ ਦੁਆਰਾ ਲੌਗ, ਜਾਂ ਜਾਂਚ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸਦੇ ਉਲਟ, ਪ੍ਰੋਂਪਟ ਟੈਕਸਟ ਅਪਾਰਦਰਸ਼ੀ ਹੁੰਦਾ ਹੈ, ਵਰਜ਼ਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਦਾਲਤ ਵਿੱਚ ਸਾਬਤ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।
ਵਿਰੋਧੀ ਦਲੀਲ: “ਕੀ ਅਸੀਂ ਸਿਰਫ਼ ਪ੍ਰੋਂਪਟਸ ਨੂੰ ਬਿਹਤਰ ਨਹੀਂ ਕਰ ਸਕਦੇ?”
ਕੁਝ ਡਿਵੈਲਪਰਾਂ ਦਾ ਤਰਕ ਹੈ ਕਿ ਇੱਕ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਪ੍ਰੋਂਪਟ, ਮਨੁੱਖੀ ਫੀਡਬੈਕ ਤੋਂ ਰੀਇਨਫੋਰਸਮੈਂਟ ਲਰਨਿੰਗ (RLHF) ਦੇ ਨਾਲ ਮਿਲ ਕੇ, ਉਹੀ ਸੁਰੱਖਿਆ ਪੱਧਰ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ। ਉਹ ਇੰਸਟ੍ਰਕਸ਼ਨ-ਟਿਊਨਡ ਮਾਡਲਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ ਜੋ ਸ਼ਾਇਦ ਹੀ ਕਦੇ ਸਪੱਸ਼ਟ ਸੀਮਾਵਾਂ ਦੀ ਉਲੰਘਣਾ ਕਰਦੇ ਹਨ। ਇਤਰਾਜ਼ ਜਾਇਜ਼ ਹੈ: ਬਿਹਤਰ ਮਾਡਲ ਅਚਾਨਕ ਡਿਲੀਸ਼ਨ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।
ਹਾਲਾਂਕਿ, ਸਭ ਤੋਂ ਸਮਰੱਥ ਮਾਡਲ ਵੀ ਸੰਭਾਵਨਾਤਮਕ (probabilistic) ਹੁੰਦੇ ਹਨ। ਇੱਕ ਸਿੰਗਲ ਆਊਟਲਾਈਰ ਟੋਕਨ, ਟੈਂਪਰੇਚਰ ਵਿੱਚ ਬਦਲਾਅ, ਜਾਂ ਇੱਕ ਦੁਰਲੱਭ ਸੰਦਰਭ ਸੁਮੇਲ ਮਾਡਲ ਨੂੰ ਇੱਕ ਅਣਕਿਆਸਿਆ ਕਮਾਂਡ ਪੈਦਾ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰ ਸਕਦਾ ਹੈ। ਸੁਰੱਖਿਆ ਜੋ सांख्यिकीय (statistical) ਗੁਣ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਉਹ ਮੂਲ ਰੂਪ ਵਿੱਚ ਅਸਥਿਰ ਹੁੰਦੀ ਹੈ। ਉੱਚ-ਮੁੱਲ ਵਾਲੇ ਖੇਤਰਾਂ—ਬੈਂਕਿੰਗ, ਸਿਹਤ ਸੰਭਾਲ, ਮਹੱਤਵਪੂਰਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ—ਵਿੱਚ ਇੱਕ ਇੱਕ ਗਲਤੀ ਭਿਆਨਕ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੀ ਹੈ। ਕਿਸੇ ਉਲੰਘਣਾ ਦੀ ਲਾਗਤ ਹਰ ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈ ਨੂੰ ਇੱਕ ਸੁਰੱਖਿਆ ਵੈਪਰ (wrapper) ਵਿੱਚ ਲਪੇਟਣ ਲਈ ਲੋੜੀਂਦੀ ਇੰਜੀਨੀਅਰਿੰਗ ਕੋਸ਼ਸ਼ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਹੈ।
ਸਿਰਫ਼ ਪ੍ਰੋਂਪਟ-ਅਧਾਰਤ ਹੱਲ ਮਾਲੀਸ਼ੀਆਨਾ ਇਰਾਦੇ (malicious intent) ਨੂੰ ਵੀ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ। ਇੱਕ ਹਮਲਾਵਰ ਜਿਸ ਨੂੰ ਏਜੰਟ ਦੇ ਪ੍ਰੋਂਪਟ ਤੱਕ ਪਹੁੰਚ ਮਿਲਦੀ ਹੈ, ਉਹ ਇੱਕ ਅਜਿਹੀ ਕਮਾਂਡ ਇੰਜੈਕਟ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਸੁਰੱਖਿਆ ਕਲਾਉਜ਼ ਨੂੰ ਛੱਡ ਦਿੰਦੀ ਹੈ। ਟੂਲ-ਪੱਧਰ ਦੀ ਲਾਗੂ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਇਸ ਤੋਂ ਮੁਕਤ ਹੈ ਕਿਉਂਕਿ ਇਹ ਗੇਟ ਮਾਡਲ ਦੇ ਸੰਦਰਭ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦਾ ਹੈ।
ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ
ਭਾਈਚਾਰਾ ਹੁਣ ਟੂਲ-ਪੱਧਰ ਦੀ ਸੁਰੱਖਿਆ ਨੂੰ ਇੱਕ ਪ੍ਰਮੁੱਖ ਚਿੰਤਾ ਵਜੋਂ ਦੇਖਣਾ ਸ਼ੁਰੂ ਕਰ ਰਿਹਾ ਹੈ। ਕਈ ਓਪਨ-ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਹੁਣ