WEBA
חדשות·אחסון ודומיין·חדשות

קלאודפלייר תוחמת סוכני AI ל־Worker בודד ללא תשלום

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

592 מילים22 עובדות אומתו

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

סוף למפתחות של כל הבית

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

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

במקום להסתבך עם עשרות הרשאות פרטניות, החברה הגדירה ארבעה תפקידים ברורים שמכסים את שלבי העבודה. התפקידים החשובים ביותר לאוטומציה הם Editor לפריסה בטוחה בלי יכולת מחיקה, ו־Content Read-Only שמאפשר לסוכנים לקרוא קוד מבלי לגעת בו. את התפקידים אפשר להחיל ברמת הפלטפורמה כולה, ברמת המוצר, או ישירות על סקריפט ספציפי.

זה שינוי קטן בהגדרות שחוסך הרבה דאגות באבטחה.

ההבדל בין לצפות לבין לפרוס

החלוקה החדשה מתאימה לתרחישי עבודה נפוצים. כשאנשי צוות או סוכני ניטור צריכים לאתר תקלות בביצועים, הם לא זקוקים לקוד המקור. תפקיד Metadata Read-Only מאפשר להם לתחקר שאילתות ב־GraphQL API, לבדוק יומני ריצה ולנתח Traces של סקריפט ספציפי, מבלי לחשוף את הקוד של אותו שירות ומבלי לראות דבר על יישומים שכנים.

מנגד, סוכן המיועד לביקורת קוד זקוק לקריאת הקבצים אך אינו אמור לשנותם. תפקיד Content Read-Only נותן בדיוק את זה. סוכני אוטומציה יכולים מעכשיו לקרוא או לפרוס קוד לסקריפט בודד, בלי יכולת למחוק אותו ובלי לגעת בשאר השירותים בחשבון הענן שלכם. עבור תהליכי CI/CD, תפקיד Editor מאפשר לעדכן גרסה ולקנפג הגדרות, אך מונע לחלוטין מחיקה של ה־Worker והשבתה של השירות.

השוואת תפקידי הגישה החדשים של Cloudflare Workers
תפקידמה מותר לעשותלמה זה מיועד
Metadata Read-Onlyצפייה ברשימות, הגדרות, מדדים, יומנים ונתוני ניטור ללא קוד מקוראיתור תקלות וניטור שגיאות בלי לחשוף את קוד היישום
Content Read-Onlyקריאת תוכן וקוד המקור ללא יכולת שינוי או פריסהביקורת קוד בידי מפתחים או סוכני בינה מלאכותית
Editorקריאה, כתיבה, עדכון הגדרות ופריסת קוד ללא יכולת יצירה או מחיקהצינורות פריסה וסוכני פיתוח שמעדכנים גרסאות בייצור
Adminשליטה מלאה במשאב כולל מחיקה, שינוי שם והענקת הרשאות לאחריםניהול עצמאי של רכיב יחיד ללא חשיפת שאר משאבי החשבון

המוקש בניתוב ובמשאבים המקושרים

כאן מגיע הניואנס שחשוב להכיר לפני שמעדכנים את קובצי ה־Wrangler. אם ה־Worker שלכם מחובר לנתיב באמצעות Routes או Custom Domains, הרשאת Editor לסקריפט עצמו לא תספיק כדי לשנות אותם. שינוי נתיבי תעבורה עלול להפיל דומיין שלם, ולכן Cloudflare דורשת הרשאה ייעודית ברמת ה־Zone שנקראת Workers Routes.

ברגע שהנתיב מוגדר מראש, צינור הפריסה יכול להמשיך להעלות גרסאות חדשות של ה־Worker עם הרשאת Editor בלבד, כל עוד הוא אינו נוגע בחיבור הדומיין. בכל הנוגע לרכיבי Durable Objects, הם אינם מקבלים מודל הרשאות עצמאי אלא יורשים ישירות את תפקיד ה־Worker שמפעיל אותם. מי שמחזיק בהרשאת Editor יוכל לגשת לנתונים שלהם באמצעות Data Studio, בעוד שהרשאת Metadata תספק רק לוגים.

מה שקלאודפלייר עדיין לא סגרה

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

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

איך להגדיר את זה נכון

כדי להגדיר גישה ממוקדת לחבר צוות, נכנסים בלוח הבקרה אל Manage Account ואז Members, ויוצרים Policy עם התפקיד וה־Worker הספציפי. כאשר מנהלים כמה עובדים עם אותן דרישות, כדאי להשתמש ב־User Groups כדי להחיל את המדיניות על הקבוצה כולה במקום להגדיר כל משתמש בנפרד.

עבור סוכנים וצינורות CI/CD, מייצרים API Token חדש ותוחמים אותו ל־Worker הרלוונטי תחת תפקיד Editor. ההרשאות הישנות כמו Workers Scripts Edit ימשיכו לפעול ואין להן תאריך פקיעה רשמי, אך מומלץ להמיר אותן בהקדם לתפקידים החדשים כדי למנוע זליגת הרשאות מיותרת. הזמן של מפתחות לכל הבית עבר.

בינתיים, כדאי לפתוח את לוח הבקרה ולמחוק מפתחות ישנים ששכחתם מהם.

מה לעשות עכשיוהיכנסו לניהול הטוקנים ב־Cloudflare והחליפו את מפתחות ה־CI והסוכנים לתפקיד Editor המוגבל ל־Worker יחיד.

מקורות

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

מה שואלים על זה

האם צריך לשדרג לחבילת Enterprise כדי להשתמש בהרשאות לפי Worker?

לא. התפקידים החדשים והיכולת לתחום הרשאות ברמת ה־Worker הבודד זמינים לכל המשתמשים בכל החבילות, כולל החשבונות החינמיים, ללא תוספת תשלום.

מה קורה אם סוכן AI מנסה לשנות ניתוב של דומיין?

הפעולה תיכשל בשגיאת 403 Forbidden. כדי לשנות Routes או Custom Domains נדרשת הרשאת Workers Routes נפרדת ברמת ה־Zone, בנוסף להרשאת Editor על ה־Worker.

האם ההרשאה המוגבלת חלה גם על מסד הנתונים D1 שמחובר ל־Worker?

לא. משאבי אחסון כמו D1, KV ו־R2 עדיין אינם תומכים בבידוד ברמת המשאב הבודד, וההרשאות עבורם מוגדרות כרגע ברמת המוצר או החשבון כולו.

מה עושים עם טוקנים קיימים שנבנו במודל ההרשאות הישן?

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