AI Database Agents — Agent שעובד מול DB בצורה בטוחה

מאת צוות מדיה דיל · 09.08.2026 · AI · 8 דק׳

לתת ל-agent גישה עצמאית למסד נתונים זה שדרוג פרודוקטיביות אדיר וגם סיכון אבטחה משמעותי. איך בונים agent שחוקר, שואל ומתקן בלי לסכן נתוני אמת בפרודקשן.

תארו agent AI שמקבל משימה כמו "תבדוק למה יש ירידה בהרשמות החדשות השבוע ותציע הסבר מבוסס נתונים". כדי לבצע את זה הוא צריך לחקור את הסכימה, לכתוב כמה שאילתות ניסיוניות, לבדוק תוצאות ביניים, אולי לתקן שאילתה שנכשלה, ולבנות מסקנה. זה תהליך אג'נטי אמיתי - לא בקשת NL2SQL בודדת אלא לולאה של חקירה. הפער בין "agent שעוזר לחקור נתונים" ל"agent שמסכן את הפרודקשן" הוא לא בכוונות שלו אלא בארכיטקטורת ההרשאות וה-tools שנותנים לו.

הפוטנציאל כאן גדול: אנליסט אנושי שהיה מבלה שעה בחקירת נתונים יכול לקבל טיוטת ניתוח תוך דקות, ולהתמקד בבדיקה ובשיפוט במקום באיסוף גולמי. אבל בדיוק בגלל שה-agent פועל בעצמאות ולוקח החלטות עצמאיות לגבי אילו שאילתות להריץ, כל טעות בעיצוב ההרשאות שלו יכולה להתבטא בתקלה אמיתית - לא רק תשובה שגויה, אלא עומס על מסד production או חשיפת נתונים שאסור לו לראות. מדריך זה מסביר איך לבנות agent כזה כך שהיכולת העצמאית שלו לא הופכת לסיכון.

מה ההבדל בין NL2SQL ל-Database Agent

NL2SQL הוא בקשה בודדת: שאלה נכנסת, שאילתה יוצאת. Database Agent הוא תהליך איטרטיבי: הוא יכול להריץ שאילתת גישוש, לבחון את התוצאה, להחליט שהיא לא רלוונטית ולנסות זווית אחרת, לשלב כמה שאילתות למסקנה אחת. זה דורש ארכיטקטורת agent אמיתית - תכנון, כלים, וזיכרון לאורך השיחה - כפי שמתואר במדריך הארכיטקטורה האג'נטית ובAgent Planning.

מבחינה מעשית, זה אומר שה-agent צריך זיכרון עבודה לאורך המשימה - לזכור אילו שאילתות כבר הריץ, אילו תוצאות כבר קיבל, ואילו כיוונים כבר נבדקו ונמצאו לא רלוונטיים - כדי לא לחזור על אותה חקירה שוב ושוב. הרחבה על סוגי הזיכרון הנדרשים במדריך Agent Memory Architecture. עבור משימות ארוכות במיוחד, כדאי גם לתכנן checkpoints שמאפשרים להמשיך חקירה שנקטעה בלי להתחיל מאפס - ראו Agent Checkpoints.

למה agent גולמי מול DB זה מסוכן

הפיתוי הגדול הוא לתת ל-agent "כלי SQL כללי" - פונקציה יחידה שמקבלת מחרוזת SQL כלשהי ומריצה אותה. זה נראה גמיש ונוח לפיתוח מהיר, אבל זה בדיוק ההיפך מארכיטקטורה בטוחה: בלי הפרדה בין סוגי פעולות, אי אפשר לשים guardrails ממוקדים - כל בקרה חייבת לנתח את תוכן ה-SQL בזמן ריצה, מה שקל לעקוף (בכוונה או בטעות) ויקר לתחזק.

