ਸਿਰਫ਼ Read-Only ਹੋਣਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ: AI Agents ਲਈ Guardrails

ਸੀਨੀਅਰ ਇੰਜੀਨੀਅਰ ਅਕਸਰ AI agents ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਲਈ ਇੱਕ ਗੱਲ ਕਹਿੰਦੇ ਹਨ: ਉਹਨਾਂ ਨੂੰ read-only access ਦਿਓ।

ਇਹ ਸੁਰੱਖਿਅਤ ਲੱਗਦਾ ਹੈ। Agent ਕੁਝ ਵੀ ਤੋੜੇ ਬਿਨਾਂ ਮਾੜੀਆਂ queries ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ schemas ਦਾ ਸਾਰ (summarize) ਕੱਢ ਸਕਦਾ ਹੈ।

ਪਰ read-only ਕੋਈ ਸੁਰੱਖਿਆ ਮਾਡਲ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਸੀਮਾ (limitation) ਹੈ।

ਜਿਸ ਪਲ ਤੁਹਾਡੇ agent ਨੂੰ ਕੋਈ ਲਾਭਦਾਇਕ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ, read-only ਉਸਨੂੰ ਰੋਕ ਦਿੰਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ agent ਕਿਸੇ ਖ਼ਰਾਬ index ਜਾਂ ਖ਼ਰਾਬ (corrupted) row ਨੂੰ ਲੱਭ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਉਸਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਤੁਹਾਡੇ ਕੋਲ ਅਜਿਹਾ ਇੱਕ ਸਹਾਇਕ (assistant) ਰਹਿ ਜਾਂਦਾ ਹੈ ਜੋ ਅੱਗ ਵੱਲ ਇਸ਼ਾਰਾ ਤਾਂ ਕਰ ਸਕਦਾ ਹੈ ਪਰ ਪਾਈਪ (hose) ਨਹੀਂ ਚੁੱਕ ਸਕਦਾ।

ਟੀਮਾਂ ਅਕਸਰ ਹਾਰ ਮੰਨ ਲੈਂਦੀਆਂ ਹਨ ਅਤੇ agent ਨੂੰ write access ਦੇ ਦਿੰਦੀਆਂ ਹਨ। ਉੱਥੋਂ ਹੀ ਅਸਲੀ ਖ਼ਤਰਾ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ।

ਅਸਲੀ ਸਵਾਲ ਇਹ ਨਹੀਂ ਹੈ ਕਿ "ਕੀ agent ਨੂੰ ਲਿਖਣਾ (write) ਚਾਹੀਦਾ ਹੈ।" ਅਸਲੀ ਸਵਾਲ ਇਹ ਹੈ ਕਿ "ਤੁਸੀਂ ਉਹਨਾਂ writes ਨੂੰ ਕਿਵੇਂ ਕੰਟਰੋਲ (govern) ਕਰਦੇ ਹੋ।"

Writes ਨੂੰ ਹਦਾਇਤਾਂ (instructions) ਰਾਹੀਂ ਕੰਟਰੋਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ। System prompt ਵਿੱਚ "ਕਦੇ ਵੀ table drop ਨਾ ਕਰੋ" ਵਰਗੇ ਨਿਯਮ ਨਾ ਰੱਖੋ।

Prompt injection ਇਹਨਾਂ ਨਿਯਮਾਂ ਨੂੰ ਬੇਕਾਰ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਹਮਲਾਵਰ (attacker) ਡੇਟਾ ਦੀ ਕਿਸੇ row ਜਾਂ comment ਦੀ ਵਰਤੋਂ ਕਰਕੇ agent ਨੂੰ ਤੁਹਾਡੇ ਨਿਯਮਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਲਈ ਮੋੜ ਸਕਦਾ ਹੈ। ਜੇਕਰ guardrail ਉਹੀਨ window ਵਿੱਚ ਹੈ ਜਿੱਥੇ agent ਹੈ, ਤਾਂ agent ਉਸਨੂੰ ਬਚ ਕੇ ਨਿਕਲ ਸਕਦਾ ਹੈ।

ਤੁਹਾਨੂੰ ungoverned writes ਅਤੇ mediated writes ਵਿਚਕਾਰ ਅੰਤਰ ਦੀ ਲੋੜ ਹੈ।

