สายเครื่องมือสี่เส้นผ่านประตูกั้นแคบลงหลายชั้น โดยสายหนึ่งพยายามออกนอกทางและถูกคันจับสีอำพันหยุดไว้
aiagentclaude-codeanthropicsecuritypermissionstooling

Claude Code 2.1.290 ขันสิทธิ์ ps, GitHub host และ path prefix—ค่าเริ่มต้นดีขึ้นแต่ policy ยังต้องคุม

พี่โชว์Engineering

Anthropic ออก Claude Code 2.1.290 วันที่ 6 ตุลาคมตามเวลาไทย โดยมี change log ยาว แต่จุดสำคัญด้าน boundary คือคำสั่ง ps หลายรูปแบบถาม approval มากขึ้น, built-in gh api ใน cloud session ปฏิเสธ host อื่นถ้าตั้งผ่าน GH_HOST/GH_REPO, repository config ตั้ง CLAUDE_CODE_DISABLE_ATTACHMENTS ไม่ได้แล้ว, custom connection จำกัด path prefix ได้ และตัวอย่าง managed agents ปิด web tools เมื่อไม่จำเป็นครับ

ผมตรวจ release 2.1.290, npm package, checksum/signature assets, permission docs และ advisories แบบอ่านอย่างเดียว ไม่ติดตั้งหรือรัน candidate รุ่นนี้ ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ แต่ plugin, hooks, MCP, web และ shell ยังขยาย authority ได้เมื่อผู้ใช้อนุญาต

สรุป 30 วินาที

  • ps บางรูปแบบเคยผ่านเป็น read-only ตอนนี้ถาม approval มากขึ้น เพราะ process listing อาจเปิด command line, username และข้อมูล workload ที่มีค่า
  • cloud-session gh api ปฏิเสธ host อื่นเมื่อเปลี่ยนผ่าน environment โดยเงียบ ต้องใช้ --hostname หรือ URL เต็ม ทำให้ปลายทางเห็นชัดในคำสั่ง
  • repository .claude/settings* ตั้งตัวแปรปิด attachments ไม่ได้ เหลือ shell/user/managed settings ลดโอกาส repo เปลี่ยน privacy posture ของ client
  • custom connections ใน Claude Tag เพิ่ม path prefixes ทำให้ allow rule ไม่ต้องครอบทั้ง host
  • ตัวอย่าง Managed Agents เปลี่ยนให้ปิด web tools เมื่อไม่จำเป็นและใช้ permission policy auto เป็นแนวทาง least capability ที่ดีขึ้น
  • asset claude-darwin-arm64.tar.gz มี SHA-256 f5315ca0…dc63d6bc; มี SHASUMS256.txt และ signature asset แยกสำหรับตรวจ provenance

ทำไมเกี่ยวกับคุณ

AI agent ที่อ่าน process list, เรียก GitHub API, เปิดเว็บและรัน plugin มีภาพระบบกว้างกว่าผู้ช่วยเขียนโค้ดธรรมดา ความเสี่ยงไม่ได้อยู่ที่แต่ละฟีเจอร์โดด ๆ แต่อยู่ที่การต่อกัน: ข้อมูลจาก process หรือเว็บอาจกลายเป็น prompt แล้วนำไปสู่ shell/GitHub action

เหมือนพนักงานที่มีคีย์การ์ดหลายชั้น การเพิ่มประตูดีขึ้นแต่ถ้าออกบัตร master ให้ทุกงาน ประตูทั้งหมดไม่มีความหมาย ทีมจึงต้องกำหนด policy ส่วนกลางและยอมให้ session ขอ escalation เฉพาะจังหวะ ไม่ฝากความปลอดภัยไว้กับคำเตือนที่คนรีบอาจกดผ่าน

ทำงานยังไง: ประตูสี่ชั้น

