การ Deploy AI Agents อย่างปลอดภัย

คู่มือการรักษาความปลอดภัย Claude Code และ Agent SDK deployments ด้วย isolation, credential management และ network controls

Claude Code และ Agent SDK เป็นเครื่องมือที่ทรงพลังซึ่งสามารถรันโค้ด เข้าถึงไฟล์ และ interact กับ external services แทนคุณ เหมือนเครื่องมือใดก็ตามที่มีความสามารถเหล่านี้ การ deploy อย่างรอบคอบจะช่วยให้คุณได้รับประโยชน์ในขณะที่รักษาการควบคุมที่เหมาะสม

ต่างจากซอฟต์แวร์ดั้งเดิมที่ปฏิบัติตาม code paths ที่กำหนดไว้ เครื่องมือเหล่านี้สร้างการกระทำแบบ dynamic ตาม context และเป้าหมาย ความยืดหยุ่นนี้เป็นสิ่งที่ทำให้มีประโยชน์ แต่ยังหมายความว่าพฤติกรรมของมันอาจได้รับอิทธิพลจากเนื้อหาที่ประมวลผล: ไฟล์ หน้าเว็บ หรือ user input ซึ่งบางครั้งเรียกว่า prompt injection เช่น หาก README ของ repository มีคำสั่งที่ผิดปกติ Claude Code อาจนำคำสั่งเหล่านั้นไปรวมในการกระทำในแบบที่ operator ไม่ได้คาดหวัง คู่มือนี้ครอบคลุมวิธีปฏิบัติที่ช่วยลดความเสี่ยงนี้

ข่าวดีคือการรักษาความปลอดภัย agent deployment ไม่ต้องการ infrastructure พิเศษ หลักการเดียวกับการรันโค้ด semi-trusted ใดๆ ก็ใช้ได้ที่นี่: isolation, least privilege และ defense in depth Claude Code มีคุณสมบัติด้านความปลอดภัยหลายอย่างที่ช่วยกับข้อกังวลทั่วไป และคู่มือนี้จะแนะนำสิ่งเหล่านี้พร้อมกับตัวเลือก hardening เพิ่มเติมสำหรับผู้ที่ต้องการ

ไม่ใช่ทุก deployment ที่ต้องการความปลอดภัยสูงสุด นักพัฒนาที่รัน Claude Code บน laptop ของตนเองมีความต้องการที่แตกต่างจากบริษัทที่ประมวลผลข้อมูลลูกค้าในสภาพแวดล้อม multi-tenant คู่มือนี้นำเสนอตัวเลือกตั้งแต่คุณสมบัติด้านความปลอดภัย built-in ของ Claude Code ไปจนถึงสถาปัตยกรรม production ที่ hardened เพื่อให้คุณเลือกสิ่งที่เหมาะกับสถานการณ์ของคุณ

Threat Model

Agents สามารถดำเนินการที่ไม่ได้ตั้งใจเนื่องจาก prompt injection (คำสั่งที่ฝังในเนื้อหาที่ประมวลผล) หรือ model error Claude models ออกแบบมาเพื่อต้านทานสิ่งนี้ ดู model overview และ system card สำหรับ model ที่คุณ deploy เพื่อรายละเอียดการประเมิน

Defense in depth ยังคงเป็นแนวปฏิบัติที่ดีอยู่ดี ตัวอย่างเช่น หาก agent ประมวลผลไฟล์ที่เป็นอันตรายที่สั่งให้ส่งข้อมูลลูกค้าไปยัง external server network controls สามารถบล็อก request นั้นได้โดยสมบูรณ์

คุณสมบัติด้านความปลอดภัย Built-in

Claude Code มีคุณสมบัติด้านความปลอดภัยหลายอย่างที่จัดการกับข้อกังวลทั่วไป ดู security documentation สำหรับรายละเอียดเต็ม

