Read-Only Isn't Enough: Guardrails for AI Agents
מהנדסים בכירים אומרים לעיתים קרובות דבר אחד כדי לשמור על סוכני AI בטוחים: תנו להם גישה לקריאה בלבד (read-only).
זה נשמע בטוח. הסוכן יכול לחקור שאילתות איטיות או לסכם סכמות (schemas) מבלי לשבור דבר.
אבל גישת "קריאה בלבד" אינה מודל בטיחות. היא מגבלה.
ברגע שהסוכן שלכם צריך לבצע עבודה מועילה, גישת הקריאה בלבד עוצרת אותו. אם סוכן מוצא אינדקס פגום או שורה פגומה, הוא לא יכול לתקן אותה. אתם מסתיימים עם עוזר שמצביע על שריפה אך אינו יכול להרים צינור.
צוותים רבים מוותרים ומעניקים לסוכן גישת כתיבה. שם מתחילה הסכנה האמיתית.
השאלה האמיתית אינה "האם הסוכן צריך לכתוב". השאלה האמיתית היא "איך מנהלים (govern) את הכתיבות הללו".
אל תנסו לנהל כתיבות באמצעות הוראות. אל תשימו כללים ב-system prompt כמו "לעולם אל תמחקו טבלה (never drop a table)".
Prompt injection הופך את הכללים הללו לחסרי תועלת. תוקף יכול להשתמש בשורת נתונים או בהערה כדי להטעות את הסוכן ולגרום לו להתעלם מהכללים שלכם. אם מנגנון ההגנה (guardrail) נמצא באותו חלון כמו הסוכן, הסוכן יכול "להתווכח" איתו ולעקוף אותו.
אתם זקוקים להבחנה בין כתיבות לא מנוהלות (ungoverned writes) לבין כתיבות מתווכות (mediated writes).
• כתיבות לא מנוהלות: הסוכן מחליט להריץ פקודה, והמסד נתונים מבצע אותה. הבקרה היחידה היא השיקול הדעת של הסוכן עצמו. • כתיבות מתווכות: הפקודה עוברת דרך נקודת ביקורת (checkpoint) מחוץ לסוכן. נקודת הביקורת הזו נמצאת בנתיב הנתונים (data path) שבין הסוכן למסד הנתונים.
כתיבה מתווכת עובדת כך:
- הסוכן מציע הצהרה (statement).
- פרוקסי (proxy) או מישור בקרה (control plane) מנתחים את ההצהרה.
- הפרוקסי מסווג את הסיכון.
- הפרוקסי מחליט אם לאפשר זאת או לבקש אישור מאדם.
גישה זו מגנה עליכם מפני prompt injection. הוראה זדונית עשויה להטעות את הסוכן לכתיבת פקודת DROP TABLE, אך היא לא יכולה להטעות את הפרוקסי. הפרוקסי לא קורא את הכוונה של הסוכן; הוא רק בוחן את פקודת ה-SQL בפועל.
השתמשו במבנה הזה כדי להישאר בטוחים:
- אישור אוטומטי לקריאות בטוחות. אפשרו לסוכנים להריץ שאילתות SELECT בחופשיות כדי לשמור על עבודה מהירה.
- חסימת כתיבות מסוכנות. דרישת אישור אנושי עבור DELETE, UPDATE, או שינויים בסכמה (schema).
- תיעוד (Log) של הכל. שמרו רישום בלתי ניתן לשינוי (immutable) של מי הציע שינוי ומי אישר אותו.
אל תסתמכו על עותקי קריאה (read replicas) לצורך בטיחות. עותקים עוזרים בחקירה, אך הם אינם יכולים ליישם תיקונים. כדי לתקן בעיה בסביבת ייצור (production), עליכם לכתוב למסד הנתונים הראשי (primary database).
תיווך מאפשר לסוכן להיות מועיל תוך שמירה על בטיחות הנתונים שלכם.
Optional learning community: https://t.me/GyaanSetuAi
