Google Cloud ਨੇ ਇੱਕ ਮੈਨੇਜਡ GKE Agent Sandbox ਸੇਵਾ ਲਾਂਚ ਕੀਤੀ ਹੈ, ਜਦੋਂ ਕਿ ਓਪਨ-ਸੋਰਸ kubernetes-sigs/agent-sandbox ਪ੍ਰੋਜੈਕਟ ਕਿਸੇ ਵੀ Kubernetes ਕਲੱਸਟਰ ਲਈ ਇਹੀ ਸਮਰੱਥਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਦੋਵੇਂ ਵਿਕਾਸਕਾਰਾਂ (developers) ਨੂੰ AI agents ਲਈ ਇੱਕ ਡਿਸਪੋਜ਼ੇਬਲ (disposable) Linux ਕੰਟੇਨਰ ਦਿੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਬਾਕੀ ਦਾ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਅਛੂਤਾ ਰਹਿੰਦਾ ਹੈ।

AI ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਗਏ ਕੋਡ ਨੂੰ ਇੱਕ 'ਪਲੇਪੈਨ' (playpen) ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ

ਆਧੁਨਿਕ AI agents ਸਿਰਫ਼ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਹੀ ਨਹੀਂ ਦਿੰਦੇ। ਉਹ ਸਕ੍ਰਿਪਟਾਂ ਲਿਖਦੇ ਹਨ, ਵੈੱਬ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਸ਼ੈੱਲ ਕਮਾਂਡਾਂ (shell commands) ਚਲਾਉਂਦੇ ਹਨ ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਵੈੱਬ ਸੇਵਾਵਾਂ ਵੀ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਸ਼ਕਤੀ ਇੱਕ ਸੁਰੱਖਿਆ ਖ਼ਤਰਾ (security gap) ਪੈਦਾ ਕਰਦੀ ਹੈ: ਉਹਨਾਂ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਕੋਡ ਬੱਗ ਵਾਲਾ, ਮਾਲੀਸ਼ੀਅਸ (malicious), ਜਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹਮਲਾਵਰ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਅਜਿਹਾ agent ਜੋ rm -rf / ਚਲਾਉਂਦਾ ਹੈ ਜਾਂ ਬਿਨਾਂ ਇਜਾਜ਼ਤ ਦੇ ਕਿਸੇ ਅੰਦਰੂਨੀ ਡਾਟਾਬੇਸ ਨਾਲ ਜੁੜ ਜਾਂਦਾ ਹੈ, ਉਹ ਪੂਰੇ ਸਿਸਟਮ ਨੂੰ ਖ਼ਤਰੇ ਵਿੱਚ ਪਾ ਸਕਦਾ ਹੈ।

ਇੱਕ sandbox ਹਰੇਕ agent ਨੂੰ ਉਸਦੇ ਆਪਣੇ ਕੰਟੇਨਰ ਵਿੱਚ ਅਲੱਗ ਕਰ ਦਿੰਦਾ ਹੈ—ਇੱਕ ਛੋਟੀ ਜਿਹੀ, ਵਰਤ ਕੇ ਸੁੱਟਣਯੋਗ (throw-away) ਵਰਚੁਅਲ ਮਸ਼ੀਨ। ਜੇਕਰ agent ਗਲਤ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਨੁਕਸਾਨ ਉਸੇ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਰਹਿੰਦਾ ਹੈ; ਹੋਸਟ ਅਤੇ ਹੋਰ ਵਰਕਲੋਡ ਸੁਰੱਖਿਅਤ ਰਹਿੰਦੇ ਹਨ। ਨਵੀਂ GKE ਪੇਸ਼ਕਸ਼ ਅਤੇ ਕਮਿਊਨਿਟੀ-ਡਰਾਈਵਨ ਪ੍ਰੋਜੈਕਟ ਇਸ ਵਿਚਾਰ ਨੂੰ ਇੱਕ ਤਿਆਰ-ਵਰਤੋਂ-ਯੋਗ ਸੇਵਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ।

