𝗧𝗵𝗲 𝗗𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲 𝗕𝗲𝘁𝘄𝗲𝗲𝗻 𝗙𝗶𝗹𝘁𝗲𝗿𝘀 𝗮𝗻𝗱 𝗪𝗮𝗹𝗹𝘀

ਫਿਲਟਰਾਂ ਅਤੇ ਕੰਧਾਂ (Filters and Walls) ਵਿਚਕਾਰ ਅੰਤਰ

ਤੁਸੀਂ ਆਪਣੇ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਵਾਲਾ ਇੱਕ AI agent ਬਣਾ ਰਹੇ ਹੋ। ਸੁਰੱਖਿਆ ਲਈ ਤੁਹਾਡੇ ਕੋਲ ਦੋ ਚੋਣਾਂ ਹਨ। ਤੁਸੀਂ ਡੇਟਾ ਨੂੰ ਫਿਲਟਰ (filter) ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ ਤੁਸੀਂ ਇਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਕੰਧ (wall) ਖੜ੍ਹੀ ਕਰ ਸਕਦੇ ਹੋ।

ਫਿਲਟਰਿੰਗ (Filtering) ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੀ ਕੁਐਰੀ (query) ਸਿਰਫ਼ ਕੁਝ ਖਾਸ ਰੋਅ (rows) ਹੀ ਵਾਪਸ ਕਰਦੀ ਹੈ। ਵਾਲਿੰਗ (Walling) ਦਾ ਮਤਲਬ ਹੈ ਕਿ agent ਲੁਕਾਈਆਂ ਹੋਈਆਂ ਰੋਅ ਤੱਕ ਬਿਲਕੁਲ ਵੀ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ।

ਇਹ ਦੋਵੇਂ ਇੱਕੋ ਜਿਹੇ ਲੱਗਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਕੁਝ ਖਰਾਬ ਨਹੀਂ ਹੁੰਦਾ।

ਮੈਂ ਹਾਲ ਹੀ ਵਿੱਚ 1.2 ਮਿਲੀਅਨ ਸ਼ਬਦਾਂ ਨੂੰ ਇੱਕ ਗਿਆਨ ਅਧਾਰ (knowledge base) ਵਿੱਚ ਬਦਲਣ ਲਈ ਇੱਕ ਸਿਸਟਮ ਬਣਾਇਆ ਹੈ। ਮੈਂ ਡੇਟਾ ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਲਈ Supabase ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਮੈਂ ਚਾਹੁੰਦਾ ਸੀ ਕਿ ਮੇਰੇ AI agents ਸਿਰਫ਼ ਜਨਤਕ (public) ਸਮੱਗਰੀ ਹੀ ਦੇਖ ਸਕਣ।

ਮੈਂ ਡੇਟਾ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਲਈ ਇੱਕ ਸਟੈਂਡਰਡ Postgres view ਦੀ ਵਰਤੋਂ ਕੀਤੀ:

CREATE VIEW public_seeds AS
  SELECT * FROM moments
  WHERE visibility = 'public'
    AND is_canonical = true;

ਇਹ ਸਹੀ ਲੱਗਦਾ ਹੈ। ਪਰ ਇਸ ਵਿੱਚ ਇੱਕ ਵੱਡੀ ਖਾਮੀ ਹੈ। ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ, ਇੱਕ Postgres view ਮਾਲਕ (owner) ਵਜੋਂ ਚੱਲਦਾ ਹੈ, ਨਾ ਕਿ ਉਸ ਵਿਅਕਤੀ ਵਜੋਂ ਜੋ ਇਸਨੂੰ ਕਾਲ ਕਰ ਰਿਹਾ ਹੈ। View ਦੇ ਮਾਲਕ ਕੋਲ ਅਕਸਰ ਪੂਰੀ ਪਹੁੰਚ ਹੁੰਦੀ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੀਆਂ Row Level Security (RLS) ਨੀਤੀਆਂ (policies) view 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀਆਂ।

ਤੁਸੀਂ ਕੰਧ ਨਹੀਂ ਬਣਾਈ। ਤੁਸੀਂ ਇੱਕ ਫਿਲਟਰ ਬਣਾਇਆ ਹੈ।

