ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਸੀਮਾ ਉਹ ਹੈ ਜਿਸ ਤੱਕ ਏਜੰਟ ਪਹੁੰਚ ਹੀ ਨਹੀਂ ਸਕਦਾ

ਜੇਕਰ ਕੋਈ AI ਏਜੰਟ ਕਈ ਸੰਸਥਾਵਾਂ ਲਈ ਇਨਫਰਾਸਟ੍ਰਕਚਰ (infrastructure) ਚਲਾਉਂਦਾ ਹੈ, ਤਾਂ ਸੁਰੱਖਿਆ ਇੱਕ ਭਿਆਨਕ ਸਰਾਪ ਬਣ ਜਾਂਦੀ ਹੈ।

ਖ਼ਤਰਾ ਏਜੰਟ ਦੁਆਰਾ ਕੋਈ ਚਲਾਕ ਗਲਤੀ ਕਰਨ ਵਿੱਚ ਨਹੀਂ ਹੈ। ਖ਼ਤਰਾ ਏਜੰਟ ਦੁਆਰਾ ਗਲਤ ਵਿਅਕਤੀ ਲਈ ਕੋਈ ਸਧਾਰਨ ਕੰਮ ਕਰਨ ਵਿੱਚ ਹੈ।

Customer A ਦੀ ਬਜਾਏ Customer B ਲਈ ਟਿਕਟ ਲਿਖਣਾ ਜਾਂ ਸੀਕਰੇਟ (secret) ਰੋਟੇਟ ਕਰਨਾ ਇੱਕ ਉਲੰਘਣਾ (breach) ਹੈ। ਤੁਸੀਂ ਉਲੰਘਣਾ ਨੂੰ ਪੈਚ (patch) ਨਹੀਂ ਕਰ ਸਕਦੇ। ਤੁਹਾਨੂੰ ਇਸ ਦਾ ਖੁਲਾਸਾ ਕਰਨਾ ਹੀ ਪਵੇਗਾ।

ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਇਸ ਨੂੰ ਪਰਮਿਸ਼ਨਾਂ (permissions) ਨਾਲ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਉਹ ਇੱਕ ਸੂਚੀ ਬਣਾਉਂਦੇ ਹਨ ਕਿ ਏਜੰਟ ਕਿਸ ਚੀਜ਼ ਨੂੰ ਛੂਹ ਸਕਦਾ ਹੈ। ਉਹ ਹਰ ਕਾਰਵਾਈ ਦੀ ਉਸ ਸੂਚੀ ਨਾਲ ਜਾਂਚ ਕਰਦੇ ਹਨ।

ਇਹ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਪਰਮਿਸ਼ਨਾਂ ਇਹ ਮੰਨ ਕੇ ਚੱਲਦੀਆਂ ਹਨ ਕਿ ਰਿਸੋਰਸ (resource) ਮੌਜੂਦ ਹੈ ਅਤੇ ਤੁਸੀਂ ਬੱਸ 'ਨਾ' ਕਹਿ ਦਿੰਦੇ ਹੋ। ਜੇਕਰ ਤੁਹਾਡੇ ਨਿਯਮ ਵਿੱਚ ਕੋਈ ਬੱਗ (bug) ਹੈ ਜਾਂ ਕੋਈ ਕੇਸ ਰਹਿ ਗਿਆ ਹੈ, ਤਾਂ ਏਜੰਟ ਗਲਤ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦਾ ਹੈ।

ਮੈਂ ਇੱਕ ਵੱਖਰੇ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹਾਂ। ਮੈਂ ਗਲਤ ਡੇਟਾ ਨੂੰ ਬਣਤਰ ਅਨੁਸਾਰ ਹੀ ਗੈਰ-ਮੌਜੂਦ ਕਰ ਦਿੰਦਾ ਹਾਂ।

Customer A ਦੇ ਸੈਸ਼ਨ ਵਿੱਚ, Customer B ਦੇ ਰਿਸੋਰਸ ਮੌਜੂਦ ਨਹੀਂ ਹੁੰਦੇ। ਕ੍ਰੈਡੈਂਸ਼ੀਅਲਜ਼ (credentials) ਲੋਡ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ। ਐਂਡਪੁਆਇੰਟਸ (endpoints) ਮੈਪ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦੇ। ਉੱਥੇ ਮੰਗਣ ਲਈ ਕੁਝ ਵੀ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਮਨ੍ਹਾ ਕਰਨ ਲਈ ਵੀ ਕੁਝ ਨਹੀਂ ਹੈ।

ਨਿਯਮਾਂ ਵਿੱਚ ਬੱਗ ਹੋ ਸਕਦੇ ਹਨ। ਸਿਸਟਮ ਦੀ ਭੌਤਿਕ ਬਣਤਰ ਵਿੱਚ ਨਹੀਂ।

ਮੈਂ ਇਹ ਬਹੁਤ ਮੁਸ਼ਕਲ ਤਰੀਕੇ ਨਾਲ ਸਿੱਖਿਆ। ਮੈਨੂੰ ਲੱਗਿਆ ਕਿ ਇੱਕ secrets manager ਕਾਫ਼ੀ ਸੀ। ਮੈਨੂੰ ਲੱਗਿਆ ਕਿ secrets ਨੂੰ ਅਲੱਗ ਕਰਨ ਨਾਲ tenants ਵੀ ਅਲੱਗ ਹੋ ਜਾਂਦੇ ਹਨ। ਮੈਂ ਗਲਤ ਸੀ।

