לפני שמחברים את Lovable לארגון: מפתחות API נשארים מחוץ לפרומפט

מפתחות API אינם חומר רקע למודל. בפרויקטי Lovable ובתהליכי vibe coding, המדיניות המומלצת היא לתאר ל־AI איזה חיבור נדרש, אילו פעולות מותרות ומהם שמות ההגדרות — בלי למסור את ערכי הסודות. את פרטי הגישה יש להגדיר בנפרד, במנגנון שאושר לפרויקט, ולחבר למימוש רק בנקודה שנבדקה. לפני חיבור אב־טיפוס למערכות הארגון, דרשו בדיקה של ההרשאות, הפרדת הסביבות, התוצרים המשותפים והיכולת לבטל גישה במקרה הצורך.

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

ניהול סודות ב־vibe coding הוא החלטת עבודה, לא תיקון בסוף

במאמר של GitHub מ־7 באוקטובר 2026 מוצגת הטענה שהגנת סודות צריכה להתקדם יחד עם קצב יצירת התוכנה. לפי הטקסט שסופק, הנתונים שנבדקו לא הצביעו על מגמה מובהקת של עלייה בשכיחות סודות בכל דחיפה למאגר, אף שהיקף הפעילות גדל. המסר הרלוונטי למנהלים אינו להאשים מפתחים בחוסר זהירות, אלא להגדיר בקרות כחלק מתהליך הפיתוח עצמו. [1]

במאמר נוסף, מ־2 באוקטובר 2026, GitHub מדגישה את האחריות להגדיר משימות ל־AI, לבחון את התוצרים ולקבל החלטות טכניות, גם כאשר סוכנים מבצעים חלק מהיישום. [2] בהקשר של סודות, מומלץ לתרגם זאת לכלל פשוט: הסוכן רשאי להציע קוד לחיבור, אך אדם מוסמך מאשר את אופן הגישה ואת המעבר לנתונים ארגוניים. יצירת קוד ואישור הרשאות צריכים להיות צעדים נפרדים.

מה לא מכניסים לפרומפט — ומה מספקים במקום

קבעו שהפרומפט כולל את חוזה החיבור, ולא את האמצעי שמאפשר להשתמש בו. תארו את הפעולה העסקית, מבנה הבקשה והתשובה, מגבלות ההרשאה והתנהגות המערכת במקרה של כשל. שמרו את ערכי הגישה מחוץ לשיחה, לקבצים המצורפים ולדוגמאות. החילו את הכלל גם כשעובדים עם Copilot, ChatGPT, Claude או Claude Code: בחירת כלי אחר אינה צריכה לשנות את מדיניות שיתוף הסודות של הפרויקט.

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

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

הפרדת ניסוי וייצור: לא רק שינוי שם הסביבה

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

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

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

דוגמה מעשית: אב־טיפוס ב־Lovable להצגת סטטוס הזמנות

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

• 1. מגדירים את הצורך: הצגת מזהה הזמנה, סטטוס ותאריך עדכון באמצעות נתוני דמה. מציינים שאין צורך בפעולות כתיבה או בפרטי תשלום.
• 2. מבקשים מ־Lovable לבנות את הממשק ואת חוזה החיבור מול תגובות לדוגמה. מגדירים שם משתנה בלבד, ללא ערך גישה.
• 3. בודקים את המימוש: היכן מתבצעת הבקשה, מי רשאי להפעיל אותה, אילו נתונים מוחזרים ומה נכתב בלוגים ובהודעות שגיאה.
• 4. גורם מורשה מגדיר מפתח ניסוי במנגנון שאושר. מריצים בדיקות של הצלחה, היעדר הרשאה והגדרה חסרה, ובודקים שלא מוצגים פרטי גישה.
• 5. לפני חיבור לייצור, מאשרים את ההרשאות, מפעילים את בדיקות הסודות הזמינות ומתרגלים החלפת מפתח. רק לאחר אישור מתועד מגדירים גישה לייצור.

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

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

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

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

מומלץ לשלב בדיקות אוטומטיות עם סקירה ממוקדת של החיבור עצמו. בהתאם לדגש של GitHub על הערכת תוצרי AI, אל תהפכו תשובה של מודל נוסף לאישור סופי. [2] אפשר להיעזר בו לבחינת דפוסי הקוד, בלי למסור סודות, אך את ההחלטה שהחיבור מוכן לשיתוף או לייצור השאירו בידי הגורמים שהוגדרו לכך.

תגובה לחשיפה: מכינים את הנוהל לפני שמזינים מפתח

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

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

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

המלצות לארגון: רשימת הבדיקות לפני החיבור הראשון

חלקו אחריות באופן ברור: הצוות העסקי מגדיר את הפעולה ואת המידע הנחוצים; הצוות הטכנולוגי בודק את מסלול החיבור ואת הטיפול בסודות; גורם האבטחה מאשר חריגים; ובעלי המערכת מאשרים את ההרשאות. בהכשרות ובתבניות העבודה של Operator AI, מומלץ למקד את התרגול ברגעים שבהם מתעורר הפיתוי להדביק מפתח: פתרון שגיאה, חיבור ראשון והכנת הדגמה.

• האם הצורך העסקי מוגדר, והגישה המבוקשת מוגבלת למה שנדרש עבורו?
• האם האב־טיפוס פועל בסביבת ניסוי עם נתונים ופרטי גישה שאושרו?
• האם תועד מקום אחסון הסוד, מי רשאי להשתמש בו ומי רשאי להחליפו?
• האם נבדק שהערך אינו מופיע בפרומפטים, בקוד משותף, בתוצרי דפדפן או בפלטים?
• האם נבדקו הרשאות הסוכנים, המאגר וסביבת ההדגמה?
• האם יש אישור טכנולוגי לחיבור ונוהל זמין לטיפול בחשיפה?

לסיכום, ניהול סודות ב־vibe coding צריך להיות תנאי מעבר מאב־טיפוס לחיבור ארגוני, ולא משימת ניקיון לאחר מכן. בנו את הממשק בעזרת AI, תארו את החיבור ללא ערכי גישה, והעבירו את הסודות רק במנגנון שנבדק ואושר. כשהאחריות, ההרשאות ודרך הביטול מוגדרות מראש, לצוותים יש בסיס ברור להחלטה אם להתקדם — או לעצור לתיקון לפני החיבור.