הגישה הנכונה, גם אם היא דורשת יותר עבודת פיתוח מראש, היא לבנות tools ממוקדים - כל אחד עם היקף פעולה מוגדר וברור, במקום כלי גנרי אחד שהכל עובר דרכו. ההבדל בין שתי הגישות דומה להבדל בין נתינת מפתח לדלת אחת ספציפית לבין נתינת צרור מפתחות גנרי לכל הבניין ותקווה שהמשתמש יפתח רק את הדלת הנכונה.

ארכיטקטורת ה-Tools

במקום לתת ל-agent גישה גולמית למסד, בונים לו סט tools מוגדר וממודד:

• schema_explorer - מחזיר מבנה טבלאות רלוונטיות, בלי לחשוף את כל הסכימה בכל פעם
• query_runner - מריץ SQL עם timeout, LIMIT קשיח, והרשאות read-only
• explain_plan - מחזיר את עלות השאילתה לפני הרצה בפועל
• sample_data - מחזיר מדגם קטן מטבלה לצורך הבנת ערכים אפשריים

ההפרדה הזו ל-tools ממוקדים, במקום "כלי SQL כללי", היא מה שמאפשר לשים guardrails ברמת כל כלי בנפרד - עקרון שמפורט בFunction Calling מעמיק ובSecure Function Calling. חשוב גם להגדיר לכל tool תיאור ברור ל-LLM על מתי להשתמש בו ומתי לא - תיאורים מעורפלים גורמים ל-agent לבחור בכלי הלא נכון או לדלג על שלבי בדיקה חיוניים.

לולאת Plan-Execute-Verify

agent database טוב לא רק מריץ שאילתות - הוא בונה תוכנית קודם ("אני צריך לבדוק קודם את התפלגות ההרשמות לפי יום, ואז לפלח לפי מקור תנועה"), מבצע שלב אחד בכל פעם, ומאמת שהתוצאה הגיונית לפני שהוא ממשיך. כשתוצאה נראית חשודה (למשל מספר שלילי במקום שאמור להיות תמיד חיובי), ה-agent צריך לזהות את זה ולחקור מחדש במקום להמשיך עם נתון שגוי - זה עקרון ה-Agent Reflection וVerifier Models מיושם בהקשר נתונים.

ניהול תור השאילתות ומגבלות משאבים

agent שחוקר באופן איטרטיבי יכול, מטבע תהליך החקירה, לנסות כמה גישות שונות עד שהוא מוצא את הזווית הנכונה - וזה אומר יותר שאילתות מאשר משתמש אנושי היה מריץ ידנית. לכן חשוב להטיל מגבלת תקציב מפורשת על כל משימת חקירה: מספר מקסימלי של שאילתות, זמן כולל מקסימלי, וסך "עלות" מצטברת (משוקללת לפי EXPLAIN) שהמשימה מורשית לצרוך. כשה-agent מגיע לתקרה, הוא צריך לעצור ולדווח מה הוא כבר גילה, במקום להמשיך לצרוך משאבים בלי הגבלה - עקרון שמקביל לניהול עלויות AI ברמת המשימה הבודדת.

Approval Gates לפעולות עם השפעה

גם כשמדובר ב-agent שמוגדר כ-read-only לחלוטין, יש רגעים שדורשים אישור אנושי - למשל כשהמסקנה שהוא מגיע אליה תשמש להחלטה עסקית משמעותית, או כשהוא מבקש להרחיב את היקף החקירה לטבלאות רגישות שלא היו בתכנון המקורי. תבנית ה-Approval Gates מגדירה נקודות עצירה מפורשות שבהן ה-agent חייב לקבל אישור לפני שהוא ממשיך, ולא רק ליישם את זה כ"רעיון טוב" אלא כמנגנון טכני אכיף - ראו מדריך Approval Gates.

