ਸੁਰੱਖਿਆ ਖੋਜਕਰਤਾ ਜੇਕ ਵਿਲੀਅਮਜ਼ (Jake Williams) ਨੇ ਇਸ ਹਫ਼ਤੇ CUSTODY ਫਰੇਮਵਰਕ ਦਾ अनाਹਰ ਕੀਤਾ ਹੈ, ਜੋ ਉਦਯੋਗਾਂ ਨੂੰ ਉਹਨਾਂ AI agents ਲਈ ਸਪੱਸ਼ਟ runtime permissions ਅਤੇ ਸੀਮਾਵਾਂ ਨਿਰਧਾਰਤ ਕਰਨ ਦਾ ਇੱਕ ਤਰੀਕਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਕਾਰਪੋਰੇਟ ਨੈੱਟਵਰਕਾਂ ਦੇ ਅੰਦਰ ਕੰਮ ਕਰਦੇ ਹਨ। ਇਹ ਟੂਲ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ, ਰਵਾਇਤੀ ਸਾਫਟਵੇਅਰ ਦੇ ਉਲਟ, AI agents ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਨ, ਸੇਵਾਵਾਂ ਨੂੰ ਕਾਲ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਮਾਡਲਾਂ ਨੂੰ ਸੋਧ ਸਕਦੇ ਹਨ—ਉਹ ਵੀ ਬਿਨਾਂ ਕਿਸੇ ਸਪੱਸ਼ਟ ਅਤੇ ਲਾਗੂ ਕਰਨਯੋਗ ਨੀਤੀ ਦੇ—ਜਿਸ ਨਾਲ ਇੱਕ ਅਜਿਹੀ ਖਾਲੀ ਥਾਂ ਬਣ ਜਾਂਦੀ ਹੈ ਜਿਸਦਾ ਹਮਲਾਵਰਾਂ ਨੇ ਪਹਿਲਾਂ ਹੀ ਫਾਇਦਾ ਉਠਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਹੈ।

AI agents ਨੂੰ ਇੱਕ ਰੁਕਾਵਟ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ

ਐਂਟਰਪ੍ਰਾਈਜ਼ AI ਸਟੈਕਸ ਵਿੱਚ ਹੁਣ ਚੈਟ-ਬੋਟਸ, ਰੈਕਮੈਂਡੇਸ਼ਨ ਇੰਜਣ, ਖੁਦਮੁਖਤਿਆਰ ਫੈਸਲੇ ਲੈਣ ਵਾਲੇ (autonomous decision-makers) ਅਤੇ ਦਰਜਨਾਂ ਬੈਕਗ੍ਰਾਊਂਡ agents ਸ਼ਾਮਲ ਹਨ ਜੋ ਅੰਦਰੂਨੀ APIs ਜਾਂ ਤੀਜੀ-ਪਾਰਟੀ ਸੇਵਾਵਾਂ ਤੋਂ ਡੇਟਾ ਕੱਢਦੇ ਹਨ। ਮੌਜੂਦਾ ਸੁਰੱਖਿਆ ਸੂਟਸ ਪਰਿਮੇਤਰ ਫਾਇਰਵਾਲ (perimeter firewalls), ਐਂਡਪੁਆਇੰਟ ਪ੍ਰੋਟੈਕਸ਼ਨ ਅਤੇ ਨੈੱਟਵਰਕ ਸੈਗਮੈਂਟੇਸ਼ਨ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦੇ ਹਨ, ਪਰ ਉਹ ਇਹ ਕਹਿਣ ਲਈ ਕੋਈ ਮਿਆਰੀ ਤਰੀਕਾ ਨਹੀਂ ਰੱਖਦੇ ਕਿ "ਇਹ agent ਗਾਹਕਾਂ ਦੇ ਰਿਕਾਰਡ ਪੜ੍ਹ ਸਕਦਾ ਹੈ ਪਰ ਵਿੱਤ ਡੇਟਾਬੇਸ (finance database) ਵਿੱਚ ਲਿਖ ਨਹੀਂ ਸਕਦਾ।" ਅਜਿਹੇ runtime ਕੰਟਰੋਲ ਦੀ ਅਣਹੋਂਦ ਕਾਰਨ ਪਹਿਲਾਂ ਹੀ ਅਜਿਹੀਆਂ ਘਟਨਾਵਾਂ ਵਾਪਰੀਆਂ ਹਨ ਜਿੱਥੇ ਕੰਪ੍ਰੋਮਾਈਜ਼ਡ agents ਦੀ ਵਰਤੋਂ ਡੇਟਾ ਚੋਰੀ ਕਰਨ ਜਾਂ ਮਾਡਲ ਵੇਟਸ (model weights) ਨੂੰ ਖਰਾਬ ਕਰਨ ਲਈ ਕੀਤੀ ਗਈ ਸੀ।

