עקרונות אבטחה

betool מתוכננת לסביבות מפוקחות. האבטחה אינה שכבה שנוספה בדיעבד: היא האינווריאנט המבני של כל שורת קוד, כל מיגרציה, כל מודול.

1. מולטי-טננט קפדני

כל ארגון מחזיק בנתוניו שלו — פייפליינים, סודות, קבצים ומפתחות LLM. הבידוד מיושם:

• ברמת מסד הנתונים — כל טבלאות העסק נושאות עמודת org_id עם אינדקס, והשאילתות בצד השרת מסננות תמיד לפי הארגון של הסשן הפעיל.
• ברמת מערכת הקבצים — לכל ארגון שורש אחסון נפרד תחת <data_root>/orgs/<org_id>/. אין נתיב משותף.
• ברמת הקאש — קאשים per-org; אין רשומה משותפת ללא דגל is_shared = TRUE מפורש.
• ברמת הסודות — לכל ארגון כספת נפרדת, מפתחות API משלו, טוקנים משלו. אין fallback גלובלי.

2. ביקורת חובה לגישות cross-tenant

לתפקידים מסוימים (בדרך כלל מפעילי הפלטפורמה בצד ה-vendor) עשויה להידרש גישה לתוכן של ארגון אחר לצרכי תמיכה. גישה זו:

• מותנית ב-opt-in מצד הארגון היעד — ניתן לביטול בכל עת דרך פאנל הניהול.
• נרשמת ביומן עבור כל גישה — טבלת ביקורת ייעודית, מסוננת לפי ארגון יעד, חשופה ללקוחות דרך נתיב GET‏ /api/admin/me/*-reads.
• נדחית אם הביקורת נכשלת — אין קריאה ללא עקבה.

ראו ביקורת GDPR.

3. סירוב מנומק לפעולות הרסניות

כל פעולה שמשמידה או מחליפה תוכן של ארגון אחר (REPLACE-IN-PLACE, DELETE) נדחית אם הארגון היעד לא הפעיל את ה-opt-in לקריאה. הסיבה: ללא נראות, המפעיל מציע בעיוורון payload שעלול לדרוס את הקיים.

4. ריבונות מודלי LLM

• BYOK נייטיב — מפתחות OpenAI, Anthropic, Mistral שלכם מנוהלים על ידי הארגון שלכם. אין דליפה cross-org.
• מודלים פרטיים ב-Enterprise — Ollama, vLLM מאוחסנים אצלכם או בענן הפרטי שלכם. הפרומפטים וההשלמות לא יוצאים לעולם מהפרימטר שלכם.
• אין pool משותף שקוף — אם ארגון משתמש במודל shared, מדובר בהחלטה מפורשת עם בקרת גישה.

עמדת ההנדסה

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

בפועל, בכל בחירה ארכיטקטונית / קוד / פרומפט:

מנטרה: «אם מישהו מוצא באג, זה מפני שלא שמנו מספיק ערבויות — לא מפני שהכנסנו יותר מדי.»

להעמקה נוספת

• בידוד מולטי-טננט
• ביקורת GDPR ויומן גישה
• פריסה ריבונית