ਇੱਕ AI-ਨਿਰਮਿਤ cron job ਨੇ ਇੱਕ startup ਵਿੱਚ ਦਸ ਸੈਕਿੰਡ ਤੋਂ ਵੀ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਹਰ ਇੱਕ ਸਰਗਰਮ Stripe subscription ਨੂੰ ਡਿਲੀਟ ਕਰ ਦਿੱਤਾ, ਜਿਸ ਨਾਲ ਕੰਪਨੀ ਦੀ ਮਾਸਿਕ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੀ ਆਮਦਨ (MRR) ਘਟ ਕੇ $38 ਰਹਿ ਗਈ। ਇਹ ਘਟਨਾ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਖ਼ਤਰਾ deployment pipeline ਵਿੱਚ ਹੈ, ਨਾ ਕਿ ਉਸ language model ਵਿੱਚ ਜਿਸਨੇ ਕੋਡ ਲਿਖਿਆ ਸੀ।
ਕੀ ਹੋਇਆ
ਪਿਛਲੇ ਹਫ਼ਤੇ BridgeMindAI ਦੀ ਟੀਮ ਨੇ ਦੇਖਿਆ ਕਿ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਮਾਸਿਕ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੀ ਆਮਦਨ (MRR) ਸਿਰਫ਼ $38 ਦਿਖਾ ਰਹੀ ਸੀ। ਇੱਕ AI ਮਾਡਲ ਨੇ ਕੋਡ ਦੀ ਇੱਕ ਸਿੰਗਲ ਲਾਈਨ ਤਿਆਰ ਕੀਤੀ ਜਿਸ ਨੂੰ scheduler ਨੇ ਆਪਣੇ ਆਪ ਚਲਾ ਦਿੱਤਾ। ਉਸ ਲਾਈਨ ਨੇ ਹਰ ਗਾਹਕ ਦੇ ਰਿਕਾਰਡ ਲਈ Stripe ਦੇ subscription-cancellation endpoint ਨੂੰ ਕਾਲ ਕੀਤਾ। ਇਹ ਕਾਲ ਸੱਤ ਸੈਕਿੰਡ ਵਿੱਚ ਖ਼ਤਮ ਹੋ ਗਈ ਅਤੇ ਸਾਰੇ ਗਾਹਕਾਂ ਦਾ ਡੇਟਾ ਸਾਫ਼ ਕਰ ਦਿੱਤਾ।
ਸਕ੍ਰਿਪਟ ਨੇ ਇੱਕ ਖਾਲੀ ਡਿਲੀਸ਼ਨ ਕਿਊ (deletion queue) ਨੂੰ ਸਭ ਕੁਝ ਡਿਲੀਟ ਕਰਨ ਦੇ ਸੰਕੇਤ ਵਜੋਂ ਗਲਤ ਸਮਝ ਲਿਆ। ਉਹ “empty = all” ਪੈਟਰਨ 1980 ਦੇ ਦਹਾਕੇ ਤੋਂ ਹੀ production code ਵਿੱਚ ਮੌਜੂਦ ਹੈ, generative AI ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ।
ਮਾਡਲ ਦੋਸ਼ੀ ਕਿਉਂ ਨਹੀਂ ਹੈ
ਲੋਕਾਂ ਨੇ ਜਲਦੀ ਹੀ AI ਮਾਡਲ ਨੂੰ ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਣ ਲਈ ਦੋਸ਼ੀ ਠਹਿਰਾਇਆ। ਮਾਡਲ ਨੂੰ ਬਦਲਣ ਨਾਲ ਵੀ ਇਹ ਡਿਲੀਸ਼ਨ ਨਹੀਂ ਰੁਕਦੀ ਕਿਉਂਕਿ ਖ਼ਰਾਬੀ ਮਨੁੱਖ ਦੁਆਰਾ ਲਿਖੇ ਗਏ ਲੌਜਿਕ (logic) ਵਿੱਚ ਸੀ, ਨਾ ਕਿ ਕਿਸੇ hallucination ਜਾਂ bias ਵਿੱਚ।
ਅਸਲ ਅਸਫਲਤਾਵਾਂ ਆਰਕੀਟੈਕਚਰਲ (architectural) ਸਨ:
- ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਇੱਕ ਲਾਈਵ production Stripe API key ਸਟੋਰ ਕੀਤੀ ਗਈ ਸੀ ਜੋ subscriptions ਨੂੰ ਰੱਦ ਕਰ ਸਕਦੀ ਸੀ।
- ਇਹ ਬਿਨਾਂ ਕਿਸੇ runtime supervision ਦੇ ਚੱਲੀ।
- ਕੋਡ ਜਨਰੇਸ਼ਨ ਅਤੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ (execution) ਦੇ ਵਿਚਕਾਰ ਕੋਈ ਮਨੁੱਖੀ ਚੈੱਕਪੁਆਇੰਟ ਨਹੀਂ ਸੀ।
ਇਹਨਾਂ ਕਮੀਆਂ ਕਾਰਨ ਇੱਕ ਸਿੰਗਲ ਬੱਗ (bug) ਨੇ ਕੁਝ ਹੀ ਸੈਕਿੰਡਾਂ ਵਿੱਚ ਆਮਦਨ ਦੇ ਸਰੋਤ ਨੂੰ ਤਬਾਹ ਕਰ ਦਿੱਤਾ।
ਕਿਸੇ ਵੀ autonomous pipeline ਲਈ ਤਿੰਨ ਸੁਰੱਖਿਆ ਸਵਾਲ
ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਅਨਿਵਾਰਤ (irreversible) ਹਨ? Subscription ਰੱਦ ਕਰਨਾ, ਰਿਕਾਰਡ ਡਿਲੀਟ ਕਰਨਾ, ਜਾਂ ਰਿਫੰਡ ਜਾਰੀ ਕਰਨਾ ਵਾਪਸ ਨਹੀਂ ਲਿਆ ਜਾ ਸਕਦਾ। ਉਹਨਾਂ ਨੂੰ read-only queries ਨਾਲੋਂ ਵੱਧ ਸੁਰੱਖਿਆ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਏਜੰਟ ਕੋਲ ਕਿਹੜੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲਜ਼ (credentials) ਹਨ? ਕਿਸੇ autonomous ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਮਾਸਟਰ Stripe key ਦੇਣ ਨਾਲ ਅਣਸੀਮਤ ਸ਼ਕਤੀ ਮਿਲ ਜਾਂਦੀ ਹੈ। least-privilege ਸਿਧਾਂਤ ਲਾਗੂ ਕਰੋ: ਅਜਿਹੀਆਂ scoped keys ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੋ ਸਿਰਫ਼ ਲੋੜੀਂਦਾ ਕੰਮ ਹੀ ਕਰ ਸਕਣ।
ਮਨੁੱਖੀ ਚੈੱਕਪੁਆਇੰਟ ਕਿੱਥੇ ਹੈ? ਸਿਰਫ਼ ਕੋਡ ਰਿਵਿਊ ਹੀ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਕੋਡ ਜਨਰੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਅਤੇ ਕਿਸੇ ਵੀ ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਗੇਟ (gate) ਲਗਾਓ।
ਵਿਹਾਰਕ ਸੁਰੱਖਿਆ ਰੇਲਿੰਗਾਂ (Practical safety rails)
- Dry-run gate – ਕਿਸੇ ਵੀ ਡਿਲੀਟ ਜਾਂ ਕੈਂਸਲ ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ, ਨਿਸ਼ਾਨੇ ਵਾਲੇ ਟਾਰਗੇਟਸ ਨੂੰ ਲੌਗ (log) ਕਰੋ। ਜੇਕਰ ਸੂਚੀ ਖਾਲੀ ਹੈ ਜਾਂ ਅਸਾਧਾਰਣ ਤੌਰ 'ਤੇ ਵੱਡੀ ਹੈ, ਤਾਂ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਰੋਕ ਦਿਓ ਅਤੇ ਕਿਸੇ ਮਨੁੱਖ ਨੂੰ ਸੂਚਿਤ ਕਰੋ।
- Scoped credentials – ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ read-only keys ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜਦੋਂ ਕਿਸੇ ਕੰਮ ਲਈ subscription ਰੱਦ ਕਰਨੀ ਜ਼ਰੂਰੀ ਹੋਵੇ, ਤਾਂ ਇੱਕ ਸੀਮਤ (restricted) key ਬਣਾਓ ਜੋ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਹੀ customer ID 'ਤੇ ਕਾਰਵਾਈ ਕਰ ਸਕੇ।
- Human-in-the-loop prompt – ਕਿਸੇ ਚੈਨਲ (ਜਿਵੇਂ ਕਿ Slack) 'ਤੇ ਇੱਕ ਛੋਟਾ ਸੁਨੇਹਾ ਭੇਜੋ, ਜਿਵੇਂ ਕਿ “ਮੈਂ 47 subscriptions ਰੱਦ ਕਰਨ ਜਾ ਰਿਹਾ ਹਾਂ। ਪੁਸ਼ਟੀ ਕਰੋ?” ਇਸਦੀ ਲਾਗਤ ਨਗਾਨੀ ਹੈ; ਸੁਰੱਖਿਆ ਦਾ ਲਾਭ ਬਹੁਤ ਵੱਡਾ ਹੈ।
ਇਹ ਉਪਾਅ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦੇ ਕਿ ਕੋਡ ਕਿਹੜਾ ਮਾਡਲ ਲਿਖ ਰਿਹਾ ਹੈ ਕਿਉਂਕਿ ਉਹ generator ਦੀ ਨਹੀਂ, ਸਗੋਂ execution environment ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹਨ।
Autonomous agents ਲਈ ਇੱਕ production ਚੈੱਕਲਿਸਟ
- ਹਰ ਕਾਰਵਾਈ ਨੂੰ read, reversible, ਜਾਂ irreversible ਵਜੋਂ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰੋ।
- ਸਾਰੀਆਂ irreversible ਕਾਰਵਾਈਆਂ ਲਈ ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਲਾਜ਼ਮੀ ਕਰੋ।
- ਕ੍ਰੈਡੈਂਸ਼ੀਅਲਜ਼ ਨੂੰ ਕੰਮ ਲਈ ਲੋੜੀਂਦੀ ਘੱਟੋ-ਘੱਟ ਇਜਾਜ਼ਤਾਂ (permissions) ਤੱਕ ਸੀਮਤ ਰੱਖੋ।
- ਉਹਨਾਂ ਲੂਪਸ (loops) 'ਤੇ ਆਕਾਰ ਦੀ ਸੀਮਾ ਲਗਾਓ ਜੋ ਰਿਕਾਰਡ ਡਿਲੀਟ ਜਾਂ ਸੋਧਦੇ ਹਨ।
- ਏਜੰਟਾਂ ਨੂੰ ਪਹਿਲਾਂ ਇੱਕ sandbox ਵਿੱਚ ਚਲਾਓ ਜੋ production ਡੇਟਾ ਦੀ ਨਕਲ ਕਰਦਾ ਹੋਵੇ; ਲਾਈਵ ਡੇਟਾ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਨਤੀਜੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
- ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਏਜੰਟ ਦੀ ਯੋਜਨਾ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਲੌਗ ਕਰੋ ਤਾਂ ਜੋ ਰਿਵਿਊਅਰ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਇਰਾਦੇ ਨੂੰ ਸਮਝ ਸਕੇ।
ਇਸ ਚੈੱਕਲਿਸਟ ਦੀ ਪਾਲਣਾ ਕਰਨ ਨਾਲ ਇੱਕ “run-once-and-forget” ਸਕ੍ਰਿਪਟ ਇੱਕ ਨਿਯੰਤਰਿਤ ਵਰਕਫਲੋ (workflow) ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ ਜਿਸਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਅਤੇ ਜੇਕਰ ਕੁਝ ਗਲਤ ਲੱਗਦਾ ਹੈ ਤਾਂ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਸਬਕ ਸਪੱਸ਼ਟ ਹੈ: ਪ੍ਰਕਿਰਿਆ 'ਤੇ ਭਰੋਸਾ ਕਰੋ, ਮਾਡਲ 'ਤੇ ਨਹੀਂ।