ਜੇਕਰ ਕੋਈ ਫਿਲਟਰ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ AI agent ਨੂੰ ਇਸਦਾ ਪਤਾ ਨਹੀਂ ਲੱਗੇਗਾ। ਇੱਕ ਇਨਸਾਨ ਗਲਤੀ ਜਾਂ ਗਲਤ ਡੇਟਾ ਦੇਖ ਲੈਂਦਾ ਹੈ। ਇੱਕ agent ਸਿਰਫ਼ ਉਹੀ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ ਜੋ ਉਸਨੂੰ ਮਿਲਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ ਫਿਲਟਰ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ agent ਬਿਨਾਂ ਕਿਸੇ ਚੇਤਾਵਨੀ ਦੇ ਨਿੱਜੀ (private) ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦੇਵੇਗਾ।

Postgres 15 ਨੇ security_invoker ਵਿਕਲਪ ਨਾਲ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰ ਦਿੱਤਾ ਹੈ।

ਜਦੋਂ ਤੁਸੀਂ security_invoker ਨੂੰ true 'ਤੇ ਸੈੱਟ ਕਰਦੇ ਹੋ, ਤਾਂ view ਕਾਲ ਕਰਨ ਵਾਲੇ ਰੋਲ (calling role) ਵਜੋਂ ਚੱਲਦਾ ਹੈ। ਇਹ view ਨੂੰ ਤੁਹਾਡੀਆਂ RLS ਨੀਤੀਆਂ ਦੀ ਪਾਲਣਾ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। View ਇੱਕ ਢਾਂਚਾਗਤ ਗੇਟ (structural gate) ਬਣ ਜਾਂਦਾ ਹੈ।

ਸਹੀ ਤਰੀਕਾ:

CREATE VIEW public_seeds
  WITH (security_invoker = true)
AS
  SELECT * FROM moments
  WHERE visibility = 'public'
    AND is_canonical = true;

ਹੁਣ ਕੰਧ ਢਾਂਚਾਗਤ (structural) ਹੈ। ਭਾਵੇਂ ਕੋਈ ਡਿਵੈਲਪਰ ਗਲਤ ਕੁਐਰੀ ਜਾਂ join ਲਿਖੇ, RLS ਨੀਤੀ ਟੇਬਲ ਦੀ ਰੱਖਿਆ ਕਰਦੀ ਹੈ।

"ਇਹ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ" (This should not happen) ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਸਭ ਕੁਝ ਬਿਲਕੁਲ ਸਹੀ ਚੱਲ ਰਿਹਾ ਹੈ। "ਇਹ ਨਹੀਂ ਹੋ ਸਕਦਾ" (This cannot happen) ਤੁਹਾਡੇ ਆਰਕੀਟੈਕਚਰ (architecture) 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

ਜਦੋਂ ਤੁਸੀਂ AI ਲਈ ਕੁਝ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਸ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਨਹੀਂ ਹੋ ਸਕਦਾ।

ਆਪਣੇ ਸੈੱਟਅੱਪ ਵਿੱਚ ਚੈੱਕ ਕਰਨ ਵਾਲੀਆਂ ਤਿੰਨ ਚੀਜ਼ਾਂ:

• ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਸੀਂ agents ਲਈ service role ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਰਹੇ ਹੋ। Service role ਪੂਰੀ ਤਰ੍ਹਾਂ RLS ਨੂੰ ਬਾਈਪਾਸ (bypass) ਕਰ ਦਿੰਦਾ ਹੈ।
• ਆਪਣਾ Postgres version ਚੈੱਕ ਕਰੋ। security_invoker ਲਈ ਤੁਹਾਨੂੰ version 15 ਜਾਂ ਇਸ ਤੋਂ ਉੱਪਰ ਦੀ ਲੋੜ ਹੈ।
• ਆਪਣੇ ਮੌਜੂਦਾ views ਦਾ ਆਡਿਟ (audit) ਕਰੋ। ਪੁਰਾਣੇ views ਆਪਣੇ ਆਪ ਨਵੀਆਂ RLS ਨੀਤੀਆਂ ਦੀ ਪਾਲਣਾ ਨਹੀਂ ਕਰਦੇ।

Source: https://dev.to/chadtdyar/the-difference-between-this-shouldnt-happen-and-this-cannot-happen-in-ai-content-pipelines-1g0p

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