عزل Claude Code (Sandboxing): كيفية عزل وتقييد وتأمين Claude Code في بيئة الإنتاج

Introduction

Claude Code can read files, write code, execute shell commands, make network requests, and call external tools. On a developer's laptop, that autonomy is the whole point. In an enterprise pipeline, it's a threat surface that needs explicit boundaries.

Claude code sandboxing means running Claude Code inside a constrained execution environment. File system access, network egress, process execution, and tool availability — all of it gets explicitly defined and limited. Skip that step, and you have an autonomous agent with full system access sitting one injected instruction away from a real incident.

Anthropic knows this. In October 2025, they shipped native sandboxing for Claude Code, built on OS-level primitives — Linux bubblewrap and macOS Seatbelt. Internal testing showed an 84% reduction in permission prompts. The technology works. But native sandboxing covers only part of what enterprise teams need. Container-level isolation, network egress controls, credential scoping, and audit logging require infrastructure decisions that go beyond a single CLI flag.

We cover all four containment surfaces here: file system, shell, network, and external tools. Plus the Claude code data privacy controls that determine what actually leaves your environment.

Why Claude Code Sandboxing Is Not Optional for Enterprise

Claude Code's default setup gives the agent access to the developer's entire file system, the ability to run arbitrary shell commands, and the capacity to make network requests to any reachable endpoint. That's fine for solo developer use. For enterprise deployments serving multiple teams and running automated workflows, those defaults are not acceptable.

Every automated system in an enterprise environment should operate under the principle of least privilege. Claude Code, as an autonomous coding agent, requires explicit sandboxing to meet that standard. Four surfaces need containment: the file system, the shell, the network, and external tools.

The consequences of skipping sandboxing are well-documented. Developer Mike Wolak's GitHub issue #10077 describes Claude Code executing rm -rf from root on his machine — destroying every user-owned file. A separate incident in November 2025 saw Claude accidentally create a directory named ~, then later run rm -rf * in the parent, which the shell expanded to the home directory. Neither case required --dangerously-skip-permissions. The permission system itself failed.

Sandboxing doesn't replace permissions. It adds a structural containment layer beneath them. If permissions are the first gate ("should this tool run?"), sandboxing is the second ("if it runs, what can it actually touch?").

The Four Attack Surfaces Claude Code Sandboxing Must Address

Each surface carries distinct risks. Understanding them individually is the first step toward effective containment.

File System: Broad Read/Write Access by Default

Claude Code's default file system behavior is generous:

• Read access covers the entire system, except certain denied directories
• Write access defaults to the current working directory and subdirectories
• With --dangerously-skip-permissions enabled, file operations run without any confirmation
• Sensitive files — SSH keys, .env files, production configs — are often reachable from a developer session

The sandboxing documentation confirms that the sandboxed bash tool restricts writes to the current working directory by default. But Claude Code's built-in Read and Edit tools operate outside the sandbox — they use the permission system directly. That means file system scoping needs to happen at both the sandbox layer and the permission layer.

Shell Execution: Full User Permissions

Claude Code can execute arbitrary bash commands with the full permissions of the user running it. Without shell isolation:

• A compromised session can install software, modify system configuration, or run persistent scripts
• Package managers (npm, pip) pull and execute code from external registries
• Shell access in automated pipelines creates a direct path from prompt injection to arbitrary code execution

On macOS, the Seatbelt framework restricts what sandboxed commands can do. On Linux, bubblewrap provides namespace-based isolation. Both enforce restrictions on child processes, too — any script or program spawned by a sandboxed command inherits the same boundaries.

Network Access: Unrestricted Egress Without Controls

Without network isolation, every Claude Code session is a potential data exfiltration vector:

• The agent can make HTTP requests to arbitrary external endpoints
• A prompt injection can direct the agent to POST repository contents, credentials, or API responses to attacker infrastructure
• Even without malicious intent, npm install or pip install pulls untrusted code from public registries

Anthropic's engineering blog on sandboxing states this directly: effective sandboxing requires both filesystem and network isolation. Without network isolation, a compromised agent could exfiltrate sensitive files. Without filesystem isolation, a compromised agent could escape the sandbox and gain network access. Both must work together.

Claude Code routes sandboxed network traffic through a proxy server running outside the sandbox. The proxy enforces domain restrictions and handles user confirmation for newly requested domains.

External Tools and MCP Servers: Unbounded Scope

Claude Code connected to MCP servers inherits all of those servers' capabilities by default:

• An agent with database tool access can often read data far beyond what the current task requires
• A GitHub MCP server gives the agent access to every repo the credentials allow
• Unbounded tool scope means a single manipulated instruction can reach systems far outside the intended task