Sandbox ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਦੋ ਤਰੀਕੇ

  • GKE Agent Sandbox – Google Cloud ਗਾਹਕਾਂ ਲਈ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮੈਨੇਜਡ ਸੇਵਾ।
  • kubernetes-sigs/agent-sandbox – ਕਿਸੇ ਵੀ Kubernetes ਕਲੱਸਟਰ ਲਈ ਇੱਕ ਓਪਨ-ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ।

ਦੋਵੇਂ ਇੱਕੋ ਜਿਹੀ ਮੂਲ ਆਰਕੀਟੈਕਚਰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਜੋ ਕਿ ਸਟੈਂਡਰਡ Kubernetes primitives 'ਤੇ ਬਣੀ ਹੈ।

ਸਿਸਟਮ ਨੂੰ ਕਿਵੇਂ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ

ਕੰਪੋਨੈਂਟ (Component) ਭੂਮਿਕਾ (Role)
Sandbox ਅਲੱਗ ਕੀਤਾ ਗਿਆ ਕੰਟੇਨਰ ਜੋ agent ਦੇ ਕੋਡ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ। ਇਸਦਾ ਇੱਕ ਸਥਿਰ ਨਾਮ ਅਤੇ ਲੋੜ ਪੈਣ 'ਤੇ ਪਰਸਿਸਟੈਂਟ ਸਟੋਰੇਜ ਹੁੰਦੀ ਹੈ।
SandboxTemplate ਇੱਕ ਬਲੂਪ੍ਰਿੰਟ ਜੋ ਕੰਟੇਨਰ ਇਮੇਜ ਅਤੇ ਸੁਰੱਖਿਆ ਨੀਤੀਆਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ—ਨਵੇਂ sandboxes ਲਈ ਇੱਕ ਰੈਸਿਪੀ।
SandboxClaim ਇੱਕ ਖਾਸ ਟੈਂਪਲੇਟ ਤੋਂ sandbox ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਇੱਕ agent (ਜਾਂ ਇਸਦੇ ਕੰਟਰੋਲਰ) ਦੁਆਰਾ ਜਾਰੀ ਕੀਤੀ ਗਈ ਬੇਨਤੀ।
SandboxWarmPool ਪਹਿਲਾਂ ਤੋਂ ਬਣਾਏ ਗਏ sandboxes ਦਾ ਇੱਕ ਪੂਲ ਜੋ ਤੁਰੰਤ ਵਰਤੋਂ ਲਈ ਤਿਆਰ ਹੈ। ਕੰਟੇਨਰਾਂ ਨੂੰ 'warm' ਰੱਖਣ ਨਾਲ ਹਰ ਵਾਰ ਇਮੇਜਾਂ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਨ ਅਤੇ ਨਵਾਂ pod ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਦੇਰੀ (latency) ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਜਦੋਂ ਕਿਸੇ agent ਨੂੰ ਵਾਤਾਵਰਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਉਹ ਇੱਕ SandboxClaim ਪੋਸਟ ਕਰਦਾ ਹੈ। ਕੰਟਰੋਲਰ ਵਾਰਮ ਪੂਲ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਇੱਕ ਖਾਲੀ sandbox ਚੁਣਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ claim ਨਾਲ ਜੋੜ ਦਿੰਦਾ ਹੈ। ਜੇਕਰ ਪੂਲ ਖਾਲੀ ਹੈ, ਤਾਂ ਇਹ ਟੈਂਪਲੇਟ ਤੋਂ ਇੱਕ ਨਵਾਂ sandbox ਬਣਾਉਂਦਾ ਹੈ; ਨਹੀਂ ਤਾਂ, ਇਹ ਪ੍ਰਕਿਰਿਆ ਮਿਲੀਸੈਕਿੰਡਾਂ ਵਿੱਚ ਹੋ ਜਾਂਦੀ ਹੈ।