CUSTODY ਇਸ ਖਾਲੀ ਥਾਂ ਨੂੰ ਕਿਵੇਂ ਭਰਦਾ ਹੈ

CUSTODY ਇੱਕ ਨਿਯਮ-ਅਧਾਰਤ ਭਾਸ਼ਾ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਜੋ ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਇੱਕ ਵਾਰ ਨੈੱਟਵਰਕ ਨਾਲ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਇੱਕ AI agent ਨੂੰ ਕੀ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ। ਨੀਤੀਆਂ (Policies) ਇਹ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੀਆਂ ਹਨ:

  • Resource access – ਕਿਹੜੇ ਡੇਟਾਬੇਸ, ਫਾਈਲ ਸਟੋਰ ਜਾਂ APIs ਦੀ agent ਕੁਐਰੀ (query) ਕਰ ਸਕਦਾ ਹੈ।
  • Action limits – ਕੀ agent ਸਿਰਫ਼ ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਜਾਂ ਲਿਖ ਸਕਦਾ ਹੈ, ਡਿਲੀਟ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਅਗਲੇਰੀਆਂ (downstream) ਜੌਬਸ ਨੂੰ ਟ੍ਰਿਗਰ ਵੀ ਕਰ ਸਕਦਾ ਹੈ।
  • Execution context – ਕੰਪਿਊਟ ਵਾਤਾਵਰਣ 'ਤੇ ਪਾਬੰਦੀਆਂ, ਜਿਵੇਂ ਕਿ CPU ਕੋਟਾ ਜਾਂ ਕੰਟੇਨਰ ਆਇਸੋਲੇਸ਼ਨ।

Runtime ਸਮੇਂ, ਇਹ ਫਰੇਮਵਰਕ agent ਦੀਆਂ ਕਾਲਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦੀ ਨਿਰਧਾਰਤ ਨੀਤੀ ਨਾਲ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਵੀ ਅਜਿਹੀ ਕਾਰਵਾਈ ਨੂੰ ਰੋਕ ਦਿੰਦਾ ਹੈ ਜੋ ਨਿਰਧਾਰਤ ਸੀਮਾਵਾਂ ਤੋਂ ਬਾਹਰ ਹੁੰਦੀ ਹੈ। ਇਹ ਇੱਕ ਹਾਈਜੈਕ ਕੀਤੇ ਗਏ agent ਨੂੰ ਕਾਰਪੋਰੇਟ ਮਾਹੌਲ ਵਿੱਚ ਬਿਨਾਂ ਕਿਸੇ ਰੋਕ-ਟੋਕ ਦੇ ਘੁੰਮਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।

CUSTODY ਨੂੰ ਮੌਜੂਦਾ ਸਟੈਕਸ ਵਿੱਚ ਜੋੜਨਾ

ਇਹ ਫਰੇਮਵਰਕ ਮੌਜੂਦਾ ਸੁਰੱਖਿਆ ਟੂਲਸ ਦੇ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਹ ਪ੍ਰਸਿੱਧ orchestration platforms, container runtimes ਅਤੇ API gateways ਨਾਲ ਜੁੜ ਸਕਦਾ ਹੈ, ਪਰ ਸਹੀ ਕਦਮ ਅਧਾਰ ਅਧੀਨ agent platform ਦੇ ਅਨੁਸਾਰ ਵੱਖ-ਵੱਖ ਹੁੰਦੇ ਹਨ। ਸੰਸਥਾਵਾਂ ਨੂੰ ਆਪਣੇ AI ਇਨਵੈਂਟਰੀ ਦਾ ਨਕਸ਼ਾ ਤਿਆਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਹਰੇਕ ਸ਼੍ਰੇਣੀ ਦੇ agent ਲਈ ਨੀਤੀ ਫਾਈਲਾਂ ਲਿਖਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ enforcement layer ਦੀ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਮਾਡਲਾਂ ਦੇ ਵਿਕਸਿਤ ਹੋਣ ਦੇ ਨਾਲ ਨਿਯਮਾਂ ਨੂੰ ਅਪ-ਟੂ-ਡੇਟ ਰੱਖਣ ਲਈ ਦਰਜਨਾਂ agents ਵਿੱਚ ਇਹਨਾਂ ਨੀਤੀਆਂ ਨੂੰ ਪਸਾਰਨ ਲਈ ਇੱਕ ਸਮਰਪਿਤ ਸੰਚਾਲਨ ਯਤਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।