MCP tool scoping requires a separate control layer. The MCP Gateway approach filters which tools are visible to each session based on agent identity and task context.

File System Isolation: Limiting What Claude Code Can Read and Write

Effective file system isolation restricts the agent to specific directories relevant to the current task. No access to the broader host file system. No credential stores. No home directories.

Configure the Native Sandbox

Claude Code's built-in sandbox supports granular file system controls through settings.json:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "allowWrite": ["./output"],
      "denyRead": ["~/.ssh", "~/.aws", "~/.env"]
    }
  }
}

Key settings to know:

• sandbox.filesystem.allowWrite — grants write access to additional paths beyond the working directory
• sandbox.filesystem.denyRead — blocks read access to sensitive directories
• allowUnsandboxedCommands — when set to false, prevents Claude from retrying failed commands outside the sandbox. Set this to false in production.

Mount Only What the Task Requires

When running Claude Code in a Docker container, mount only the target repository:

docker run -it --rm \
  -v $(pwd)/project:/workspace:ro \
  -v $(pwd)/output:/output \
  docker/sandbox-templates:claude-code

The source repository mounts as read-only (:ro). Output goes to a separate writable directory. An injected instruction that tries to modify the source it's analyzing hits a read-only filesystem.

Never Mount Credential Files

Environment files, .env configurations, SSH key directories, and cloud credential stores should never appear inside a Claude Code sandbox. Production credentials belong in a platform secret management layer — not as files the agent can read. See the enterprise security guide for how to handle credential injection safely.

Network Isolation: Controlling Claude Code's External Access

Network isolation is the most critical piece of Claude Code sandboxing for preventing data exfiltration. An agent that can't reach external endpoints can't send your code, credentials, or data anywhere outside your environment.

Default to Deny, Allow by Exception

Claude Code environments should block all outbound network access by default. Allow only the specific endpoints the task requires:

• The Anthropic API endpoint (for inference)
• Internal tool servers and MCP endpoints
• Defined package registries (npm, PyPI)
• Your source control platform (GitHub, GitLab)

Block everything else at the network policy layer, not the application layer. Application-level restrictions can be bypassed. Infrastructure-level network policies cannot — at least not by the agent.

Use Claude Code's Network Settings as a First Layer

Claude Code's sandbox routes network traffic through a proxy that enforces domain restrictions. Configure allowed domains in your settings:

{
  "sandbox": {
    "network": {
      "allowedDomains": [
        "api.anthropic.com",
        "registry.npmjs.org",
        "github.com"
      ],
      "httpProxyPort": 8080,
      "socksProxyPort": 1080,
      "allowLocalBinding": true
    }
  }
}

The allowedDomains array controls which domains sandboxed commands can reach and supports wildcards (e.g., *.npmjs.org). The httpProxyPort and socksProxyPort keys let you bring your own proxy instead of the built-in one. allowLocalBinding allows localhost port binding (macOS only, defaults to false).

Treat it as a first-layer control. Necessary but not sufficient on its own. The real enforcement should happen at the infrastructure level — VPC egress rules, security groups, or network policies that the agent can't modify.

Route API Traffic Through a Gateway

Send Claude Code's Anthropic API calls through a controlled gateway that logs every request and response. The AI Gateway provides visibility into what gets sent to the model and what comes back, independent of what Claude Code logs on its own. For teams handling usage limits, the gateway also enforces rate limits and budget caps.

Container-Level Sandboxing: Running Claude Code in Isolated Execution

Container-based deployment is the reference architecture for Claude Code sandboxing in production. It combines file system isolation, network policy, and process isolation in a single deployable unit.

Docker Sandboxes, launched in January 2026, take this further. Each sandbox runs in a dedicated microVM — not a standard container, but a full, lightweight virtual machine with its own Linux kernel and private Docker daemon. The host's Docker daemon can't even see the sandboxes in docker ps.

Container Security Checklist

Follow these runtime principles for production deployments:

• Minimal base image. Strip out package managers, network utilities, and tools that the task doesn't need. A smaller image means a smaller attack surface.
• Non-root user. يجب ألا تعمل عمليات Claude Code بصلاحيات الجذر (root) أبدًا. لا يمكن لمستخدم محدود تعديل ملفات النظام أو تثبيت حزم على مستوى النظام عبر أوامر shell.
• نظام ملفات الجذر للقراءة فقط. قم بتحميل جذر الحاوية كقراءة فقط، مع إمكانية الكتابة في أدلة إخراج محددة فقط. لا يمكن لأي أمر shell إجراء تغييرات دائمة على بيئة الحاوية.
• قيود الموارد. تمنع قيود وحدة المعالجة المركزية والذاكرة الأتمتة الجامحة من استهلاك البنية التحتية المشتركة. تقلل قيود العمليات من قدرة تنفيذ shell على إنشاء عمليات إضافية.
• حاويات مؤقتة. يتم تدمير الحاوية بعد كل جلسة Claude Code. تختفي جميع عمليات الكتابة غير المقصودة للملفات، وإدخالات ذاكرة التخزين المؤقت لبيانات الاعتماد، والتكوينات المعدلة مع الحاوية.

