# 7 כללים ל-Claude Code להגבלת ההוצאות של סוכנים אוטונומיים ב-2026

> 7 כללים להגדרת מגבלות ב-Claude Code, כדי שסוכן אוטונומי לא ישאיר אותך בלי כסף: מגבלות אצל הספק, Task Budgets, hooks, רשימות היתרים, מתגי חירום, מפתחות sandbox ומגבלות איטרציות.

Source: https://ailoot.ai/blog/he/ai-agent-burned-budget-claude-code/
Canonical: https://ailoot.ai/blog/he/ai-agent-burned-budget-claude-code/
Language: he
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-122
Revision: sha256-7e4e11066c64f9a3ec89e6ab98509cc67a3e0ce0ff741fbd4b914141ae1ac09d


<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key points in this section">

הנקודה המרכזית

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

</div>

למדו לעבוד עם השירות בתיעוד של [Ailoot](https://ailoot.ai/docs/).



## לאן הכסף הולך: 3 קטגוריות הוצאה של סוכן אוטונומי

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key points in this section">

הנקודה המרכזית

איפה סוכן אוטונומי מוציא את הכסף שלך? דרך שלושה ערוצים נפרדים: טוקנים ב-Anthropic/OpenAI, משאבי ענן (AWS/GCP/Yandex Cloud) ופעולות בתשלום בממשקי API של צד שלישי (חיובי Stripe, שערי SMS, ‏Twilio, בוטים של Telegram עם מנויים). לכל ערוץ יש מערכת חיוב משלו ודרך משלו לעצור את מסע ההוצאות.

</div>

אל תבלבלו בין שלושת הערוצים האלה—הם פועלים בנפרד ודורשים הגדרות שונות:

1. **טוקנים של LLM.** ‏Claude, ‏OpenAI או Gemini גובים על הקשר הקלט והפלט של כל בקשה. תקציבי משימות של Anthropic (ראו כלל 2) ומנוי במקום תשלום לפי שימוש ב-API יכולים לעזור כאן.
2. **תשתית ענן.** דרך MCP או כלי Bash, הסוכן יוצר משאבי EC2, ‏RDS, ‏S3 או פורס lambdas. ‏AWS Budgets, ‏GCP או Yandex Cloud עם מתג חירום יכולים לעזור כאן (כלל 5).
3. **ממשקי API של צד שלישי.** הסוכן מבצע חיוב ב-Stripe, שולח 100 הודעות SMS דרך שער או מגדיר אלף מנויים ב-Telegram. מפתחות Sandbox עם הרשאות מצומצמות ותקרה קשיחה בלוח הבקרה של הספק יכולים לעזור כאן (כלל 6).

בהמשך מופיעים 7 כללים. כל אחד מכסה ערוץ אחד או שניים.

## איך להגדיר תקרה קשיחה להוצאות API (כלל 1)

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key points in this section">

הנקודה המרכזית

איך מגדירים תקרה קשיחה להוצאות API? ל-Anthropic ול-OpenAI יש מגבלת הוצאות מובנית לארגון, שמווסתת את החשבון אוטומטית כשהוא מגיע לסכום שנקבע. אל תבלבלו אותה עם התראות, שרק שולחות אימייל. תקרה קשיחה היא מחסום; התראות הן נורית. הגדירו את שתיהן, והתחילו במחסום.

</div>

איפה מפעילים אותה (הקצו לפחות 2 דקות לכל ספק):

**Anthropic Console.** [console.anthropic.com](https://console.anthropic.com) → Settings → Limits → Monthly spend limit. קבעו סכום שאתם מוכנים להוציא בחודש הגרוע ביותר. כשהוא מגיע, ה-API מחזיר 429 ומתעד את האירוע. אין “אנסה שוב בעוד דקה”—הגישה חסומה עד סוף החודש.

**OpenAI Platform.** [platform.openai.com](https://platform.openai.com/account/billing/limits) → Billing → Usage limits. באופן דומה, יש מגבלה רכה (התראת אימייל) ומגבלה קשיחה (השבתת API). הגדירו את שתיהן; קבעו את המגבלה הקשיחה על 1.5x מהמגבלה הרכה כדי להשאיר זמן להגיב.

**AWS Bedrock / Google Vertex.** אם ניגשים ל-Claude/Anthropic דרך מתווך ענן, צריך להגדיר את התקרה הקשיחה בצד הענן, לא בצד של Anthropic. זה כלל 5.

מה **לא** נחשב לתקרה קשיחה: התראות אימייל (“ניצלתם 80% מהתקציב”). הן מגיעות באיחור, ואף אחד לא קורא אימייל בלילה. רק מחסום סינכרוני בצד הספק.

## איך פועלים תקציבי המשימות של Anthropic ואיפה מגדירים אותם (כלל 2)

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key points in this section">

הנקודה המרכזית

מהם תקציבי המשימות של Anthropic ומפני מה הם מגינים? זו תכונת בטא ב-Opus 4.7/4.8 ובקו Fable/Mythos: מגדירים תקציב לתהליך עבודה אוטונומי אחד, ו-Claude מצמצם את עומק החשיבה שלו כשהתקציב הולך ואוזל, ומשלים את המשימה באמצעות סיכום במקום לומר “זהו, נגמר לי התקציב” באמצע העבודה. זה לא פתרון לכל הבעיות של הוצאות ענן, אבל הוא מונע 80% מהמקרים שבהם הסוכן “נתקע בלולאה ולא שם לב”.

</div>

לפרטים, ראו את [התיעוד הרשמי](https://platform.claude.com/docs/en/build-with-claude/task-budgets) של Anthropic. הנקודה המרכזית: זהו **גבול רך**, לא גבול קשיח. אם הסוכן כבר יצר מופע EC2, תקציב המשימה לא יבטל זאת.

כך זה עובד בפועל: מעבירים את השדה `task_budget` במטען הבקשה (לדוגמה, 100,000 טוקני קלט לכל המשימה). Claude מקבל מידע על התקציב ו**מצמצם בעצמו את התוכניות שלו**, מפשט שלבים או מדלג על תתי-משימות. כשהתקציב מתקרב לאפס, הוא מסיים בהדרגה ומחזיר סיכום ביניים במקום “תודה שהאזנתם”.

מגבלות:

- **Anthropic API בלבד.** זה לא עובד ב-Bedrock/Vertex, שיש להם מערכות חיוב משלהם
- **מודלי בטא בלבד** (Opus 4.7, 4.8, Fable 5, Mythos 5). לא ב-Sonnet 4.6 או Haiku
- **לא מכסה הוצאות ענן או ממשקי API של צד שלישי.** אם Claude מפעיל מופע EC2, תקציב המשימה לא מגיב

השתמשו בו יחד עם כלל 1 (תקרה קשיחה), לא במקומו.

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



## מה לחסום באמצעות הוקים של PreToolUse ב-Claude Code (כלל 3)

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key points in this section">

הנקודה המרכזית

מהם הוקים של PreToolUse ב-Claude Code, ולמה צריך אותם? אלה סקריפטים שרצים **לפני** ש-Claude מבצע קריאה לכלי. הם יכולים לחסום בקשה (`exit 2`), לדרוש אישור מהמשתמש או לאפשר לה לעבור ללא שאלה. הנקודה המרכזית: ההוקים רצים לפני `--dangerously-skip-permissions`. פירוש הדבר שאפשר לחסום פעולות מסוכנות אפילו במצב עקיפת ההרשאות.

</div>

הרשאות ב-Claude Code (נכון ל-1 ביוני 2026) נבדקות בסדר **deny → ask → allow**. פירוש הדבר:

- בדקו בנפרד את מצב ההרשאות שנבחר; אין להסיק מבדיקת כלל deny במצב רגיל שקיימת אותה הגנה במצב עקיפת הרשאות
- אם הוק מחזיר `exit 2`, קריאת הכלי נחסמת
- `allowedTools` חל רק כאשר כללי deny וההוקים אינם פעילים

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

```bash
#!/usr/bin/env bash
# ~/.claude/hooks/block-dangerous-bash.sh
INPUT=$(cat)
if ! COMMAND=$(printf '%s\n' "$INPUT" | jq -er '.tool_input.command | select(type == "string")'); then
  echo "Blocked: invalid Bash hook input" >&2
  exit 2
fi

# Checks the listed text patterns; does not cover every equivalent operation
if echo "$COMMAND" | grep -qiE '(rm -rf|aws s3 rb|terraform destroy|kubectl delete|drop database)'; then
  echo "Blocked: destructive command" >&2
  exit 2
fi

exit 0
```

שמרו את הסקריפט בנתיב המצוין, ודאו ש-`jq` זמין והפכו אותו לניתן להרצה באמצעות `chmod +x ~/.claude/hooks/block-dangerous-bash.sh`. קשרו אותו ב-`~/.claude/settings.json`:

```json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "~/.claude/hooks/block-dangerous-bash.sh" }]
      }
    ]
  }
}
```

ראו את [התיעוד הרשמי](https://code.claude.com/docs/en/permissions).

בדקו ב-`/hooks` שההוק נרשם, ואז העבירו לסקריפט דוגמאות JSON לא מזיקות בלי להריץ את שדה הפקודה שלהן. צורת כתיבה הרסנית שמופיעה ברשימה אמורה להחזיר 2; פקודה לא מזיקה אמורה להחזיר 0. בדקו גם קלט פגום. הביטוי הרגולרי בודק רק קריאות Bash תואמות; לגבול ההרשאה בפועל השתמשו בפרטי גישה מוגבלים ובבידוד הסביבה. ראו את [הדוגמה הרשמית לקלט ולפלט של hook](https://code.claude.com/docs/en/hooks-guide#read-input-and-return-output).

## למה להשתמש ברשימת היתר של `allowedTools` ולמה מצב `--dangerously-skip-permissions` אינו מיועד למחשב המארח (כלל 4)

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key points in this section">

הנקודה המרכזית

איפה מגדירים את רשימת ההיתרים של הכלים המותרים, ולמה המחשב המארח אינו מקום מתאים למצב העקיפה? `allowedTools` בתוך settings.json היא רשימה של פקודות מסוימות שהסוכן יכול להריץ ללא אישור; כל דבר אחר דורש אישור. `--dangerously-skip-permissions` משבית לחלוטין את בקשת האישור, ולכן אל תפעילו אותו במחשב המארח—השתמשו בו רק במכולה או במכונה וירטואלית.

</div>

רשימת היתרים היא יישום של עקרון ההרשאות המזעריות. במקום “לאפשר הכול” (`--dangerously-skip-permissions`), הוסיפו רק את מה שהמשימה צריכה:

```json
{
  "permissions": {
    "allow": [
      "Bash(npm install:*)",
      "Bash(npm run build)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Read(./src/**)",
      "Write(./src/**)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(curl * | sh)",
      "Write(/etc/**)",
      "Write(~/.ssh/**)"
    ]
  }
}
```

מה צריך לדעת על מצב עקיפת ההרשאות:

- **Linux/macOS מסרבים להפעיל** את Claude Code במצב עקיפה כ-root או עם sudo—הגנה מובנית
- במחשב שלכם, מצב העקיפה משבית את כל בקשות האישור, והסוכן יכול להריץ `rm -rf` על כל מה שירצה, לפתוח מפתחות SSH ולהעלות נתונים לענן
- **לעולם לא** להפעיל `--dangerously-skip-permissions` במחשב המארח, אלא רק בתוך:
  - מכולת Docker עם עיגון מצומצם של אמצעי אחסון (רק התיקייה הנדרשת)
  - מכונה וירטואלית מבודדת (Multipass, Lima, Orbstack)
  - GitHub Codespaces / Replit / ארגז חול אחר

פקודת docker run מינימלית למצב עקיפה:

```bash
docker run --rm -it \
  -v "$PWD:/workspace" \
  -w /workspace \
  --network host \
  ghcr.io/anthropics/claude-code:latest \
  claude --dangerously-skip-permissions
```

אם הסוכן צריך אישורי ענן, השתמשו ב**מפתחות נפרדים בעלי הרשאות מצומצמות**, לא במפתחות הראשיים שלכם (כלל 6).

## איך להגדיר התראות תקציב ענן עם מתג חירום ב-AWS, ‏GCP ו-Yandex Cloud (כלל 5)

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key points in this section">

הנקודה המרכזית

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

</div>

כך מגדירים זאת בכל ענן:

**AWS Budgets** ([תיעוד](https://aws.amazon.com/aws-cost-management/aws-budgets/)). צרו תקציב חודשי בתוספת ספים (50%, 80%, 100%). בסף של 100%, נושא SNS יכול להפעיל Lambda לתגובה. הדוגמה הבאה משביתה רק את מפתחות הגישה של משתמש IAM ששמו מצוין; היא אינה עוצרת משאבים ואינה קובעת תקרת הוצאה קשיחה:

```python
import boto3

def lambda_handler(event, context):
    iam = boto3.client('iam')
    # Deactivate all keys for the 'claude-agent' user
    keys = iam.list_access_keys(UserName='claude-agent')['AccessKeyMetadata']
    for key in keys:
        iam.update_access_key(
            UserName='claude-agent',
            AccessKeyId=key['AccessKeyId'],
            Status='Inactive'
        )
    return {'statusCode': 200, 'body': 'IAM keys deactivated; existing resources unchanged'}
```

**נוהל מוגבל לעצירת משאבים:** בסביבת ניסוי ייעודית שמכילה מופעי EC2 מאושרים המבוססים על EBS, רשמו לפני ההרצה את החשבון, האזורים ומזהי המופעים המדויקים. במסוף EC2 בחרו רק את המופעים האלה → **Instance state → Stop instance** → אשרו, ואז ודאו שכל אחד הגיע למצב `stopped`. שמרו קודם נתונים נחוצים מאחסון instance-store; העצירה מוחקת אותם. בדקו שמתזמן מאושר או מערכת התאמת קיבולת אינם יכולים ליצור להם תחליפים. הפעולה מפסיקה את שימוש המחשוב הזה, ולא את כל חיובי החשבון: בדקו בנפרד אחסון שנשמר ושירותים אחרים. פעלו לפי [נוהל העצירה הרשמי של EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html).

[תיעוד AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html) מזהיר שהודעות מפגרות אחרי השימוש במשאבים ושעלויות נוספות עשויות להצטבר לפני ההתראה ואחריה. לכן הפעלה בסף של 100% אינה יכולה לאכוף תקרה כספית מדויקת.

**התראות תקציב ב-GCP**. צרו Budget → נושא Pub/Sub → Cloud Function שמשביתה את Service Account. עצה חשובה מהתיעוד: **התראות רק מודיעות, הן לא מכבות דברים**, ולכן Cloud Function חיונית.

**Yandex Cloud** ([תיעוד](https://yandex.cloud/ru/docs/billing/concepts/budget)). הגדירו תקציבים תחת Billing → Budgets, ובנוסף מכסות משאבים כתקרה קשיחה. אפשר לחבר התראות לבוט Telegram דרך Cloud Functions.

**OpenAI API**. מגבלות הוצאה רכות וקשיחות זמינות ישירות בלוח הבקרה—המגבלה הקשיחה עוצרת את ה-API אוטומטית; אין צורך ב-Lambda.

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

## למה סוכן צריך מפתח API נפרד של ארגז חול עם הרשאות מצומצמות (כלל 6)

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key points in this section">

הנקודה המרכזית

למה סוכן צריך מפתח API נפרד? כדי שהכשל יישאר תחום. צרו משתמש IAM או Service Account במיוחד עבור סוכן אחד, העניקו לו הרשאות מזעריות (EC2, לא *), ושייכו אותו לפרויקט חיוב נפרד עם תקרה קשיחה. אם הסוכן מנצל את כל התקציב, הוא ישרוף את 50 הדולר שלו בשעה, לא את כל התקציב של החברה.

</div>

הגדרת AWS מינימלית:

1. צרו את משתמש IAM בשם `claude-agent-scan`
2. מדיניות: רק הפעולות הנדרשות (לדוגמה, `ec2:RunInstances` באזור אחד, בגודל `t3.micro`, ללא כתובת IP ציבורית של VPC)
3. שייכו אותו לחשבון AWS נפרד (דרך Organizations) עם תקציב חודשי של 100 דולר
4. צרו מפתחות גישה ותנו אותם **רק לסוכן**; אל תשימו אותם ב-`~/.aws/credentials` שלכם
5. לאחר הסשן, החליפו את המפתחות או מחקו את המשתמש

כך גם אצל ספקים אחרים:

- **OpenAI / Anthropic:** מפתח API נפרד לכל סוכן, תקרה קשיחה לכל מפתח בלוח הבקרה, ותגיות `agent_id` במטא-נתונים של הבקשות
- **Stripe / YooKassa:** מפתח API מוגבל לפעולה אחת (לדוגמה, `charges:read` בלבד), ובמידת האפשר חשבון סוחר נפרד
- **Telegram Bot API:** אסימון בוט נפרד, לא הראשי

עקרון האבטחה הוותיק תקף גם כאן: **הרשאות מזעריות**—הסוכן מקבל בדיוק את מה שהמשימה צריכה, ולא בייט אחד יותר. אם המשימה היא “לסרוק את הרשת”, אל תתנו לו `ec2:*` ו-`s3:*`; תנו לו רק `ec2:DescribeInstances` וזהו.

## מתי להשתמש בהרצת dry run לפני ההפעלה ובהגבלת מספר האיטרציות (כלל 7)

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key points in this section">

הנקודה המרכזית

למה כדאי לתת לסוכן להציג את התוכנית לפני ההפעלה, ומהו מספר האיטרציות המרבי שכדאי להתיר? Plan Mode היא תכונה מובנית ב-Claude Code: הסוכן מתאר תחילה מה בכוונתו לעשות, ואתם מאשרים זאת. זו בדיקת הכנה בחינם. ו-`--max-turns N` מגביל את מספר השלבים בסשן אחד, כך שהסוכן לא יוכל להסתחרר לנצח. למצב אוטונומי, הגדירו 10–30 תורות, לא יותר.

</div>

Plan Mode (`/plan`) מופעל בתחילת סשן. הסוכן מכין תוכנית, מציג אותה בצ'אט, ממתין לאישור, ו**רק אז** מתחיל לעבוד. זה בחינם ומונע 70% מהמקרים של “אופס, חשבתי שהוא ישאל קודם”.

`--max-turns` הוא דגל הפעלה. כל תור הוא מחזור אחד של “הסוכן חושב + קריאה לכלי + תוצאה”. למשימות אוטונומיות:

- שינוי קטן: 5–10 תורות
- משימה בינונית: 15–30 תורות
- משימה אוטונומית גדולה: 50–80 תורות

טכניקות נוספות:

- **הגבלת זמן שעון** באמצעות הפקודה Linux `timeout`:

```bash
timeout 1800 claude --dangerously-skip-permissions --max-turns 30 -p "scan task"
# 1800 seconds = 30 minutes. Stop the process gracefully.
```

- תעדו כל קריאה לכלי בקובץ באמצעות הוק PostToolUse, כדי שתוכלו לראות בדיעבד מה קרה
- ניטור Cron—כל 5 דקות, בדקו שאין 10 תהליכי Claude שפועלים בו-זמנית (סימן אופייני לכך שמשהו השתבש)

## רשימת בדיקה מוכנה לשימוש של 5 דקות לפני הפעלת Claude Code אוטונומי

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key points in this section">

הנקודה המרכזית

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

</div>

**רשימת בדיקה לפני `claude --dangerously-skip-permissions`:**

```
[ ] 1. Hard cap at the API provider (Anthropic Console → Limits → Monthly spend limit)
[ ] 2. Task Budget in the request payload (if using Opus 4.7+/Fable/Mythos)
[ ] 3. PreToolUse hook to block rm -rf, aws s3 rb, terraform destroy
[ ] 4. allowedTools whitelist in settings.json or work inside a Docker container
[ ] 5. Delayed cloud budget alerts + tested key revocation and approved resource shutdown
[ ] 6. Sandbox API keys (a separate key for the agent, not the main one)
[ ] 7. --max-turns N + timeout NNN seconds + process cron monitoring
```

אם כל שבעת הפריטים מוכנים, צאו לדרך. אם אפילו אחד חסר, **עצרו והגדירו אותו**. שלושים דקות עכשיו עשויות לחסוך 6,000–500,000 דולר בהמשך.

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

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

קריאה נוספת:

- [איך להגן על Claude Code מפני תקלות](https://ailoot.ai/blog/he/claude-code-safe-overnight-setup/)—על `--dangerously-skip-permissions` והרשאות מזווית אחרת
- [אבטחת vibe coding](https://ailoot.ai/blog/he/vibe-coding-security/)—עמוד התווך של האבטחה
- [איך לא לשרוף את מגבלות Claude Code ביום אחד](https://ailoot.ai/blog/he/claude-code-token-limits-saving/)—על טוקנים במנוי (אל תבלבלו זאת עם המדריך הזה על חשבונות ענן)

<div class="section" role="doc-bibliography" aria-label="Sources">

### מקורות

- [מסמכי Anthropic: תקציבי משימות](https://platform.claude.com/docs/en/build-with-claude/task-budgets)
- [מסמכי Claude Code: הגדרת הרשאות](https://code.claude.com/docs/en/permissions)
- [AWS Budgets—הגדרת תקציבי עלות ושימוש מותאמים](https://aws.amazon.com/aws-cost-management/aws-budgets/)
- [Yandex Cloud: תקציבים](https://yandex.cloud/ru/docs/billing/concepts/budget)

</div>





הכירו את [Ailoot](https://ailoot.ai/).

## שאלות ותשובות: 7 כללים ל-Claude Code להגבלת ההוצאות של סוכנים אוטונומיים ב-2026

### האם ביטול מפתחות ה-IAM של הסוכן עוצר את חשבון הענן?

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

### האם הביטוי הרגולרי שבדוגמה אוכף גבול בטיחות מלא?

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


## Ailoot · החברה ופורטפוליו הפרויקטים שלה

Ailoot נשענת על ניסיון תפעולי מצטבר, בסיס לקוחות רחב, שירות יציב ובקרה שוטפת של KPI.

החברה ופורטפוליו הפרויקטים שלה: מיליוני לקוחות; מכירות בהיקף של מיליארדים מדי חודש.

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