Permissions system: tool และ bash command ทุกอย่างสามารถกำหนดให้ allow, block หรือ prompt ผู้ใช้เพื่อขออนุมัติ ใช้ glob patterns เพื่อสร้างกฎเช่น "allow all npm commands" หรือ "block any command with sudo" Organizations สามารถตั้งนโยบายที่ใช้กับผู้ใช้ทั้งหมด ดู permissions
Command parsing สำหรับ permissions: ก่อนรัน bash commands Claude Code จะ parse คำสั่งเป็น AST และ match ผลลัพธ์กับกฎ permission ของคุณ คำสั่งที่ไม่สามารถ parse ได้อย่างสะอาดหรือไม่ตรงกับ allow rule ต้องได้รับการอนุมัติอย่างชัดเจน
Web search summarization: ผลการค้นหาถูก summarize แทนที่จะส่ง raw content เข้า context โดยตรง ซึ่งลดความเสี่ยงของ prompt injection จากเนื้อหาเว็บที่เป็นอันตราย
Sandbox mode: Bash commands สามารถรันในสภาพแวดล้อม sandboxed ที่จำกัด filesystem และ network access ดู sandboxing documentation สำหรับรายละเอียด

หลักการด้านความปลอดภัย

สำหรับ deployments ที่ต้องการ hardening เพิ่มเติมนอกเหนือจาก defaults ของ Claude Code หลักการเหล่านี้จะแนะนำตัวเลือกที่มี

Security Boundaries

Security boundary แยก components ที่มี trust levels ต่างกัน สำหรับ deployments ที่มีความปลอดภัยสูง คุณสามารถวาง sensitive resources (เช่น credentials) ไว้นอก boundary ที่มี agent อยู่ หากบางอย่างผิดพลาดใน environment ของ agent resources ที่อยู่นอก boundary นั้นยังคงได้รับการปกป้อง

Least Privilege

เมื่อจำเป็น คุณสามารถจำกัด agent ให้มีเฉพาะ capabilities ที่จำเป็นสำหรับงานเฉพาะของมัน:

Resource	ตัวเลือกการจำกัด
Filesystem	Mount เฉพาะ directories ที่จำเป็น โดยเลือก read-only
Network	จำกัดไปยัง endpoints เฉพาะผ่าน proxy
Credentials	Inject ผ่าน proxy แทนการเปิดเผยโดยตรง
System capabilities	Drop Linux capabilities ใน containers

Defense in Depth

สำหรับสภาพแวดล้อมที่มีความปลอดภัยสูง การใช้หลายการควบคุมร่วมกันให้การปกป้องเพิ่มเติม ตัวเลือกรวมถึง:

Container isolation
Network restrictions
Filesystem controls
Request validation ที่ proxy

Isolation Technologies

Isolation technologies ต่างๆ มีการ tradeoff ระหว่างความแข็งแกร่งด้านความปลอดภัย performance และความซับซ้อนในการดำเนินงาน

info

ในทุกการกำหนดค่าเหล่านี้ Claude Code (หรือ Agent SDK application ของคุณ) รันอยู่ภายใน isolation boundary (sandbox, container หรือ VM) การควบคุมความปลอดภัยที่อธิบายด้านล่างจำกัดสิ่งที่ agent สามารถเข้าถึงได้จากภายใน boundary นั้น

Technology	ความแข็งแกร่งของ Isolation	Performance overhead	ความซับซ้อน
Sandbox runtime	ดี (secure defaults)	ต่ำมาก	ต่ำ
Containers (Docker)	ขึ้นอยู่กับการตั้งค่า	ต่ำ	ปานกลาง
gVisor	ดีเยี่ยม (พร้อมการตั้งค่าที่ถูกต้อง)	ปานกลาง/สูง	ปานกลาง
VMs (Firecracker, QEMU)	ดีเยี่ยม (พร้อมการตั้งค่าที่ถูกต้อง)	สูง	ปานกลาง/สูง

Sandbox Runtime

สำหรับ isolation น้ำหนักเบาโดยไม่ต้องใช้ containers sandbox-runtime บังคับใช้ filesystem และ network restrictions ที่ระดับ OS

ข้อได้เปรียบหลักคือความเรียบง่าย: ไม่ต้องมีการกำหนด Docker, container images หรือการตั้งค่า networking proxy และ filesystem restrictions ถูก built in