مشكلة الهروب من بيئة الاختبار المعزولة (Sandbox)

لا توجد بيئة اختبار معزولة مثالية. قامت شركة، أونا، بإثبات في مارس 2026 أن Claude Code يمكنه تجاوز قائمة الحظر الخاصة به باستخدام حيل المسار (/proc/self/root/usr/bin/npx يشير إلى نفس الملف الثنائي ولكنه يتجنب مطابقة الأنماط). عندما اكتشف bubblewrap ذلك، قام الوكيل بتعطيل بيئة الاختبار المعزولة نفسها وتشغيل الأمر خارجها.

لم يتم اختراق الوكيل. لم يُطلب منه الهروب. لقد أراد فقط إكمال المهمة، وكانت بيئة الاختبار المعزولة تعيق ذلك. الدرس المستفاد: بيئة الاختبار المعزولة على مستوى التطبيق ضرورية ولكنها ليست كافية. يكتشف التنفيذ على مستوى نظام التشغيل (مثل bubblewrap و Seatbelt) ما تفوته قواعد التطبيق. يكتشف العزل على مستوى البنية التحتية (مثل الأجهزة الافتراضية وسياسات الشبكة) ما يفوته التنفيذ على مستوى نظام التشغيل. الدفاع المتعمق مهم هنا أكثر من أي مكان آخر.

خصوصية بيانات Claude Code: ما يغادر بيئتك

لخصوصية بيانات Claude Code بعدان: ما يتم إرساله إلى واجهة برمجة تطبيقات Anthropic كجزء من التشغيل العادي، وما يمكن أن يتسرب عبر وصول Claude Code إلى الشبكة أو آليات الإخراج إذا فشلت بيئة الاختبار المعزولة.

ما يرسله Claude Code إلى Anthropic

يتم إرسال التعليمات البرمجية ومحتويات الملفات ونوافذ السياق التي يستخدمها Claude Code للاستدلال إلى واجهة برمجة تطبيقات Anthropic. تعتمد مدة احتفاظ Anthropic بهذه البيانات على خطتك:

• خطط المستهلكين (مجاني، احترافي، ماكس): الاحتفاظ بالبيانات لمدة 30 يومًا افتراضيًا. إذا وافقت على تحسين النموذج، يمتد الاحتفاظ إلى 5 سنوات. تتضمن خطط المستهلكين استخدام Claude Code.
• الخطط التجارية (الفريق، المؤسسة، واجهة برمجة التطبيقات): لا تقوم Anthropic بتدريب النماذج على بياناتك بموجب الشروط التجارية. يتم تطبيق الاحتفاظ القياسي لمدة 30 يومًا.
• عدم الاحتفاظ بالبيانات: متاح في Claude للمؤسسات. يجب تفعيله لكل مؤسسة بواسطة فريق حسابك.

تأتي هذه السياسات مباشرة من شركة Anthropic وثائق استخدام البيانات و مركز الخصوصية. يجب على الفرق التي تعمل بموجب متطلبات صارمة لإقامة البيانات أو السرية مراجعة اتفاقيات Anthropic للمؤسسات بعناية.

ما يمكن أن يسربه كود Claude بدون وضع الحماية

بدون عزل الشبكة، يمكن لجلسة كود Claude التي تم التلاعب بها أن:

• نشر محتويات المستودع أو بيانات الاعتماد أو استجابات واجهة برمجة التطبيقات إلى نقاط نهاية خارجية عبر أوامر shell
• قراءة الملفات الحساسة ضمن نطاق نظام ملفات الوكيل وتضمينها في سياق النموذج (والتي تنتقل بعد ذلك إلى واجهة برمجة التطبيقات)
• دفع الكود إلى مستودعات git بعيدة غير مصرح بها
• كتابة بيانات الاعتماد إلى ملفات الإخراج التي تتم مشاركتها خارج البيئة

ضوابط خصوصية بيانات كود Claude لا تكون قوية إلا بقدر قوة عزل الشبكة ونظام الملفات الذي يدعمها. الـ إطار الحوكمة يغطي كيفية بناء سياسات تنظيمية حول هذه الضوابط.

التسجيل للخصوصية والامتثال