מיפוי מפורש של רמת הסיכון לכל סוג משימה, ותרגום שלו לרמת הפיקוח הנדרשת, הוא חלק בלתי נפרד מעיצוב מערכת agent. משימות עם השפעה נמוכה (חקירה אקספלורטיבית פנימית) יכולות לרוץ באוטונומיה גבוהה יחסית עם רק סקירה בדיעבד; משימות שהתוצאה שלהן תשפיע על החלטה עסקית או תוצג ללקוח דורשות נקודת בדיקה אנושית לפני שהמסקנה יוצאת לדרך.

בטיחות: Least Privilege, Sandboxing ו-Observability

ה-DB user שה-agent פועל דרכו חייב להיות מוגדר בצמצום מרבי: read-only, מוגבל לטבלאות ספציפיות, עם row-level security לפי הרשאות המשתמש שביקש את המשימה. שאילתות כתיבה, אם בכלל מותרות, רצות אך ורק דרך tool נפרד עם אישור אנושי מפורש. העקרונות המלאים נמצאים בZero Trust ל-AI Agents ובLeast Privilege Agents. חשוב גם להריץ את שכבת ה-query runner בתוך sandbox מבודד עם רשת מוגבלת - ראו מדריך AI Sandboxing.

כל שאילתה שה-agent מריץ, כל תוצאה שהוא קיבל וכל החלטה שהוא קיבל על סמך התוצאה - צריכים להיות מתועדים בלוג מובנה שניתן לחפש בו בדיעבד. זה קריטי גם לדיבוג וגם לצרכי ביקורת. הרחבה מלאה במדריך LLM Observability ובAI Audit Logs.

שילוב עם שכבות ה-AI האחרות

Database agent כמעט אף פעם לא פועל בבידוד - הוא בדרך כלל חלק מ-agent גדול יותר או מערכת multi-agent (ראו Multi-Agent Systems) שבה agent אחד אחראי על חקירת נתונים, agent אחר על ניסוח המסקנה בשפה טבעית, ואולי agent שלישי על יצירת ויזואליזציה. הפרדת האחריות הזו מאפשרת לתת ל-agent החוקר הרשאות מצומצמות מאוד, בעוד agents אחרים שלא נוגעים ישירות בנתונים לא נחשפים למסד כלל. תזמור נכון בין ה-agents האלה מפורט במדריך Agent Orchestration.

מניעת Side Effects לא רצויים

גם שאילתת קריאה "תמימה" יכולה להזיק - סריקת טבלה ענקית בלי אינדקס יכולה להעמיס על replica ולהאט מערכות אחרות שתלויות בה. לכן כל שאילתה שה-agent מריץ עוברת קודם דרך explain_plan, ואם העלות המוערכת חורגת מסף מוגדר, המערכת דוחה את הריצה ומבקשת מה-agent לצמצם את היקף השאילתה - לדוגמה, להוסיף תנאי סינון או להקטין טווח תאריכים - לפני שהיא מאשרת הרצה. חשוב שה-agent יקבל את הודעת הדחייה בצורה מובנית שהוא יכול לפעול לפיה, לא רק קוד שגיאה גנרי.

נקודה נוספת שקל לפספס: agent שרץ בלולאת חקירה עלול, בלי מגבלות, לבצע שאילתות מקבילות שכל אחת לכשעצמה זולה אך יחד יוצרות עומס מצטבר משמעותי. לכן כדאי להגביל גם את מספר השאילתות הבו-זמניות שה-agent רשאי להריץ, ולא רק את העלות של כל שאילתה בודדת - הגבלה שמתאימה במיוחד למערכות שבהן כמה משימות agent רצות במקביל על אותה תשתית.

טעויות נפוצות

• כלי SQL גנרי במקום tools ממוקדים - מה שהופך כל בקרת אבטחה לתלוית ניתוח תוכן דינמי במקום אכיפה ברמת הכלי.
• חוסר תקציב חקירה - agent שממשיך לחקור ללא הגבלה, צורך משאבים ומעכב תשובה במקום לעצור ולדווח.
• אין verification על תוצאות ביניים - agent שממשיך לבנות מסקנה על נתון שגוי במקום לזהות אנומליה ולחקור מחדש.
• הרשאות רחבות מדי "ליתר ביטחון" - מתן גישה לכל הטבלאות כדי "לא להגביל" את החקירה, במקום להתחיל מהיקף מצומצם ולהרחיב לפי צורך.
• העדר audit trail - לא ניתן לשחזר בדיעבד אילו שאילתות ה-agent הריץ ולמה הגיע למסקנה מסוימת.

