ਪ੍ਰਮਾਣਿਕਤਾ (Authentication) ਇਹ ਜਾਂਚਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਕੌਣ ਹੋ; ਅਧਿਕਾਰ (Authorization) ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹੋ। AI-ਸੰਚਾਲਿਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਇੱਕ ਵਧਦੀ ਗਿਣਤੀ ਲੌਗਇਨ ਸਮੇਂ ਇੱਕ ਵਾਰ ਉਪਭੋਗਤਾ ਦੀ ਪਛਾਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ ਅਤੇ ਫਿਰ ਬਾਕੀ ਸੈਸ਼ਨ ਲਈ ਅੰਡਰਲਾਈਂਗ ਏਜੰਟ ਨੂੰ ਕਿਸੇ ਵੀ ਸਰੋਤ (resource) 'ਤੇ ਕਾਰਵਾਈ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇ ਦਿੰਦੀ ਹੈ, ਜੋ ਅਸਲ ਵਿੱਚ ਉਸਨੂੰ ਇੱਕ "ਖੁੱਲ੍ਹੀ ਇਜਾਜ਼ਤ" (blank check) ਦੇਣ ਦੇ ਬਰਾਬਰ ਹੈ। ਇਹ ਡਿਜ਼ਾਈਨ ਅਚਾਨਕ ਡੇਟਾ ਲੀਕ, ਅਣਚਾਹੇ ਈਮੇਲਾਂ, ਜਾਂ ਇੱਥੋਂ ਤੱਕ ਕਿ ਵਿਨਾਸ਼ਕਾਰੀ ਡੇਟਾਬੇਸ ਅੱਪਡੇਟਾਂ ਦੇ ਦਰਵਾਜ਼ੇ ਖੋਲ੍ਹ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਜੋਖਮ ਹਰ ਵਾਰ ਵਧ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਇੱਕ AI ਸਹਾਇਕ ਮਿਲੀਸੈਕਿੰਡ ਲੇਟੈਂਸੀ (latency) ਦੇ ਨਾਲ ਕਈ ਟੂਲਸ ਨੂੰ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ।
ਇਹ ਗਲਤੀ ਵਾਰ-ਵਾਰ ਕਿਉਂ ਹੁੰਦੀ ਰਹਿੰਦੀ ਹੈ
ਜ਼ਿਆਦਾਤਰ AI ਡਿਵੈਲਪਰ ਲੌਗਇਨ ਸਕ੍ਰੀਨ ਨੂੰ ਇਕਲੌਤੀ ਸੁਰੱਖਿਆ ਗੇਟ ਮੰਨਦੇ ਹਨ। ਕੋਡ ਪਾਸਵਰਡ ਜਾਂ ਟੋਕਨ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ, ਸੈਸ਼ਨ ਨੂੰ "authenticated" ਵਜੋਂ ਮਾਰਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਇਹ ਮੰਨ ਲੈਂਦਾ ਹੈ ਕਿ ਅਗਲੀ ਕੋਈ ਵੀ ਬੇਨਤੀ ਸੁਰੱਖਿਅਤ ਹੈ। ਇੱਕ ਰਵਾਇਤੀ ਵੈੱਬ ਐਪ ਵਿੱਚ, ਇੱਕ ਮਨੁੱਖੀ ਉਪਭੋਗਤਾ ਦੇ ਹੌਲੀ ਕਲਿੱਕ ਇੱਕ ਕੁਦਰਤੀ ਰੋਕ (throttling point) ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ; ਇੱਕ ਮਨੁੱਖ "delete" ਦਬਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਰੁਕਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇੱਕ AI ਏਜੰਟ ਸਕਿੰਟਾਂ ਵਿੱਚ ਦਰਜਨਾਂ ਟੂਲ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਪਲੇਟਫਾਰਮ ਸਿਰਫ ਇਹ ਪੁੱਛਦਾ ਹੈ "ਕੀ ਉਪਭੋਗਤਾ ਲੌਗਇਨ ਹੈ?", ਤਾਂ ਹਰ ਕਾਲ ਨੂੰ ਉਹੀ ਬਿਨਾਂ ਕਿਸੇ ਰੋਕ-ਟੋਕ ਵਾਲੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਮਿਲ ਜਾਂਦੀਆਂ ਹਨ।
ਇਸਦਾ ਮੂਲ ਕਾਰਨ ਸਹੂਲਤ ਹੈ। ਟੀਮਾਂ ਅਕਸਰ ਪੂਰੀ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਇੱਕ ਸਿੰਗਲ ਲੌਂਗ-ਲਿਵਡ (long-lived) ਸਰਵਿਸ ਅਕਾਊਂਟ ਪ੍ਰੋਵੀਜ਼ਨ ਕਰਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਕੋਡ ਨੂੰ ਕਈ ਟੋਕਨਾਂ ਜਾਂ ਸਕੋਪਸ (scopes) ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਨਾ ਕਰਨਾ ਪਵੇ। ਉਸ ਅਕਾਊਂਟ ਕੋਲ ਆਮ ਤੌਰ 'ਤੇ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਵਿਆਪਕ ਇਜਾਜ਼ਤਾਂ ਹੁੰਦੀਆਂ ਹਨ—ਪੜ੍ਹਨਾ (read), ਲਿਖਣਾ (write), ਡਿਲੀਟ ਕਰਨਾ (delete)। ਜਦੋਂ ਇੱਕ AI ਸਹਾਇਕ ਉਸ ਸੈਸ਼ਨ ਦੇ ਅੰਦਰ ਚੱਲਦਾ ਹੈ, ਤਾਂ ਉਹ ਆਪਣੇ ਆਪ ਉਹ ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦਾ ਹੈ, ਭਾਵੇਂ ਮੌਜੂਦਾ ਕਾਰਜ ਨੂੰ ਅਸਲ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਲੋੜ ਹੋਵੇ ਜਾਂ ਨਾ।
ਕੀ ਖਤਰੇ ਵਿੱਚ ਹੈ
- ਡੇਟਾ ਦਾ ਪ੍ਰਗਟ ਹੋਣਾ (Data exposure) – ਇੱਕ ਏਜੰਟ ਜੋ ਉਪਭੋਗਤਾ ਦੇ ਲੌਗਇਨ ਕਰਨ ਤੋਂ ਬਾਅਦ ਕੋਈ ਵੀ ਫਾਈਲ ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਉਹ ਅਣਜਾਣੇ ਵਿੱਚ ਗੁਪਤ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਇੱਕ ਅਜਿਹੇ ਜਵਾਬ ਵਿੱਚ ਲਿਆ ਸਕਦਾ ਹੈ ਜੋ ਬਾਅਦ ਵਿੱਚ ਸੰਸਥਾ ਤੋਂ ਬਾਹਰ ਸਾਂਝਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
- ਅਣਚਾਹੇ ਕਾਰਜ (Unintended actions) – ਇੱਕ ਸਪੋਰਟ ਇੰਜੀਨੀਅਰ ਦਾ AI ਹੈਲਪਰ ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾਬੇਸ ਵਿਰੁੱਧ ਇੱਕ ਰੋਅ (raw) SQL ਕੁਐਰੀ ਚਲਾ ਸਕਦਾ ਹੈ, ਸਿਰਫ ਇਸ ਲਈ ਕਿਉਂਕਿ ਇੰਜੀਨੀਅਰ ਦਾ ਸੈਸ਼ਨ ਅਜੇ ਵੀ ਸਰਗਰਮ ਹੈ, ਭਾਵੇਂ ਕੁਐਰੀ ਉਸ ਟਿਕਟ ਨਾਲ ਸਬੰਧਤ ਨਾ ਹੋਵੇ ਜਿਸ 'ਤੇ ਕੰਮ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ।
- ਰੈਗੂਲੇਟਰੀ ਕੰਪਲਾਇੰਸ (Regulatory compliance) – ਬਹੁਤ ਸਾਰੇ ਡੇਟਾ-ਸੁਰੱਖਿਆ ਨਿਯਮਾਂ ਦੀ ਲੋੜ ਹੈ ਕਿ ਪਹੁੰਚ (access) ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਲੋੜੀਂਦੇ ਤੱਕ ਸੀਮਤ ਰੱਖਿਆ ਜਾਵੇ। ਇੱਕ ਬਲੈਂਕਟ ਪਰਮਿਸ਼ਨ ਮਾਡਲ ਉਹਨਾਂ ਸਿਧਾਂਤਾਂ ਦੀ ਉਲੰਘਣਾ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਆਡਿਟ ਜਾਂ ਜੁਰਮਾਨੇ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ।
- ਸੰਚਾਲਨ ਲਾਗਤ (Operational cost) – ਉਹ ਗਲਤੀਆਂ ਜੋ ਰਿਕਾਰਡ ਨੂੰ ਡਿਲੀਟ ਜਾਂ ਸੋਧਦੀਆਂ ਹਨ, ਟੀਮਾਂ ਨੂੰ ਤਬਦੀਲੀਆਂ ਨੂੰ ਵਾਪਸ ਲੈਣ (roll back), ਮੂਲ ਕਾਰਨਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਨਾਲ ਭਰੋਸਾ ਮੁੜ ਬਣਾਉਣ ਲਈ ਮਜਬੂਰ ਕਰਦੀਆਂ ਹਨ—ਇਹ ਸਭ ਸਮਾਂ ਅਤੇ ਪੈਸਾ ਬਰਬਾਦ ਕਰਦਾ ਹੈ।
ਗੁੰਮ ਹੋਇਆ ਕਦਮ: ਹਰ-ਕਾਰਵਾਈ ਲਈ ਅਧਿਕਾਰ (per-action authorization)
ਅਧਿਕਾਰ ਦੀ ਜਾਂਚ ਸਿਰਫ ਮੁੱਖ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ 'ਤੇ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਸਿਸਟਮ ਦੇ ਅੰਦਰ ਹਰ "ਦਰਵਾਜ਼ੇ" 'ਤੇ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਸਵਾਲ "ਇਹ ਕੌਣ ਹੈ?" ਤੋਂ ਬਦਲ ਕੇ "ਕੀ ਇਸ ਖਾਸ ਸਰੋਤ 'ਤੇ ਇਹ ਖਾਸ ਕਾਰਵਾਈ ਹੁਣੇ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ?" ਹੋ ਜਾਂਦਾ ਹੈ। ਉਸ ਜਾਂਚ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਪੂਰੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਬਦਲਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ; ਇਸ ਲਈ ਸਿਰਫ ਇੱਕ ਸਿੰਗਲ ਸੈਸ਼ਨ ਫਲੈਗ ਤੋਂ ਛੋਟੇ ਸਮੇਂ ਵਾਲੇ, ਸਕੋਪਡ ਟੋਕਨਾਂ (scoped tokens) ਵੱਲ ਜਾਣ ਦੀ ਲੋੜ ਹੈ।
ਅਭਿਆਸ ਵਿੱਚ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ
- ਇੱਕ ਨਿਰਧਾਰਤ ਸਕੋਪ ਦੇ ਨਾਲ ਟੋਕਨ ਦੀ ਮੰਗ ਕਰੋ – ਜਦੋਂ AI ਏਜੰਟ ਨੂੰ ਕਿਸੇ ਟੂਲ ਨੂੰ ਕਾਲ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਪਹਿਲਾਂ ਇੱਕ ਅਜਿਹਾ ਟੋਕਨ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਜੋ ਲੋੜੀਂਦੇ ਸਹੀ ਅਧਿਕਾਰਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ,
read:ticket,execute:sql_query)। - ਹਰ ਕਾਲ ਲਈ ਟੋਕਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ – ਟੂਲ ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ, ਸਰਵਿਸ ਇਹ ਜਾਂਚ ਕਰਦੀ ਹੈ ਕਿ ਟੋਕਨ ਵਿੱਚ ਲੋੜੀਂਦਾ ਸਕੋਪ ਸ਼ਾਮਲ ਹੈ ਅਤੇ ਟੋਕਨ ਦੀ ਮਿਆਦ ਖਤਮ ਨਹੀਂ ਹੋਈ ਹੈ।
- ਸਰੋਤ ਨੂੰ ਸਕੋਪ ਨਾਲ ਮਿਲਾਓ – ਜੇਕਰ ਬੇਨਤੀ ਕਿਸੇ ਖਾਸ ਪ੍ਰੋਜੈਕਟ ਜਾਂ ਡੇਟਾਬੇਸ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੀ ਹੈ, ਤਾਂ ਟੋਕਨ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਉਸ ਆਈਡੈਂਟੀਫਾਇਰ ਤੱਕ ਪਹੁੰਚ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ।
- ਰੱਦ ਕਰੋ ਜਾਂ ਇਜਾਜ਼ਤ ਦਿਓ – ਜੇਕਰ ਕੋਈ ਵੀ ਜਾਂਚ ਅਸਫਲ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਕਾਲ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਏਜੰਟ ਨੂੰ ਇੱਕ ਗਲਤੀ (error) ਮਿਲਦੀ ਹੈ ਜੋ ਉਹ ਉਪਭੋਗਤਾ ਨੂੰ ਦਿਖਾ ਸਕਦਾ ਹੈ।
ਕੋਡ ਵਿੱਚ ਅੰਤਰ ਸਿੱਧਾ ਹੈ। ਇੱਕ "ਗਲਤ" ਤਰੀਕਾ ਅਜਿਹਾ ਦਿਖ ਸਕਦਾ ਹੈ:
if session.is_authenticated():
tool.run(params)
ਇੱਕ "ਚੰਗਾ" ਤਰੀਕਾ ਜਾਂਚ ਦਾ ਵਿਸਤਾਰ ਕਰਦਾ ਹੈ:
token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
tool.run(params)
else:
raise PermissionError
ਦੂਜਾ ਪੈਟਰਨ ਕੁਝ ਲਾਈਨਾਂ ਵਧਾਉਂਦਾ ਹੈ ਪਰ ਸਿਸਟਮ ਨੂੰ ਹਰ ਕਾਰਜ ਲਈ ਸਹੀ ਸਵਾਲ ਪੁੱਛਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ।
ਮਿਆਰਡ (Standards) ਜੋ ਇਸਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ
OAuth 2.0 ਸਕੋਪਸ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਟੋਕਨ ਕੀ ਕਰ ਸਕਦਾ ਹੈ, ਇਸ ਨੂੰ ਸੀਮਤ ਕਰਨ ਲਈ ਇੱਕ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਅਪਣਾਇਆ ਗਿਆ ਤਰੀਕਾ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। project:1234:write ਜਾਂ email:send ਵਰਗੇ ਸਕੋਪਸ ਨੂੰ ਐਨਕੋਡ ਕਰਨ ਵਾਲੇ ਛੋਟੇ ਸਮੇਂ ਵਾਲੇ ਐਕਸੈਸ ਟੋਕਨ ਜਾਰੀ ਕਰਕੇ, ਡਿਵੈਲਪਰ ਵੈਰੀਫਿਕੇਸ਼ਨ ਸਟੈਪ ਕਰਨ ਲਈ ਮੌਜੂਦਾ ਲਾਇਬ੍ਰੇਰੀਆਂ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਨ।
ਨਵੇਂ Rich Authorization Requests (RFC 9396) ਇਸ ਵਿਚਾਰ ਦਾ ਵਿਸਤਾਰ ਕਰਦੇ ਹਨ, ਜੋ ਇੱਕ ਕਲਾਇੰਟ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਸਥਿਰ ਸੂਚੀ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦੀ ਬਜਾਏ ਰਨ-ਟਾਈਮ 'ਤੇ ਵਿਸਤ੍ਰਿਤ ਅਧਿਕਾਰਾਂ ਦੀ ਮੰਗ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ। ਉਹ ਲਚਕਤਾ ਉਦੋਂ ਉਪਯੋਗੀ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇੱਕ AI ਵਰਕਫਲੋ ਨੂੰ ਉਪਭੋਗਤਾ ਦੇ ਇਰਾਦੇ ਦੇ ਅਧਾਰ 'ਤੇ ਤੁਰੰਤ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਜੋੜਨ ਜਾਂ ਹਟਾਉਣ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
ਵਿਰੋਧੀ ਦਲੀਲ: ਸਰਲਤਾ ਬਨਾਮ ਸੁਰੱਖਿਆ
ਕੁਝ ਟੀਮਾਂ ਦਾ ਤਰਕ ਹੈ ਕਿ ਹਰ-ਐਕਸ਼ਨ (per-action) ਚੈੱਕ ਲੇਟੈਂਸੀ (latency) ਅਤੇ ਕੋਡ ਦੀ ਜਟਿਲਤਾ ਵਧਾਉਂਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ AI ਸਹਾਇਕ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕਈ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। ਉਹ ਦੱਸਦੇ ਹਨ ਕਿ ਇੱਕ ਸਿੰਗਲ ਸੈਸ਼ਨ ਟੋਕਨ ਹਰ ਕਾਲ ਲਈ ਨਵਾਂ ਟੋਕਨ ਪ੍ਰਾਪਤ ਕਰਨ ਅਤੇ ਉਸਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਦੇ ਵਾਧੂ ਕੰਮ (overhead) ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇਸ ਦਾ ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਇਸ ਨਾਲ ਦੁਰਵਰਤੋਂ ਦਾ ਖਤਰਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਧ ਜਾਂਦਾ ਹੈ। ਆਧੁਨਿਕ ਟੋਕਨ-ਵੈਲੀਡੇਸ਼ਨ ਸੇਵਾਵਾਂ ਮਾਈਕ੍ਰੋਸੈਕਿੰਡਾਂ ਵਿੱਚ ਕੰਮ ਕਰਨ ਲਈ ਬਣਾਈਆਂ ਗਈਆਂ ਹਨ, ਅਤੇ ਵਾਧੂ ਨੈੱਟਵਰਕ ਰਾਊਂਡ-ਟ੍ਰਿਪ ਨੂੰ 'least privilege' (ਘੱਟੋ-ਘੱਟ ਅਧਿਕਾਰ) ਦੇ ਸਿਧਾਂਤ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤੇ ਬਿਨਾਂ ਬੈਚ (batch) ਜਾਂ ਕੈਸ਼ (cache) ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਅਜਿਹੇ ਮਾਹੌਲ ਵਿੱਚ ਜਿੱਥੇ ਡੇਟਾ ਦੀ ਅਖੰਡਤਾ (integrity) ਅਤੇ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ (compliance) ਅਟੱਲ ਹੈ, ਉੱਥੇ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਮਾਮੂਲੀ ਕੀਮਤ ਜੋਖਮ ਵਿੱਚ ਕਮੀ ਦੇ ਮੁਕਾਬਲੇ ਬਹੁਤ ਘੱਟ ਹੈ।
ਅੱਗੇ ਕਿਸ ਚੀਜ਼ 'ਤੇ ਨਜ਼ਰ ਰੱਖਣੀ ਹੈ
- AI SDKs ਵਿੱਚ ਸਕੋਪਡ ਟੋਕਨਾਂ (scoped tokens) ਨੂੰ ਅਪਣਾਉਣਾ – ਪ੍ਰਮੁੱਖ AI ਪਲੇਟਫਾਰਮ ਟੂਲਕਿੱਟਾਂ ਦੇ ਅਪਡੇਟਸ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ; ਕਈ ਪਲੇਟਫਾਰਮ OAuth-ਅਧਾਰਤ ਸਕੋਪਸ ਲਈ ਹੈਲਪਰ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਪੇਸ਼ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹਨ।
- Policy-as-code ਫਰੇਮਵਰਕ – ਉੱਭਰ ਰਹੇ ਹੱਲ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਡਿਕਲੇਰੇਟਿਵ ਫਾਈਲ ਵਿੱਚ ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ ਨਿਯਮਾਂ ਨੂੰ ਘੋਸ਼ਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ, ਜੋ ਰਨ-ਟਾਈਮ (runtime) 'ਤੇ ਆਪਣੇ ਆਪ ਲਾਗੂ ਹੋ ਜਾਂਦੇ ਹਨ।
- ਆਡਿਟ ਲੌਗਸ ਜੋ ਹਰ-ਐਕਸ਼ਨ ਦੇ ਫੈਸਲਿਆਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਂਦੇ ਹਨ – ਜਿਵੇਂ-ਜਿਵੇਂ ਵਧੇਰੇ ਪਲੇਟਫਾਰਮ ਹਰ ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ ਚੈੱਕ ਨੂੰ ਰਿਕਾਰਡ ਕਰਨਗੇ, ਸੰਸਥਾਵਾਂ ਨੂੰ ਇਹ ਦੇਖਣ ਵਿੱਚ ਮਦਦ ਮਿਲੇਗੀ ਕਿ ਕਿਹੜੇ AI ਐਕਸ਼ਨਾਂ ਨੂੰ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਜਾ ਰਹੀ ਹੈ ਜਾਂ ਰੋਕਿਆ ਜਾ ਰਿਹਾ ਹੈ, ਜਿਸ ਨਾਲ ਭਵਿੱਖ ਦੀਆਂ ਨੀਤੀਆਂ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਮਿਲੇਗੀ।
ਮੁੱਖ ਗੱਲ (Takeaway)
ਲੌਗ-ਇਨ ਸੈਸ਼ਨ ਨੂੰ ਕੁਝ ਵੀ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਮੰਨਣਾ ਅਣਚਾਹੇ ਨਤੀਜਿਆਂ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ। ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ ਦੇ ਫੈਸਲੇ ਨੂੰ ਲੌਗਇਨ ਦੇ ਸਮੇਂ ਤੋਂ ਹਰ ਇੱਕ ਟੂਲ ਕਾਲ ਤੱਕ ਲੈ ਕੇ ਜਾ ਕੇ—ਅਤੇ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਵਰਤੇ ਜਾਣ ਵਾਲੇ, ਸਕੋਪਡ ਟੋਕਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ—AI ਐਪਲੀਕੇਸ਼ਨਾਂ ਡੇਟਾ ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹੋਏ, ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹੋਏ ਅਤੇ ਮਹਿੰਗੀਆਂ ਗਲਤੀਆਂ ਤੋਂ ਬਚਦੇ ਹੋਏ ਆਟੋਨੋਮਸ ਏਜੰਟਾਂ ਦੀ ਸਹੂਲਤ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖ ਸਕਦੀਆਂ ਹਨ। ਕੋਡ ਦੀਆਂ ਵਾਧੂ ਲਾਈਨਾਂ ਇੱਕ ਅਜਿਹੇ ਸਿਸਟਮ ਲਈ ਬਹੁਤ ਘੱਟ ਕੀਮਤ ਹਨ ਜੋ ਹਰ ਵਾਰ ਐਕਸ਼ਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵੇਲੇ ਸਹੀ ਸਵਾਲ ਪੁੱਛਦਾ ਹੈ।