ਸੁਰੱਖਿਆ ਕੰਟਰੋਲ (Security knobs) ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਵਰਤ ਸਕਦੇ ਹੋ

  • Default-deny networking – ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਇੱਕ sandbox ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ। ਤੁਹਾਨੂੰ ਬਾਹਰੀ ਜਾਂ ਅੰਦਰੂਨੀ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਲਈ ਸਪੱਸ਼ਟ ਨਿਯਮ ਜੋੜਨੇ ਪੈਣਗੇ, ਜੋ ਅੰਦਰੂਨੀ ਸੇਵਾਵਾਂ ਦੇ ਅਚਾਨਕ ਖ਼ੇਡ ਵਿੱਚ ਆਉਣ ਨੂੰ ਰੋਕਦੇ ਹਨ।
  • Isolation levels – ਉਹ ਕੰਟੇਨਰ ਰਨਟਾਈਮ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਜੋਖਮ ਸਹਿਣ ਦੀ ਸਮਰੱਥਾ (risk tolerance) ਦੇ ਅਨੁਕੂਲ ਹੋਵੇ:
    • ਤੇਜ਼ੀ ਲਈ Standard containers,
    • ਵਾਧੂ user-space isolation ਲੇਅਰ ਲਈ gVisor, ਜਾਂ
    • ਹਾਰਡਵੇਅਰ-ਸਹਾਇਤਾ ਪ੍ਰਾਪਤ isolation ਲਈ Kata Containers ਜੋ ਇੱਕ ਹਲਕੀ VM ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ।
  • SDKs – Python ਅਤੇ Go ਕਲਾਇੰਟ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿਕਾਸਕਾਰਾਂ ਨੂੰ ਪ੍ਰੋਗਰਾਮੈਟਿਕ ਤੌਰ 'ਤੇ sandboxes ਬਣਾਉਣ, claim ਕਰਨ ਅਤੇ ਖਤਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ, ਜੋ AI-ਡਰਾਈਵਨ ਪਾਈਪਲਾਈਨਾਂ ਦੇ ਵਰਕਫਲੋ ਦੇ ਅਨੁਕੂਲ ਹਨ।

ਕਿਸ ਨੂੰ ਫਾਇਦਾ ਹੋਵੇਗਾ, ਅਤੇ ਕੌਣ ਵਿਰੋਧ ਕਰ ਸਕਦਾ ਹੈ

ਨਿਚੋੜ (Bottom line)

AI agents ਨੂੰ ਉਹਨਾਂ ਦਾ ਆਪਣਾ ਡਿਸਪੋਜ਼ੇਬਲ Linux ਬਾਕਸ ਦੇਣ ਨਾਲ AI-ਡਰਾਈਵਨ ਆਟੋਮੇਸ਼ਨ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਵੱਡਾ ਅਣਜਾਣ ਖ਼ਤਰਾ ਖ਼ਤਮ ਹੋ ਜਾਂਦਾ ਹੈ: ਇਹ ਜੋਖਮ ਕਿ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਕੋਡ ਹੋਸਟ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ। Google Cloud ਦੀ ਮੈਨੇਜਡ GKE Agent Sandbox ਅਤੇ ਕਮਿਊਨਿਟੀ ਦੁਆਰਾ ਚਲਾਇਆ ਜਾ ਰਿਹਾ kubernetes-sigs/agent-sandbox ਇਸ ਅਲੱਗਤਾ (isolation) ਨੂੰ ਕਲਾਉਡ-ਨੇਟਿਵ ਅਤੇ ਆਨ-ਪ੍ਰੇਮ (on-prem) ਦੋਵਾਂ ਵਾਤਾਵਰਣਾਂ ਲਈ ਵਿਹਾਰਕ ਬਣਾਉਂਦਾ ਹੈ। ਉਹ ਸੰਸਥਾਵਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸੁਰੱਖਿਆ ਦੇ ਨਾਲ ਚੁਸਤੀ (agility) ਦਾ ਸੰਤੁਲਨ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਉਹਨਾਂ ਕੋਲ ਹੁਣ AI ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਗਏ ਕੋਡ ਨੂੰ ਇੱਕ sandboxed playpen ਵਿੱਚ ਰੱਖਣ ਲਈ ਇੱਕ ਠੋਸ, Kubernetes-native ਟੂਲ ਹੈ।