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

तुम्ही तुमच्या डेटाचा वापर करू शकणारे एक AI agent तयार करत आहात. सुरक्षेसाठी तुमच्याकडे दोन पर्याय आहेत. तुम्ही डेटा फिल्टर करू शकता किंवा त्याला 'वॉल' (wall) करू शकता.

फिल्टरिंगचा अर्थ असा की तुमची क्वेरी फक्त काही ठराविक रो (rows) परत करते. वॉलिंगचा अर्थ असा की एजंट लपवलेल्या रो (rows) पर्यंत अजिबात पोहोचू शकत नाही.

जोपर्यंत काहीतरी बिघडत नाही, तोपर्यंत हे दोन्ही सारखेच वाटतात.

मी अलीकडेच १२ लाख शब्दांचे नॉलेज बेसमध्ये रूपांतर करण्यासाठी एक सिस्टम तयार केली. डेटा व्यवस्थापित करण्यासाठी मी 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 च्या मालकाकडे अनेकदा पूर्ण प्रवेश (full access) असतो. याचा अर्थ असा की तुमच्या Row Level Security (RLS) पॉलिसीज या view ला लागू होत नाहीत.

तुम्ही भिंत (wall) बांधली नाही. तुम्ही फक्त एक फिल्टर तयार केला आहे.

जर फिल्टर फेल झाला, तर AI agent ला त्याची जाणीव होणार नाही. मानवाला त्रुटी किंवा चुकीचा डेटा दिसतो. पण एजंटला जे काही मिळते, त्यावर तो प्रक्रिया करतो. जर तुमचा फिल्टर फेल झाला, तर तुमचा एजंट कोणतीही चेतावणी न देता खाजगी (private) डेटा वापरू लागेल.

Postgres 15 ने security_invoker पर्यायाद्वारे ही समस्या सोडवली आहे.

जेव्हा तुम्ही security_invoker ला true सेट करता, तेव्हा view हा कॉल करणाऱ्या रोल (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;

आता ही भिंत स्ट्रक्चरल आहे. जरी एखाद्या डेव्हलपरने चुकीची क्वेरी किंवा join लिहिले तरी, RLS पॉलिसी टेबलचे संरक्षण करते.

"असे होऊ नये" (This should not happen) हे सर्व काही व्यवस्थित चालण्यावर अवलंबून असते. "असे होऊ शकत नाही" (This cannot happen) हे तुमच्या आर्किटेक्चरवर अवलंबून असते.

जेव्हा तुम्ही AI साठी काही तयार करता, तेव्हा 'जे होऊ शकत नाही' (what cannot happen) या दृष्टीने डिझाइन केले पाहिजे.

तुमच्या सेटअपमध्ये तपासण्यासारख्या तीन गोष्टी:

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