วิธีการทำงาน:

Filesystem: ใช้ OS primitives (bubblewrap บน Linux, sandbox-exec บน macOS) เพื่อจำกัดการเข้าถึง read/write ไปยัง paths ที่กำหนด
Network: ลบ network namespace (Linux) หรือใช้ Seatbelt profiles (macOS) เพื่อ route traffic ผ่าน built-in proxy
Configuration: JSON-based allowlists สำหรับ domains และ filesystem paths

การตั้งค่า:

npm install @anthropic-ai/sandbox-runtime

Containers

Containers ให้ isolation ผ่าน Linux namespaces Container แต่ละอันมี view ของ filesystem, process tree และ network stack ของตัวเอง ในขณะที่แชร์ host kernel

การกำหนด container ที่ hardened ด้านความปลอดภัยอาจมีลักษณะดังนี้:

docker run \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --security-opt seccomp=/path/to/seccomp-profile.json \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /home/agent:rw,noexec,nosuid,size=500m \
  --network none \
  --memory 2g \
  --cpus 2 \
  --pids-limit 100 \
  --user 1000:1000 \
  -v /path/to/code:/workspace:ro \
  -v /var/run/proxy.sock:/var/run/proxy.sock:ro \
  agent-image

Option	วัตถุประสงค์
`--cap-drop ALL`	ลบ Linux capabilities เช่น `NET_ADMIN` และ `SYS_ADMIN` ที่อาจ enable privilege escalation
`--security-opt no-new-privileges`	ป้องกัน processes ไม่ให้ได้รับ privileges ผ่าน setuid binaries
`--security-opt seccomp=...`	จำกัด syscalls ที่มี
`--read-only`	ทำให้ root filesystem ของ container เป็น immutable
`--tmpfs /tmp:...`	ให้ writable temporary directory ที่ถูกล้างเมื่อ container หยุด
`--network none`	ลบ network interfaces ทั้งหมด
`--memory 2g`	จำกัดการใช้ memory
`--pids-limit 100`	จำกัดจำนวน process เพื่อป้องกัน fork bombs
`--user 1000:1000`	รันในฐานะ non-root user
`-v ...:/workspace:ro`	Mount โค้ดแบบ read-only

gVisor

Standard containers แชร์ host kernel: เมื่อโค้ดภายใน container ทำ system call มันจะไปที่ kernel เดียวกับที่รัน host โดยตรง gVisor แก้ปัญหานี้โดยการ intercept system calls ใน userspace ก่อนที่จะถึง host kernel

เพื่อใช้ gVisor กับ Docker ให้ติดตั้ง runtime runsc และกำหนด daemon:

// /etc/docker/daemon.json
{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc"
    }
  }
}

จากนั้นรัน containers ด้วย:

docker run --runtime=runsc agent-image

ข้อพิจารณาด้าน Performance:

Workload	Overhead
CPU-bound computation	~0%
Simple syscalls	~2× ช้าลง
File I/O intensive	สูงถึง 10-200× ช้าลง

Virtual Machines

VMs ให้ hardware-level isolation ผ่าน CPU virtualization extensions VM แต่ละอันรัน kernel ของตัวเอง ซึ่งสร้าง boundary ที่แข็งแกร่ง

Firecracker ออกแบบมาสำหรับ lightweight microVM isolation สามารถ boot VMs ภายใน 125ms โดยมี memory overhead น้อยกว่า 5 MiB

Cloud Deployments

สำหรับ cloud deployments คุณสามารถรวม isolation technologies ข้างต้นกับ cloud-native network controls:

รัน agent containers ใน private subnet ที่ไม่มี internet gateway
กำหนด cloud firewall rules (AWS Security Groups, GCP VPC firewall) เพื่อบล็อก egress ทั้งหมดยกเว้นไปยัง proxy ของคุณ
รัน proxy (เช่น Envoy พร้อม credential_injector filter) ที่ validate requests, บังคับใช้ domain allowlists, inject credentials และ forward ไปยัง external APIs
กำหนด IAM permissions น้อยที่สุดให้กับ service account ของ agent
Log traffic ทั้งหมดที่ proxy เพื่อวัตถุประสงค์ audit