ਸਾਵਧਾਨੀਆਂ ਅਤੇ ਵਿਰੋਧ

ਆਲੋਚਕਾਂ ਦਾ ਕਹਿਣਾ ਹੈ ਕਿ CUSTODY ਆਪਣੇ ਆਪ ਨੀਤੀਆਂ ਤਿਆਰ ਨਹੀਂ ਕਰਦਾ; ਸੁਰੱਖਿਆ ਟੀਮਾਂ ਨੂੰ ਉਹਨਾਂ ਨੂੰ ਮੈਨੂਅਲੀ ਤਿਆਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਜੋ ਕਿ ਬਹੁਤ ਮਿਹਨਤ ਵਾਲਾ ਕੰਮ ਹੋ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਹਰ ਕਾਲ ਦੀ ਰੀਅਲ-ਟਾਈਮ ਵਿੱਚ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਪ੍ਰਦਰਸ਼ਨ (performance) ਵਿੱਚ ਕਮੀ ਆਉਣ ਦਾ ਖ਼ਤਰਾ ਵੀ ਹੈ, ਖਾਸ ਕਰਕੇ ਉੱਚ-ਥਰਪੁੱਟ (high-throughput) inference services ਲਈ। ਅੰਤ ਵਿੱਚ, ਫਰੇਮਵਰਕ ਦੀ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਵਿਆਪਕ ਅਪਣਾਉਣ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ—ਜੇਕਰ ਕਿਸੇ ਵੈਂਡਰ ਦਾ AI platform ਲੋੜੀਂਦੇ hooks ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ CUSTODY ਦੇ ਕੰਟਰੋਲਸ ਨੂੰ ਬਾਈਪਾਸ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

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

  • Vendor response – ਕੀ ਪ੍ਰਮੁੱਖ AI platform ਪ੍ਰਦਾਤਾ CUSTODY-ਅਨੁਕੂਲ hooks ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਗੇ ਜਾਂ ਆਪਣੇ runtime-policy engines ਪੇਸ਼ ਕਰਨਗੇ।
  • Standardisation – AI agent permissions ਲਈ ਉਦਯੋਗ-ਵਿਆਪੀ ਸੈਟਿੰਗਾਂ ਵੱਲ ਕੋਈ ਵੀ ਹਰਕਤ CUSTODY ਨੂੰ ਇੱਕ ਅਸਲ ਮਿਆਰ (de-facto baseline) ਬਣਾ ਸਕਦੀ ਹੈ।
  • Community feedback – ਸ਼ੁਰੂਆਤੀ ਅਪਣਾਉਣ ਵਾਲੇ ਅਸਲ-ਦੁਨੀਆ ਦੀ ਨੀਤੀ ਦੀ ਗੁੰਝਲਤਾ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਪ੍ਰਗਟ ਕਰਨਗੇ, ਜੋ ਭਵਿੱਖ ਦੇ ਵਰਜ਼ਨਾਂ ਨੂੰ ਰੂਪ ਦੇਣਗੇ।

ਉਹ ਉਦਯੋਗ ਜੋ AI agents 'ਤੇ ਨਿਰਭਰ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਹੁਣੇ CUSTODY ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ ਉਹਨਾਂ ਦੇ ਸੁਰੱਖਿਆ ਸਟੈਕ ਵਿੱਚ ਕਿੱਥੇ ਫਿੱਟ ਹੁੰਦਾ ਹੈ, ਅਤੇ AI-ਅਧਾਰਿਤ ਹਮਲਿਆਂ ਦੀ ਅਗਲੀ ਲਹਿਰ ਦੇ ਉਹਨਾਂ ਦੇ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਨੀਤੀਆਂ ਦਾ ਪਾਇਲਟ ਟੈਸਟ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।