కేవలం Read-Only మాత్రమే సరిపోదు: AI ఏజెంట్ల కోసం గార్డ్‌రైల్స్ (Guardrails)

AI ఏజెంట్లను సురక్షితంగా ఉంచడానికి సీనియర్ ఇంజనీర్లు తరచుగా ఒకే మాట చెబుతుంటారు: వాటికి read-only యాక్సెస్ మాత్రమే ఇవ్వండి.

ఇది సురక్షితంగా అనిపిస్తుంది. ఏజెంట్ దేనినీ పాడు చేయకుండానే స్లో క్వెరీలను (slow queries) పరిశోధించగలదు లేదా స్కీమాలను (schemas) సమ్మరైజ్ చేయగలదు.

కానీ read-only అనేది ఒక సేఫ్టీ మోడల్ కాదు. అది ఒక పరిమితి మాత్రమే.

మీ ఏజెంట్ ఏదైనా ఉపయోగకరమైన పని చేయాల్సి వచ్చినప్పుడు, read-only దాన్ని అడ్డుకుంటుంది. ఒకవేళ ఏజెంట్ ఏదైనా తప్పుగా ఉన్న ఇండెక్స్‌ను లేదా కరప్ట్ అయిన రో (corrupted row)ను గుర్తిస్తే, అది దాన్ని సరిచేయలేదు. దీనివల్ల మీకు మంటను చూపిస్తూ కూడా, దాన్ని ఆర్పడానికి హోస్ (hose) పట్టుకోలేని ఒక అసిస్టెంట్ ఉన్నట్లు అవుతుంది.

టీమ్‌లు తరచుగా ఓటమిని ఒప్పుకుని ఏజెంట్‌కు write access ఇచ్చేస్తుంటాయి. అసలు ప్రమాదం అక్కడే మొదలవుతుంది.

అసలు ప్రశ్న "ఏజెంట్ రైట్ చేయాలా వద్దా" అనేది కాదు. అసలు ప్రశ్న "ఆ రైట్స్ (writes)ను మీరు ఎలా నియంత్రిస్తారు (govern)" అనేది.

ఇన్స్ట్రక్షన్స్ (instructions) ద్వారా రైట్స్‌ను నియంత్రించడానికి ప్రయత్నించకండి. "ఎప్పుడూ టేబుల్‌ను డ్రాప్ చేయవద్దు" వంటి నియమాలను సిస్టమ్ ప్రాంప్ట్‌లో (system prompt) పెట్టకండి.

ప్రాంప్ట్ ఇంజెక్షన్ (Prompt injection) వల్ల ఈ నియమాలు నిరుపయోగం అవుతాయి. ఒక అటాకర్ డేటాలోని ఒక రో లేదా ఒక కామెంట్‌ను ఉపయోగించి, మీ నియమాలను విస్మరించేలా ఏజెంట్‌ను మోసం చేయవచ్చు. గార్డ్‌రైల్ అనేది ఏజెంట్‌తో పాటు ఒకే విండోలో ఉంటే, ఏజెంట్ దానిని తప్పించుకునేలా వాదించగలదు.

మీకు ungoverned writes మరియు mediated writes మధ్య తేడా అవసరం.

• Ungoverned writes: ఏజెంట్ ఒక కమాండ్‌ను రన్ చేయాలని నిర్ణయించుకుంటుంది, మరియు డేటాబేస్ దానిని అమలు చేస్తుంది. ఇక్కడ ఏజెంట్ యొక్క స్వంత నిర్ణయమే ఏకైక నియంత్రణ. • Mediated writes: కమాండ్ ఏజెంట్‌కు వెలుపల ఉన్న ఒక చెక్‌పాయింట్ (checkpoint) ద్వారా వెళుతుంది. ఈ చెక్‌పాయింట్ ఏజెంట్ మరియు డేటాబేస్ మధ్య ఉన్న డేటా పాత్‌లో ఉంటుంది.

ఒక mediated write ఈ విధంగా పనిచేస్తుంది:

  • ఏజెంట్ ఒక స్టేట్‌మెంట్‌ను ప్రతిపాదిస్తుంది.
  • ఒక proxy లేదా control plane ఆ స్టేట్‌మెంట్‌ను విశ్లేషిస్తుంది (parse చేస్తుంది).
  • ఆ proxy రిస్క్‌ను వర్గీకరిస్తుంది.
  • దాన్ని అనుమతించాలా లేదా మనిషి అనుమతి కోసం అడగాలా అనేది proxy నిర్ణయిస్తుంది.

ఈ విధానం మిమ్మల్ని ప్రాంప్ట్ ఇంజెక్షన్ నుండి రక్షిస్తుంది. ఒక దుర్మార్గపు ఇన్స్ట్రక్షన్ ఏజెంట్‌ను మోసం చేసి DROP TABLE కమాండ్‌ను రాయేలా చేయవచ్చు, కానీ అది proxyని మోసం చేయలేదు. Proxy ఏజెంట్ యొక్క ఉద్దేశాన్ని (intent) చదవదు; అది కేవలం అసలైన SQL కమాండ్‌ను మాత్రమే చూస్తుంది.

సురక్షితంగా ఉండటానికి ఈ నిర్మాణాన్ని ఉపయోగించండి:

  • సురక్షితమైన రీడ్స్‌ను (reads) ఆటో-అనుమతించండి. పని వేగంగా సాగడానికి ఏజెంట్లు SELECT క్వెరీలను స్వేచ్ఛగా రన్ చేయనివ్వండి.
  • రిస్క్‌తో కూడిన రైట్స్‌ను నియంత్రించండి (Gate). DELETE, UPDATE లేదా స్కీమా మార్పుల కోసం మనిషి అనుమతిని తప్పనిసరి చేయండి.
  • ప్రతిదీ లాగ్ (log) చేయండి. మార్పును ఎవరు ప్రతిపాదించారు మరియు ఎవరు ఆమోదించారో తెలిపే ఒక మార్చలేని (immutable) రికార్డును ఉంచుకోండి.

భద్రత కోసం read replicas పై ఆధారపడకండి. రీప్లికాలు పరిశోధనకు సహాయపడతాయి, కానీ అవి సమస్యలను సరిచేయలేవు. ప్రొడక్షన్ సమస్యను పరిష్కరించడానికి, మీరు ప్రైమరీ డేటాబేస్‌కు (primary database) రైట్ చేయాల్సిందే.

Mediation అనేది మీ డేటాను సురక్షితంగా ఉంచుతూనే, ఏజెంట్ ఉపయోగకరంగా ఉండేలా చేస్తుంది.

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