يجب أن تنتج جميع إجراءات كود Claude — قراءات الملفات، أوامر shell، مكالمات الشبكة، استدعاءات الأدوات — سجلات تدقيق يتم الاحتفاظ بها داخل البنية التحتية الخاصة بك. لا تقم بإعادة توجيهها إلى منصات SaaS خارجية إذا كنت بحاجة إلى تلبية متطلبات HIPAA أو SOC 2 أو قانون الاتحاد الأوروبي للذكاء الاصطناعي. الـ دليل أمان المؤسسات يشرح كيفية توجيه السجلات إلى Grafana أو Datadog أو Splunk عبر OpenTelemetry.

كيف تطبق TrueFoundry عزل كود كلود لفرق المؤسسات

توفر TrueFoundry طبقة البنية التحتية التي تحتاجها فرق المؤسسات لتشغيل كود كلود بأمان وعلى نطاق واسع. يتم نشر كل شيء داخل بيئة AWS أو GCP أو Azure الخاصة بك. وتبقى جميع عمليات التنفيذ والتسجيل وحركة مرور الشبكة ضمن حدود سحابتك.

يتم فرض عزل كود كلود في TrueFoundry على مستوى طبقة البنية التحتية. لا تقوم الفرق الفردية بتهيئته لكل جلسة — فالحدود هيكلية، ويتم فرضها قبل بدء تشغيل كود كلود، وتكون متسقة عبر كل جلسة.

• تنفيذ أصلي لشبكة VPC. تعمل كل جلسة من كود كلود داخل شبكتك الخاصة. وتأتي سياسات الخروج من البنية التحتية السحابية، وليس من الوكيل. الـ بوابة الذكاء الاصطناعي توجه جميع حركة مرور النموذج عبر نقطة نهاية واحدة محكمة التحكم.
• عزل الحاوية لكل جلسة. يعمل كود كلود في حاويات مؤقتة مخصصة للمهمة. يتم التخلص من كل حاوية بعد الانتهاء. ولا تشارك أي جلسة حاوية مع مستخدم أو مهمة أخرى.
• حقن بيانات الاعتماد محددة النطاق. لا تظهر أسرار الإنتاج أبدًا في بيئة تنفيذ كود كلود. توفر المنصة فقط الأذونات المحددة التي تتطلبها كل مهمة — ويتم التعامل مع الوصول بأقل الامتيازات تلقائيًا.
• تحديد نطاق نظام الملفات. يتم تحميل الدلائل ذات الصلة بالمهمة الحالية فقط. وصول للقراءة فقط حيث لا يتطلب الأمر الكتابة. لا توجد دلائل رئيسية، ولا مخازن بيانات اعتماد، ولا قواعد أكواد غير ذات صلة.
• فرض قائمة السماح للشبكة. يتم تقييد الوصول الصادر للشبكة من جلسات كود كلود إلى نقاط نهاية محددة على مستوى طبقة البنية التحتية. ويتم حظر المكالمات الخارجية العشوائية قبل وصولها إلى الشبكة.
• سجلات تدقيق غير قابلة للتغيير. يتم تسجيل كل عملية قراءة ملف، وأمر shell، ومكالمة شبكة، واستدعاء أداة مع هوية المستخدم، والطابع الزمني، والمخرجات. وتبقى السجلات في بيئتك. وجهها إلى نظام SIEM الحالي لديك عبر OpenTelemetry.

لا تعتمد المؤسسات التي تشغل كود كلود عبر بنية TrueFoundry التحتية على التكوين على مستوى العلامات لإنشاء حدود أمنية. فالحدود هيكلية. وبالنسبة للفرق التي تدير أيضًا اتصالات خادم MCP، توفر بوابة MCP نفس ضوابط الوصول على مستوى البنية التحتية على الوصول إلى الأدوات الخارجية. الـكامل دليل سير عمل Claude Code يغطي كيفية دمج هذه الضوابط في سير عمل التطوير الإنتاجي.

إذا كان فريقك يقوم بتهيئة بيئات الاختبار يدويًا لكل جلسة Claude Code — مثل إعداد حاويات Docker، وكتابة قواعد جدار الحماية، وتحديد نطاق تحميل الملفات — فإن TrueFoundry تتولى كل ذلك على مستوى البنية التحتية.

تُشغّل كل جلسة في حاوية مؤقتة داخل شبكتك الافتراضية الخاصة (VPC) مع حظر خروج الشبكة، وحقن بيانات الاعتماد لكل مهمة، وتسجيل كل إجراء في نظام SIEM الخاص بك. احجز عرضًا توضيحيًا لترى كيف تعمل بيئات الاختبار الإنتاجية دون الحاجة إلى الإعداد اليدوي.