ಕೇವಲ 'Read-Only' ಸಾಕಾಗುವುದಿಲ್ಲ: AI ಏಜೆಂಟ್‌ಗಳಿಗಾಗಿ ಗಾರ್ಡ್‌ರೈಲ್‌ಗಳು (Guardrails)

AI ಏಜೆಂಟ್‌ಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿಡಲು ಹಿರಿಯ ಎಂಜಿನಿಯರ್‌ಗಳು ಹೆಚ್ಚಾಗಿ ಒಂದು ಮಾತನ್ನು ಹೇಳುತ್ತಾರೆ: ಅವುಗಳಿಗೆ 'read-only' ಪ್ರವೇಶವನ್ನು ನೀಡಿ.

ಇದು ಸುರಕ್ಷಿತವಾಗಿ ಕೇಳಿಸುತ್ತದೆ. ಏಜೆಂಟ್ ಏನನ್ನೂ ಹಾಳು ಮಾಡದೆಯೇ ನಿಧಾನಗತಿಯ ಕ್ವೇರಿಗಳನ್ನು (queries) ತನಿಖೆ ಮಾಡಬಹುದು ಅಥವಾ ಸ್ಕೀಮಾಗಳನ್ನು (schemas) ಸಾರಾಂಶಗೊಳಿಸಬಹುದು.

ಆದರೆ 'read-only' ಎಂಬುದು ಸುರಕ್ಷತಾ ಮಾದರಿಯಲ್ಲ. ಅದು ಕೇವಲ ಒಂದು ಮಿತಿ.

ನಿಮ್ಮ ಏಜೆಂಟ್ ಉಪಯುಕ್ತ ಕೆಲಸವನ್ನು ಮಾಡಬೇಕಾದ ಕ್ಷಣದಲ್ಲಿ, 'read-only' ಅದನ್ನು ತಡೆಯುತ್ತದೆ. ಒಂದು ವೇಳೆ ಏಜೆಂಟ್ ಕೆಟ್ಟ ಇಂಡೆಕ್ಸ್ (index) ಅಥವಾ ದೋಷಪೂರಿತ ಸಾಲನ್ನು (corrupted row) ಕಂಡುಕೊಂಡರೆ, ಅದನ್ನು ಸರಿಪಡಿಸಲು ಅದಕ್ಕೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಅಂದರೆ, ಬೆಂಕಿ ಇರುವುದನ್ನು ತೋರಿಸಬಲ್ಲ ಆದರೆ ಅದನ್ನು ಆರಿಸಲು ಪೈಪ್ ಹಿಡಿಯಲಾಗದ ಸಹಾಯಕನನ್ನು ನೀವು ಹೊಂದಿರುತ್ತೀರಿ ಎಂದರ್ಥ.

ತಂಡಗಳು ಹೆಚ್ಚಾಗಿ ಸೋತು ಏಜೆಂಟ್‌ಗೆ 'write access' ನೀಡುತ್ತವೆ. ಅಂದಿನಿಂದ ನಿಜವಾದ ಅಪಾಯ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

ನಿಜವಾದ ಪ್ರಶ್ನೆ "ಏಜೆಂಟ್ ಬರೆಯಬೇಕೇ?" ಎಂದಲ್ಲ. ನಿಜವಾದ ಪ್ರಶ್ನೆ "ಆ ಬರವಣಿಗೆಗಳನ್ನು (writes) ನೀವು ಹೇಗೆ ನಿಯಂತ್ರಿಸುತ್ತೀರಿ?" ಎಂಬುದಾಗಿದೆ.

ಸೂಚನೆಗಳ ಮೂಲಕ ಬರವಣಿಗೆಗಳನ್ನು ನಿಯಂತ್ರಿಸಲು ಪ್ರಯತ್ನಿಸಬೇಡಿ. "ಎಂದಿಗೂ ಟೇಬಲ್ ಅನ್ನು ಡ್ರಾಪ್ (drop) ಮಾಡಬೇಡಿ" ಎಂಬಂತಹ ನಿಯಮಗಳನ್ನು ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿ (system prompt) ಹಾಕಬೇಡಿ.

ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್ (Prompt injection) ಇಂತಹ ನಿಯಮಗಳನ್ನು ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿಸುತ್ತದೆ. ದಾಳಿಕೋರರು ಒಂದು ಡೇಟಾ ಸಾಲು ಅಥವಾ ಕಾಮೆಂಟ್ ಬಳಸಿ ನಿಮ್ಮ ನಿಯಮಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವಂತೆ ಏಜೆಂಟ್ ಅನ್ನು ವಂಚಿಸಬಹುದು. ಗಾರ್ಡ್‌ರೈಲ್ ಏಜೆಂಟ್ ಇರುವ ಅದೇ ವಿಂಡೋದಲ್ಲಿ ಇದ್ದರೆ, ಏಜೆಂಟ್ ತನ್ನ ವಾದಗಳ ಮೂಲಕ ಅದನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳಬಹುದು.

ನಿಯಂತ್ರಣವಿಲ್ಲದ ಬರವಣಿಗೆಗಳು (ungoverned writes) ಮತ್ತು ಮಧ್ಯಸ್ಥಿಕೆ ವಹಿಸಿದ ಬರವಣಿಗೆಗಳ (mediated writes) ನಡುವೆ ವ್ಯತ್ಯಾಸವಿರಬೇಕು.