ਇੱਕ secrets manager secrets ਨੂੰ ਅਲੱਗ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ endpoints ਨੂੰ ਅਲੱਗ ਨਹੀਂ ਕਰਦਾ। ਇੱਕ ਏਜੰਟ ਕੋਲ Customer A ਲਈ ਸਹੀ token ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਫਿਰ ਵੀ ਉਹ Customer B ਦੇ ਪਤੇ 'ਤੇ ਰਿਕਵੈਸਟ ਭੇਜ ਸਕਦਾ ਹੈ ਜੇਕਰ ਉਹ ਪਤਾ configuration ਵਿੱਚ ਹੈ।

ਲੀਕ (leak) secret ਵਿੱਚ ਨਹੀਂ ਹੈ। ਲੀਕ routing ਵਿੱਚ ਹੈ।

ਮੈਂ ਹਰ ਰਿਸੋਰਸ ਨੂੰ ਇੱਕ ਰਿਕਾਰਡ ਵਿੱਚ ਬੰਨ੍ਹ ਕੇ ਇਸ ਨੂੰ ਠੀਕ ਕੀਤਾ: • Resource • Endpoint • Credential • Owning tenant

ਤੁਸੀਂ ਮਾਲਕ ਨੂੰ ਪ੍ਰਾਪਤ ਕੀਤੇ ਬਿਨਾਂ ਪਤਾ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਡੇਟਾ ਭੇਜਣ ਵਾਲੀ library ਕੰਮ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੰਦੀ ਹੈ ਜੇਕਰ tenant ਸੈਸ਼ਨ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ। ਤੁਸੀਂ ਇਸ ਨੂੰ hardcode ਕਰਕੇ ਬਚ ਨਹੀਂ ਸਕਦੇ ਕਿਉਂਕਿ ਪਤਾ ਉਦੋਂ ਹੀ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਆਪਣੇ ਮਾਲਕ ਨਾਲ ਜੁੜਿਆ ਹੋਵੇ।

ਮੈਂ ਰੱਖਿਆ ਦੇ ਤਿੰਨ ਪੱਧਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹਾਂ:

  • Structural isolation ਤਾਂ ਜੋ ਗਲਤ ਡੇਟਾ ਮੌਜੂਦ ਹੀ ਨਾ ਹੋਵੇ।
  • ਇੱਕ bypass block ਤਾਂ ਜੋ ਏਜੰਟ ਚੈੱਕਾਂ ਨੂੰ ਛੱਡਣ ਲਈ raw tools ਦੀ ਵਰਤੋਂ ਨਾ ਕਰ ਸਕੇ।
  • Egress scoping ਤਾਂ ਜੋ ਸੈਸ਼ਨ ਸਿਰਫ਼ ਇਜਾਜ਼ਤ ਪ੍ਰਾਪਤ ਪਤਿਆਂ ਨਾਲ ਹੀ ਗੱਲ ਕਰ ਸਕੇ।

ਇਹ ਇੱਕ ਅਜਿਹਾ ਸਿਸਟਮ ਬਣਾਉਂਦਾ ਹੈ ਜੋ fails closed ਹੁੰਦਾ ਹੈ।

ਆਪਣੇ ਪਿਛਲੇ ਕੰਮ ਵਿੱਚ, ਮੈਂ failing open ਦੇ ਪੱਖ ਵਿੱਚ ਦਲੀਲ ਦਿੱਤੀ ਸੀ। ਜੇਕਰ ਏਜੰਟ ਨੂੰ ਯਕੀਨ ਨਹੀਂ ਹੈ ਕਿ ਕੋਈ ਕਾਰਵਾਈ ਸੁਰੱਖਿਅਤ ਹੈ ਜਾਂ ਨਹੀਂ, ਤਾਂ ਉਸ ਨੂੰ ਅੱਗੇ ਵਧਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਏਜੰਟ ਜੋ ਹਰ ਸ਼ੱਕ 'ਤੇ ਰੁਕ ਜਾਂਦਾ ਹੈ, ਉਹ ਬੇਕਾਰ ਹੈ।

ਪਰ tenant ਦੀਆਂ ਸੀਮਾਵਾਂ ਵੱਖਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਜੇਕਰ ਏਜੰਟ ਨੂੰ ਯਕੀਨ ਨਹੀਂ ਹੈ ਕਿ ਉਹ ਕਿਸਦਾ ਡੇਟਾ ਛੂਹ ਰਿਹਾ ਹੈ, ਤਾਂ ਉਸ ਨੂੰ ਰੁਕਣਾ ਚਾਹੀਦਾ ਹੈ।

ਕਾਰਵਾਈ ਵਿੱਚ ਅਨਿਸ਼ਚਿਤਤਾ ਹਲਚਲ ਵੱਲ ਲੈ ਜਾਂਦੀ ਹੈ। ਮਾਲਕੀ ਵਿੱਚ ਅਨਿਸ਼ਚਿਤਤਾ ਸਥਿਰਤਾ ਵੱਲ ਲੈ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

ਅਜਿਹੇ ਚੈੱਕ ਨਾ ਬਣਾਓ ਜੋ 'ਨਾ' ਕਹਿਣ। ਉਨ੍ਹਾਂ ਆਕਾਰਾਂ ਨੂੰ ਹਟਾ ਦਿਓ ਜਿਨ੍ਹਾਂ ਦੀ ਜਾਂਚ ਦੀ ਲੋੜ ਹੈ।

ਸਰੋਤ: https://dev.to/artemmatviychuk/the-safest-boundary-is-the-one-the-agent-cant-reach-across-20ad

ਵਿਕਲਪਿਕ ਸਿੱਖਣ ਕਮਿਊਨਿਟੀ: https://t.me/GyaanSetuAi