ชั้นแรกคือข้อมูลเข้า ps ดูเหมือนอ่านอย่างเดียวแต่ command line อาจมี token หรือ path ลับ การถาม approval มากขึ้นทำให้ผู้ใช้เห็นว่ากำลังสำรวจ process boundary ชั้นสองคือปลายทาง GitHub การบังคับ host ให้ explicit ลดกรณี env จาก repo เปลี่ยน API host โดยไม่เด่น

ชั้นสามคือ configuration precedence ค่า privacy/control ที่ repository ไม่ควรเปลี่ยนถูกย้ายให้ shell/user/managed settings ที่ authority สูงกว่า ชั้นสี่คือ connection path prefix: host เดียวอาจมี API หลายเส้น การจำกัด /approved/project/ ดีกว่าอนุญาตทั้ง domain แต่ยังต้องระวัง redirect, encoding และ path normalization

การปิด web tools ในตัวอย่าง managed agents สะท้อนหลัก capability: ถ้างานอ่าน repository และรัน test ได้โดยไม่ browse ก็ไม่ควรให้ egress เพิ่ม หากต้องใช้ web ให้แยก agent/step ที่มี domain allowlist และอย่าส่ง secret จาก workspace ไปกับ query

หลักฐานที่ตรวจ

Release v2.1.290 มาจาก repository anthropics/claude-code และแจกแจง change ด้าน permission, host, attachment setting, connection paths, web budget และ plugin/hook behavior ผมยึดถ้อยคำจาก changelog ไม่เหมารวมว่าทุกการเปลี่ยนเป็น security fix

GitHub release มี per-asset SHA-256: macOS arm64 คือ f5315ca0b8d87d89022e0f4e53c30c8be3ab9ad7373154ef56313deadc63d6bc; SHASUMS256.txt มี digest 5aa0357b…a6b244e และไฟล์ signature แยก digest 7a2607de…26f0fd หลักฐานนี้ตรวจ supply chain ได้เมื่อ install pipeline ตรวจลายเซ็นกับ key ที่องค์กรยืนยัน

npm metadata เป็นอีกช่องทาง ต้องตรวจ integrity/signature ของ tarball ที่ใช้จริง หน้า advisories ไม่พบ high/critical ที่ระบุว่ากระทบ 2.1.290 โดยไม่มี mitigation ณ วันที่ตรวจ แต่ plugin และ dependency ภายนอกมี advisory lifecycle ของตนเอง

จาก publisher, repository, tag/changelog, release checksums/signature artifact, registry provenance, permission docs และ advisory review รุ่นนี้จึง ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ 2026-10-06 ไม่ใช่การรับรอง runtime ทุก configuration

เงินและผลกระทบ

การถาม approval มากขึ้นอาจเพิ่ม friction แต่ช่วยลดข้อมูลรั่วจากคำสั่งที่คนเคยมองว่า harmless วัดทั้ง approval rate, denial, false prompt, time-to-task และ incident signal อย่าปรับ allowlist ให้กว้างเพียงเพื่อลดจำนวน popup

path-scoped connection ลด blast radius โดยตรง หาก credential ใช้ได้ทั้ง host ก็ยังควรออก token ที่ scope แคบที่สุด ให้ network proxy ตรวจ destination จริง และบันทึก tool call แบบ redact เพื่อหาความผิดปกติหลัง rollout

สิ่งที่ยังไม่ชัดและแหล่งข่าวพูดไม่ตรงกัน

Changelog บอกว่า ps รูปแบบเพิ่มขึ้นถาม approval แต่ไม่ให้รายการ grammar ทั้งหมด ทีมต้องทดสอบ pipeline, alias, absolute path และ wrapper scripts ใน policy ของตนเอง คำว่า read-only ใน tool ไม่เท่ากับ non-sensitive ในองค์กร

การปฏิเสธ alternate GitHub host ผ่าน environment ยังอนุญาต --hostname หรือ full URL แบบ explicit นั่นคือ visibility improvement ไม่ใช่ deny-all ต้องมี host allowlist ระดับ managed policy/proxy หาก enterprise ห้าม GitHub Enterprise หรือโดเมนอื่น