• ನಿಯಂತ್ರಣವಿಲ್ಲದ ಬರವಣಿಗೆಗಳು (Ungoverned writes): ಏಜೆಂಟ್ ಒಂದು ಕಮಾಂಡ್ ಚಲಾಯಿಸಲು ನಿರ್ಧರಿಸುತ್ತದೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಇಲ್ಲಿ ಏಜೆಂಟ್‌ನ ಸ್ವಂತ ನಿರ್ಧಾರವೇ ಏಕೈಕ ನಿಯಂತ್ರಣವಾಗಿರುತ್ತದೆ. • ಮಧ್ಯಸ್ಥಿಕೆ ವಹಿಸಿದ ಬರವಣಿಗೆಗಳು (Mediated writes): ಕಮಾಂಡ್ ಏಜೆಂಟ್‌ಗೆ ಹೊರಗಿರುವ ಒಂದು ಚೆಕ್‌ಪಾಯಿಂಟ್ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ. ಈ ಚೆಕ್‌ಪಾಯಿಂಟ್ ಏಜೆಂಟ್ ಮತ್ತು ಡೇಟಾಬೇಸ್ ನಡುವಿನ ಡೇಟಾ ಪಾತ್‌ನಲ್ಲಿ (data path) ಇರುತ್ತದೆ.

ಮಧ್ಯಸ್ಥಿಕೆ ವಹಿಸಿದ ಬರವಣಿಗೆಯು ಈ ರೀತಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ:

  • ಏಜೆಂಟ್ ಒಂದು ಸ್ಟೇಟ್‌ಮೆಂಟ್ ಅನ್ನು ಪ್ರಸ್ತಾಪಿಸುತ್ತದೆ.
  • ಒಂದು ಪ್ರೊಕ್ಸಿ (proxy) ಅಥವಾ ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ ಆ ಸ್ಟೇಟ್‌ಮೆಂಟ್ ಅನ್ನು ಪಾರ್ಸ್ (parse) ಮಾಡುತ್ತದೆ.
  • ಪ್ರೊಕ್ಸಿ ಅಪಾಯವನ್ನು ವರ್ಗೀಕರಿಸುತ್ತದೆ.
  • ಅದನ್ನು ಅನುಮತಿಸಬೇಕೆ ಅಥವಾ ಮನುಷ್ಯನ ಅನುಮತಿ ಕೇಳಬೇಕೆ ಎಂಬುದನ್ನು ಪ್ರೊಕ್ಸಿ ನಿರ್ಧರಿಸುತ್ತದೆ.

ಈ ವಿಧಾನವು ನಿಮ್ಮನ್ನು ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್‌ನಿಂದ ರಕ್ಷಿಸುತ್ತದೆ. ಒಂದು ದುರುದ್ದೇಶಪೂರಿತ ಸೂಚನೆಯು ಏಜೆಂಟ್ ಅನ್ನು DROP TABLE ಕಮಾಂಡ್ ಬರೆಯುವಂತೆ ವಂಚಿಸಬಹುದು, ಆದರೆ ಅದು ಪ್ರೊಕ್ಸಿಯನ್ನು ವಂಚಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಪ್ರೊಕ್ಸಿ ಏಜೆಂಟ್‌ನ ಉದ್ದೇಶವನ್ನು ಓದುವುದಿಲ್ಲ; ಅದು ಕೇವಲ ನಿಜವಾದ SQL ಕಮಾಂಡ್ ಅನ್ನು ಮಾತ್ರ ನೋಡುತ್ತದೆ.

ಸುರಕ್ಷಿತವಾಗಿರಲು ಈ ರಚನೆಯನ್ನು ಬಳಸಿ:

  • ಸುರಕ್ಷಿತ ರೀಡ್‌ಗಳನ್ನು (reads) ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅನುಮತಿಸಿ. ಕೆಲಸ ವೇಗವಾಗಿ ನಡೆಯಲು ಏಜೆಂಟ್‌ಗಳು ಮುಕ್ತವಾಗಿ SELECT ಕ್ವೇರಿಗಳನ್ನು ಚಲಾಯಿಸಲು ಬಿಡಿ.
  • ಅಪಾಯಕಾರಿ ಬರವಣಿಗೆಗಳಿಗೆ ತಡೆಗೋಡೆ ನಿರ್ಮಿಸಿ. DELETE, UPDATE ಅಥವಾ ಸ್ಕೀಮಾ ಬದಲಾವಣೆಗಳಿಗೆ ಮನುಷ್ಯನ ಅನುಮತಿಯನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸಿ.
  • ಎಲ್ಲವನ್ನೂ ಲಾಗ್ (log) ಮಾಡಿ. ಬದಲಾವಣೆಯನ್ನು ಯಾರು ಪ್ರಸ್ತಾಪಿಸಿದರು ಮತ್ತು ಯಾರು ಅನುಮೋದಿಸಿದರು ಎಂಬುದರ ಬದಲಾಯಿಸಲಾಗದ ದಾಖಲೆಯನ್ನು ಇರಿಸಿ.

ಸುರಕ್ಷತೆಗಾಗಿ ಕೇವಲ ರೀಡ್ ರೆಪ್ಲಿಕಾಗಳನ್ನು (read replicas) ಅವಲಂಬಿಸಬೇಡಿ. ರೆಪ್ಲಿಕಾಗಳು ತನಿಖೆಗೆ ಸಹಾಯ ಮಾಡುತ್ತವೆ, ಆದರೆ ಅವು ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಪ್ರೊಡಕ್ಷನ್ ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸಲು, ನೀವು ಪ್ರೈಮರಿ ಡೇಟಾಬೇಸ್‌ಗೆ ಬರೆಯಲೇಬೇಕು.

ಮಧ್ಯಸ್ಥಿಕೆಯು (Mediation) ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಸುರಕ್ಷಿತವಾಗಿಡುತ್ತಲೇ ಏಜೆಂಟ್ ಉಪಯುಕ್ತವಾಗಿರಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

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

ಐಚ್ಛಿಕ ಕಲಿಕಾ ಸಮುದಾಯ: https://t.me/GyaanSetuAi