Hermes Agent 101 EP10: Security and Sandbox: Agent ที่ทำงานจริง ต้องมี guardrails จริง

Security features ที่ซ่อนอยู่: cryptographic randomness, rate limit 1 request/user/10 นาที, lockout หลัง 5 ครั้งผิด, files chmod 0600, code ไม่ถูก log ลง stdout

—

ชั้น 2: Dangerous Command Approval

ทุก command ที่ agent จะรัน ผ่านการตรวจสอบก่อน ถ้า match กับ pattern อันตราย จะขอ approval ก่อนเสมอ

3 โหมด (config ได้ใน config.yaml):

• manual (default): ถามทุกครั้ง
• smart: ให้ LLM ช่วยตัดสิน low-risk auto-approve, dangerous auto-deny
• off: ปิดการถาม (เหมาะสำหรับ container environments)

ตัวอย่าง approval prompt (CLI):

⚠️ DANGEROUS COMMAND: recursive delete
   rm -rf /tmp/old-project

   [o]nce | [s]ession | [a]lways | [d]eny
   Choice [o/s/a/D]:

ผ่าน Telegram/Discord: แค่ตอบ yes หรือ no ในแชท

YOLO Mode: สำหรับ dev/testing รัน hermes --yolo หรือ /yolo ใน session แต่ก็ยัง block hardline blocklist อยู่

—

ชั้น 3: Hardline Blocklist (ยิ่งกว่า YOLO)

บาง command อันตรายถึงขนาดที่ไม่มีทาง bypass ได้แม้จะเปิด YOLO mode:

นี่คือ “floor สุดท้าย” ที่ไม่มีทาง override

—

ชั้น 4: Container Isolation

เมื่อใช้ terminal.backend: docker ทุก command ที่ agent รันจะอยู่ใน container ที่ hardened แล้ว:

# Security flags ที่ Hermes ใส่ให้อัตโนมัติ
--cap-drop ALL                  # drop ทุก Linux capability
--cap-add DAC_OVERRIDE          # แค่ที่จำเป็น
--security-opt no-new-privileges # block privilege escalation
--pids-limit 256                # จำกัด process count
--tmpfs /tmp:rw,nosuid,size=512m

เมื่อใช้ container backend ระบบ approval ถูก skip เพราะ container คือ security boundary แล้ว: agent ทำลายอะไรใน container ไม่กระทบ host

—

ชั้น 5: MCP Credential Filtering

MCP subprocess ได้รับเพียง environment ที่ปลอดภัยเท่านั้น (PATH, HOME, USER, etc.) API keys และ tokens ทั้งหมดถูก strip ออก

ถ้า MCP server ต้องการ credential ต้อง declare ไว้ใน config:

mcp_servers:
  github:
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "[REDACTED]"

Error messages ที่ return จาก MCP tools ถูก sanitize ก่อน ป้องกัน key leakage ผ่าน error logs

—

ชั้น 6: SSRF Protection

ป้องกัน agent จากการถูกใช้เป็น proxy ไป internal network:

• Private networks (RFC 1918): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
• Loopback: 127.0.0.0/8
• Cloud metadata: 169.254.169.254 (AWS/GCP metadata endpoint)
• DNS failures treated as blocked (fail-closed)
• Redirect chains re-validated ทุก hop

สำหรับ home lab หรือ internal setup ที่ต้องการ: security.allow_private_urls: true

—

ชั้น 7: Context File Scanning

AGENTS.md, SOUL.md, .cursorrules ถูก scan ก่อนโหลดเข้า system prompt

ป้องกัน prompt injection ประเภท:

• “จงลืม instructions เดิมทั้งหมด”
• Hidden HTML comments ที่สั่งให้อ่าน .env
• Invisible Unicode characters (zero-width space, bidirectional override)

ถ้าไฟล์ trigger ระบบ จะ block และแสดง warning แทนการโหลด

—

Terminal Backend: เลือก sandbox ตามระดับความเสี่ยง

สำหรับ production: แนะนำ docker หรือ cloud backend เพื่อให้ container คือ safety boundary หลัก

—

Production Deployment Checklist

ถ้าจะใช้ Hermes จริงในองค์กร:

• ตั้ง explicit allowlists ห้ามใช้ GATEWAY_ALLOW_ALL_USERS=true ใน production
• ใช้ container backend: terminal.backend: docker
• ตั้ง resource limits (CPU/memory/disk)
• เก็บ secrets ใน ~/.hermes/.env พร้อม chmod 600
• ใช้ DM pairing แทนการ hardcode user ID
• review command_allowlist เป็นประจำ
• รัน gateway ด้วย non-root user
• ตรวจ ~/.hermes/logs/ สม่ำเสมอ

—

สรุปสำหรับ Thai business operator

Agent ที่ทำงานได้จริงมี power มากกว่า chatbot ทั่วไปมาก แต่ power นั้นต้องมากับ responsibility

Hermes Agent ถูกออกแบบมาให้ใช้งานได้จริงโดยมี guardrails ตั้งแต่ชั้น user access ไปจนถึง container isolation และทุกชั้นตั้งค่าได้ตามระดับความเสี่ยงที่องค์กรยอมรับได้

สำหรับ SME ที่ไม่อยากตั้งค่าทุกอย่างเอง OPB Stack คือ path ที่ได้ sandbox VPS พร้อม Hermes runtime, guardrails เหล่านี้ และ AI Credits ไว้ใช้ได้เลย โดยที่ agent ของคุณมีบ้านแยกออกจาก laptop ประจำวัน

ดีที่สุดคือ เรื่อง security ที่ต้องรู้ก่อนใช้ agent จริง ไม่ใช่หลังจากเกิดปัญหาแล้วถึงมาค้นหา

—

Hermes Agent 101: จาก Chatbot สู่ AI Coworker ที่ทำงานจริง: EP10 จาก 12

[EP09: Profiles: ทำไมควรมี AI หลายบทบาท](#) | [EP11: Hermes บน VPS/Sandbox](#)

OPB Stack tie-in: Sandbox ที่ดีต้องมี proof และ approval

ICP ของ OPB Stack คือคนที่มีงานจริง มีข้อมูลจริง และเริ่มให้ AI ช่วยงานจริงแล้ว ดังนั้นเรื่อง security ไม่ใช่ภาคผนวก แต่เป็นเงื่อนไขก่อนใช้งาน

ถ้า AI coworker จะอ่านไฟล์ แก้ draft รันคำสั่ง ต่อ provider และทำงานตามเวลา มันต้องมี sandbox boundary, permission, approval gate, log และ proof artifact ให้ตรวจ

นี่คือจุดที่ OPB Stack ควรแยกตัวเองจาก chatbot ทั่วไป: ไม่ใช่ตอบเร็วกว่า แต่ทำงานในพื้นที่ที่ออกแบบมาให้เจ้าของธุรกิจควบคุมความเสี่ยงได้

ดู managed path ได้ที่ opbstack.com