Credential Management

Agents มักต้องการ credentials เพื่อเรียก APIs เข้าถึง repositories หรือ interact กับ cloud services ความท้าทายคือการให้ access นี้โดยไม่เปิดเผย credentials เอง

The Proxy Pattern

แนวทางที่แนะนำคือการรัน proxy นอก security boundary ของ agent ที่ inject credentials เข้า outgoing requests Agent ส่ง requests โดยไม่มี credentials, proxy เพิ่มเข้าไป และ forward request ไปยังปลายทาง

การกำหนด Claude Code ให้ใช้ Proxy

Claude Code รองรับสองวิธีในการ route sampling requests ผ่าน proxy:

Option 1: ANTHROPIC_BASE_URL (ง่ายแต่สำหรับ sampling API requests เท่านั้น)

export ANTHROPIC_BASE_URL="http://localhost:8080"

Option 2: HTTP_PROXY / HTTPS_PROXY (system-wide)

export HTTP_PROXY="http://localhost:8080"
export HTTPS_PROXY="http://localhost:8080"

Credentials สำหรับ Services อื่น

นอกจาก sampling จาก Claude API แล้ว agents มักต้องการ authenticated access ไปยัง services อื่น เช่น git repositories, databases และ internal APIs มีสองแนวทางหลัก:

Custom Tools

ให้ access ผ่าน MCP server หรือ custom tool ที่ route requests ไปยัง service ที่รันอยู่นอก security boundary ของ agent

Traffic Forwarding

สำหรับการแก้ไข HTTPS traffic ไปยัง arbitrary services โดยไม่ใช้ custom tool คุณต้องมี TLS-terminating proxy ที่ decrypt traffic, inspect หรือแก้ไข จากนั้น re-encrypt ก่อน forward สิ่งนี้ต้องการ:

รัน proxy นอก container ของ agent
ติดตั้ง CA certificate ของ proxy ใน trust store ของ agent
กำหนด HTTP_PROXY/HTTPS_PROXY เพื่อ route traffic ผ่าน proxy

Filesystem Configuration

Read-only Code Mounting

เมื่อ agent ต้องการวิเคราะห์โค้ดแต่ไม่แก้ไข ให้ mount directory แบบ read-only:

docker run -v /path/to/code:/workspace:ro agent-image

warning

แม้การเข้าถึงแบบ read-only ไปยัง code directory สามารถเปิดเผย credentials ไฟล์ทั่วไปที่ควร exclude หรือ sanitize ก่อน mount:

ไฟล์	ความเสี่ยง
`.env`, `.env.local`	API keys, database passwords, secrets
`~/.git-credentials`	Git passwords/tokens แบบ plaintext
`~/.aws/credentials`	AWS access keys
`~/.config/gcloud/application_default_credentials.json`	Google Cloud ADC tokens
`~/.azure/`	Azure CLI credentials
`~/.docker/config.json`	Docker registry auth tokens
`~/.kube/config`	Kubernetes cluster credentials
`.npmrc`, `.pypirc`	Package registry tokens
`*-service-account.json`	GCP service account keys
`.pem`, `.key`	Private keys

Writable Locations

หาก agent ต้องการเขียนไฟล์ คุณมีหลายตัวเลือก สำหรับ ephemeral workspaces ใน containers ให้ใช้ tmpfs mounts:

docker run \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /workspace:rw,noexec,size=500m \
  agent-image

Threat Model​

คุณสมบัติด้านความปลอดภัย Built-in​

หลักการด้านความปลอดภัย​

Security Boundaries​

Least Privilege​

Defense in Depth​

Isolation Technologies​

Sandbox Runtime​

Containers​

gVisor​

Virtual Machines​

Cloud Deployments​

Credential Management​

The Proxy Pattern​

การกำหนด Claude Code ให้ใช้ Proxy​

Credentials สำหรับ Services อื่น​

Custom Tools​

Traffic Forwarding​

Filesystem Configuration​

Read-only Code Mounting​

Writable Locations​

อ่านเพิ่มเติม​