דוגמה מהשטח

נחזור לדוגמה מתחילת המאמר. agent שמקבל את המשימה "תבדוק למה יש ירידה בהרשמות" יתחיל לרוב בשאילתת schema_explorer כדי לוודא הבנה נכונה של הטבלאות הרלוונטיות. בשלב הבא ירוץ sample_data כדי להבין את טווח הערכים האפשריים. רק אז יתחיל לבנות שאילתות אגרגציה בפועל דרך query_runner, קודם ברמה גסה ואז מתמקד יותר ויותר. בכל שלב, כל שאילתה עוברת דרך explain_plan לפני הרצה, ותוצאת כל שלב נשמרת בזיכרון העבודה כדי שהוא לא יחזור על אותה בדיקה פעמיים. בסיום, ה-agent מרכיב מסקנה עם הפניה מפורשת לשאילתות שהוא הסתמך עליהן - שרשרת נימוקים ניתנת לביקורת, לא תשובה סתמית.

שאלות נפוצות

האם agent database יכול לקבל הרשאות כתיבה?

רק דרך tool נפרד ומבודד עם human-in-the-loop לפני כל הרצה - לא כחלק מזרימת החקירה הרגילה שלו.

איך מונעים מ-agent להריץ שאילתה שתעמיס על המסד?

באמצעות שלב EXPLAIN חובה לפני כל הרצה, עם סף עלות שמעליו השאילתה נדחית אוטומטית וה-agent מתבקש לצמצם היקף.

מה ההבדל בין database agent ל-NL2SQL רגיל?

NL2SQL עונה על שאלה בודדת בשאילתה בודדת. Database agent מבצע תהליך חקירה איטרטיבי עם כמה שאילתות, בדיקת תוצאות ביניים ותיקון עצמי.

איך מוודאים שה-agent לא חושף נתונים שהמשתמש לא אמור לראות?

באמצעות row-level security ברמת המסד עצמו, לפי זהות המשתמש שיזם את הבקשה - לא הסתמכות על ה-agent "לזכור" להסתיר.

מה קורה אם ה-agent "נתקע" בלולאת חקירה בלי להגיע למסקנה?

מגדירים תקציב חקירה מפורש שכשהוא מתמלא, ה-agent נדרש לעצור ולדווח מה נמצא עד כה.

איך שונה database agent מדשבורד BI רגיל?

דשבורד BI עונה על שאלות מוגדרות מראש בתצוגה קבועה; database agent מבצע חקירה אד-הוק וגמישה לפי שאלה חופשית, ומסוגל להתאים את הגישה שלו תוך כדי תנועה לפי מה שהוא מגלה בדרך.

האם צריך צוות ייעודי כדי לתחזק agent כזה?

לא בהכרח - ברגע שהתשתית (tools, guardrails, observability) בנויה נכון, תחזוקה שוטפת מתמקדת בעדכון ספריית הדוגמאות ובבחינה תקופתית של הרשאות ותקציבי החקירה.

Database agents הם אחד הכלים החזקים ביותר לצמצום זמן ניתוח נתונים בארגון - כשהם נבנים עם ארכיטקטורת הרשאות נכונה. הצוות של מדיה דיל בונה מערכות כאלה מאפס, כולל שכבת האבטחה. אפשר לדבר איתנו בוואטסאפ, או להכיר את פתרונות ה-AI והאבטחה שלנו.

תגיות: AI database agents · database agent · agentic SQL · least privilege · AI sandboxing · query safety

← חזרה לבלוג · צור קשר