• Ungoverned writes: Agent ਇੱਕ command ਚਲਾਉਣ ਦਾ ਫੈਸਲਾ ਕਰਦਾ ਹੈ, ਅਤੇ database ਉਸਨੂੰ ਲਾਗੂ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਕਲੌਤਾ ਕੰਟਰੋਲ agent ਦਾ ਆਪਣਾ ਫੈਸਲਾ ਹੁੰਦਾ ਹੈ। • Mediated writes: Command agent ਤੋਂ ਬਾਹਰ ਇੱਕ checkpoint ਤੋਂ ਲੰਘਦੀ ਹੈ। ਇਹ checkpoint agent ਅਤੇ database ਦੇ ਵਿਚਕਾਰ data path ਵਿੱਚ ਹੁੰਦਾ ਹੈ।

ਇੱਕ mediated write ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ:

  • Agent ਇੱਕ statement ਪ੍ਰਸਤਾਵਿਤ ਕਰਦਾ ਹੈ।
  • ਇੱਕ proxy ਜਾਂ control plane ਉਸ statement ਨੂੰ parse ਕਰਦਾ ਹੈ।
  • Proxy ਖ਼ਤਰੇ (risk) ਦੀ ਸ਼੍ਰੇਣੀ ਤੈਅ ਕਰਦਾ ਹੈ।
  • Proxy ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਇਜਾਜ਼ਤ ਦੇਣੀ ਹੈ ਜਾਂ ਕਿਸੇ ਇਨਸਾਨ ਤੋਂ ਮਨਜ਼ੂਰੀ ਲੈਣੀ ਹੈ।

ਇਹ ਤਰੀਕਾ ਤੁਹਾਨੂੰ prompt injection ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। ਇੱਕ ਮਾੜੀ ਹਦਾਇਤ (malicious instruction) agent ਨੂੰ DROP TABLE command ਲਿਖਣ ਲਈ ਮੋੜ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ proxy ਨੂੰ ਨਹੀਂ ਧੋਖਾ ਦੇ ਸਕਦੀ। Proxy agent ਦੇ ਇਰਾਦੇ (intent) ਨੂੰ ਨਹੀਂ ਪੜ੍ਹਦਾ; ਇਹ ਸਿਰਫ਼ ਅਸਲ SQL command ਨੂੰ ਦੇਖਦਾ ਹੈ।

ਸੁਰੱਖਿਅਤ ਰਹਿਣ ਲਈ ਇਸ ਢਾਂਚੇ ਦੀ ਵਰਤੋਂ ਕਰੋ:

  • Safe reads ਨੂੰ auto-allow ਕਰੋ। ਕੰਮ ਨੂੰ ਤੇਜ਼ ਰੱਖਣ ਲਈ agents ਨੂੰ SELECT queries ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਚਲਾਉਣ ਦਿਓ।
  • Risky writes 'ਤੇ ਰੋਕ ਲਗਾਓ। DELETE, UPDATE, ਜਾਂ schema ਬਦਲਾਅ ਲਈ ਇਨਸਾਨੀ ਮਨਜ਼ੂਰੀ ਲਾਜ਼ਮੀ ਕਰੋ।
  • ਸਭ ਕੁਝ log ਕਰੋ। ਇਸ ਗੱਲ ਦਾ ਇੱਕ ਅਟੱਲ (immutable) ਰਿਕਾਰਡ ਰੱਖੋ ਕਿ ਕਿਸਨੇ ਬਦਲਾਅ ਦਾ ਪ੍ਰਸਤਾਵ ਦਿੱਤਾ ਅਤੇ ਕਿਸਨੇ ਉਸਨੂੰ ਮਨਜ਼ੂਰ ਕੀਤਾ।

ਸੁਰੱਖਿਆ ਲਈ read replicas 'ਤੇ ਨਿਰਭਰ ਨਾ ਰਹੋ। Replicas ਜਾਂਚ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ, ਪਰ ਉਹ ਸੁਧਾਰ (fixes) ਲਾਗੂ ਨਹੀਂ ਕਰ ਸਕਦੇ। Production ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ primary database ਵਿੱਚ write ਕਰਨਾ ਹੀ ਪਵੇਗਾ।

Mediation agent ਨੂੰ ਤੁਹਾਡੇ ਡੇਟਾ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦੇ ਹੋਏ ਲਾਭਦਾਇਕ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ।

Source: https://dev.to/maxime_dalessandro_28171d/read-only-isnt-enough-guardrails-for-ai-agents-that-change-your-database-2e5h

Optional learning community: https://t.me/GyaanSetuAi