Path prefix ช่วยจำกัด route แต่ไม่ได้พิสูจน์ authorization ปลายทางและอาจเจอ normalization/redirect edge case ส่วน plugin hooks ที่ clip ข้อความยาวแทน drop เพิ่ม observability แต่ log อาจเก็บข้อมูลลับมากขึ้น ต้องตรวจ retention/redaction

วิธีใช้ให้ปลอดภัยขึ้น

  1. pin 2.1.290 และตรวจ checksum/signature หรือ npm integrity ตาม channel จริง
  2. ใช้ managed settings ล็อก deny/allow rules ที่ repository แก้ไม่ได้ และห้าม bypass permissions ใน workspace จริง
  3. ตั้ง shell/network/web เป็น deny by default เปิด ps และ web ต่อ task พร้อม log เหตุผล
  4. allowlist GitHub host และ path prefix ที่จำเป็น ตรวจ redirect/URL normalization ที่ proxy ด้วย
  5. audit plugin, hook, MCP และ marketplace ก่อนติดตั้ง แยก credential ต่อ extension และปิด auto-update เมื่อ provenance ยังไม่ตรวจ
  6. ใช้ token อายุสั้น scope แคบ ไม่วาง secret ใน command line, process env กว้าง หรือไฟล์ที่ agent อ่านได้
  7. ให้ push, publish, deploy, account/permission change ผ่าน human approval และ CI เดิม

แล้วเราควรทำอะไร

เจ้าของเครื่องนักพัฒนาควรอัปเดตในกลุ่มเล็กก่อน แล้ว replay งานที่เคยขออนุญาตผิดรูปแบบโดยใช้ repository ทดลอง ตรวจทั้งคำสั่งที่ควรผ่าน คำสั่งที่ควรถูกถาม และคำสั่งที่ต้องถูกปฏิเสธ องค์กรควรล็อก policy สำคัญนอก repository เพราะ repository เป็นข้อมูลที่ผู้โจมตีหรือ dependency แก้ได้ และติดตาม config drift ของ permission, attachment และ remote control เป็นเหตุการณ์ security

หาก workflow พึ่ง attachment หรือ gh api หลาย host ให้กำหนด allowlist พร้อม owner แทน wildcard และแยก credential ตาม host งานที่มี side effect สูงต้องยืนยัน repository, branch, destination และ diff ใหม่ตรงจุดอนุมัติ ไม่ใช้ approval เก่าหลัง context compact, reconnect หรือ state เปลี่ยน

ความเสี่ยงคงเหลือ

Prompt injection จาก issue, webpage หรือ repository ยังอาจชัก agent ไปขอสิทธิ์เพิ่ม ผู้ใช้มี approval fatigue และ policy parser อาจตีความ shell composition ผิด Plugin/hook สามารถเปลี่ยนหลัง review หากไม่ pin digest และ remote connection อาจขยาย behavior โดย server-side change

Cloud session, Slack/Claude Tag และ local CLI มี boundary ต่างกัน การผ่าน test หนึ่ง surface ไม่แทนอีก surface ต้อง inventory ว่าองค์กรเปิดอะไรจริงและมี kill switch ต่อช่องทาง

Recap

  • ตรวจ release, checksum/signature, npm provenance และ advisories
  • ล็อก managed policy ไม่ให้ repo ลด privacy/security control
  • จำกัด shell/web/GitHub host/path และ plugin คนละชั้น
  • ไม่ส่ง secret ใน process args/env หรือ log hook
  • ทดสอบ policy grammar กับคำสั่งจริงบน image มาตรฐาน
  • เก็บ kill switch และ audit trail หลัง rollout

2.1.290 ขยับค่าเริ่มต้นหลายจุดไปทาง least privilege ครับ แต่ประตูที่ดีต้องมีกฎออกบัตรที่ดีด้วย ไม่อย่างนั้นการกดอนุมัติ master key ครั้งเดียวก็ข้ามประตูทุกชั้นอยู่ดี