ทางเดินสิทธิ์มืดมีประตู write เปิดกว้างขึ้น ขณะที่ประตู read และ network ยังล็อก โดยสลักอำพันเส้นหนึ่งเอียงผิดแนวเป็นจุดผิดปกติ
aiagentcodexopenaisecuritypermissionsmcpnews

Codex CLI 0.161.0 ขยาย write ที่อนุมัติได้โดยไม่เปิด read/network: อัปเดตดี แต่ต้องทดสอบ policy จริง

พี่โชว์Engineering

OpenAI ออก Codex CLI 0.161.0 เมื่อ 7 ตุลาคม 2026 โดยแก้ permission escalation ให้ผู้ใช้อนุมัติพื้นที่เขียนที่กว้างขึ้นได้ แต่ยังคง denied reads และ network restriction เดิม พร้อมผูก background task กับสิทธิ์ของ turn ต้นทางครับ รุ่นเดียวกันเพิ่ม /mcp login <name>, ทำ GPT-6.1 Sol เป็นค่าเริ่มต้นใน catalog บางช่องทาง และเพิ่มความสามารถ Bedrock/multi-agent

ผมตรวจ release, tag, npm metadata, asset digest, เอกสาร security และ advisory แบบอ่านอย่างเดียว ไม่ดาวน์โหลดหรือรัน binary, installer, MCP server หรือ plugin ใดกับ repository จริง ผลคือ ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ 2026-10-08 สำหรับ rollout แบบควบคุม ไม่ใช่การรับประกันว่าไม่มีความเสี่ยงในทุก config

สรุป 30 วินาที

  • release rust-v0.161.0 เผยแพร่ 7 ตุลาคม 15:58 UTC และ tag ชี้ commit 979011409de0a60b52f179721948e65531d26144
  • macOS arm64 archive มี SHA-256 bd83479f3ae21474c407ec2164fbc2a63fa763f7afbbd123fb6a69c5201cfd38
  • npm @openai/[email protected] มี integrity sha512-+ZnJFGBbQBwY...uGf7guD2Q==; tag ที่ตรวจเป็น annotated tag แต่ verification จาก GitHub รายงาน unsigned
  • permission fix แยก broad write approval ออกจาก denied read/network และ background task ใช้สิทธิ์ของ turn ที่สร้างมัน
  • /mcp login ทำ OAuth/sign-in จาก terminal ง่ายขึ้น แต่ credential, issuer discovery และ server identity กลายเป็น boundary ที่ต้องกำกับ
  • Daybreak ซ่อนและ opt-in โดย default ขณะที่ per-turn Cyber access override มีทาง explicit แยก จึงต้องตรวจ policy ขององค์กร ไม่พึ่ง UI ว่า feature ไม่ปรากฏ

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

Coding agent ต่างจาก autocomplete เพราะมันอ่านไฟล์ รัน shell เขียนหลาย directory ต่อ network และคุยกับ MCP ได้ใน workflow เดียว Permission bug จึงไม่ใช่เพียง popup ผิดสี แต่สามารถเปลี่ยนขอบเขตข้อมูลที่ agent เห็นหรือแก้ได้

การเปิด write กว้างขึ้นโดยรักษา read deny ฟังแปลกในตอนแรก แต่เป็นกรณีจริง เช่น build ต้องเขียน cache/output ใน directory หนึ่งโดยไม่ควรอ่าน secret ที่อยู่ข้างกัน หาก engine ตีความ approval เป็น “เปิดทั้งต้นไม้” การแก้ friction หนึ่งจุดอาจทำลาย confidentiality อีกจุด

เหมือน รปภ. อนุญาตให้พนักงานวางพัสดุในโกดังเพิ่ม แต่ไม่ได้ให้กุญแจเปิดตู้เอกสารหรือประตูออกหลังร้าน สิทธิ์ write, read และ network ต้องเป็นคนละกุญแจ ไม่ใช่บัตรใบเดียวที่ระดับสูงกว่าชนะทุกอย่าง

ทำงานยังไง: capability ต้องติดกับ turn และ resource

รุ่นนี้ระบุว่า approved filesystem escalation สามารถเพิ่ม write roots โดยคง denied reads กับ network restrictions หมายความว่า permission lattice ไม่ควรเป็นตัวเลขระดับเดียว แต่เป็นชุด capability ตาม operation และ resource เมื่อ user อนุมัติ /tmp/build, runtime เพิ่มสิทธิ์ write จุดนั้นโดยไม่ลบ deny ที่ /secrets หรือเปิด egress

Background task retention สำคัญเพราะงานอาจอยู่ต่อหลัง UI เปลี่ยน turn หาก task ไปรับสิทธิ์ล่าสุดของ session มันอาจได้กว้างกว่าตอนถูกสร้าง หรือเสีย boundary เดิมจน behavior เปลี่ยน รุ่นนี้ผูกกับ originating turn ช่วย reasoning และ audit แต่ทีมควรยืนยันว่า child process, daemon และ MCP call สืบสิทธิ์ตาม contract เดียวกัน

/mcp login <name> ลดขั้นตอน OAuth ใน terminal แต่ sign-in ไม่ได้พิสูจน์ว่า server tools ควรเข้าถึง repo/secret เท่าไร Authentication ตอบว่า “server นี้คือใคร” ส่วน authorization ตอบว่า “tool นี้ทำอะไรได้” ต้อง allowlist issuer/redirect, pin server config, แยก account ทดสอบ และ review tool schema ก่อนเปิดให้ model

Bedrock multi-agent V2 และ reasoning สูงขึ้นเพิ่มจำนวน actor กับ call chain ถ้า agent หลัก spawn ลูกที่เข้าถึง network/MCP ต่างกัน audit log ต้องผูก parent-child และ budget อย่างชัดเจน อย่าคิดว่า provider IAM แทน permission ภายใน harness ได้ทั้งหมด

Daybreak/Cyber controls มีทั้ง feature flag, eligibility, catalog support และ explicit per-turn option การซ่อนเมนูไม่ใช่ policy enforcement เสมอ ทีม managed environment ควร deny หรือ allow ที่ server/requirements layer และทดสอบ CLI/SDK/exec path ทุกทาง ไม่ดูเฉพาะ TUI

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

GitHub release 0.161.0 ให้ changelog, asset digest และวันเผยแพร่ Tag object ชี้ commit ข้างต้น แต่ GitHub verification ระบุ unsigned จึงไม่อ้างว่ามี signed tag ส่วน Linux musl บาง asset มี .sigstore แยก ผู้ใช้ควรเลือก artifact/channel ที่องค์กรตรวจได้และ mirror หลัง verify

npm package ยืนยัน version/integrity ของ distribution อีกช่องทาง Integrity ช่วยตรวจ bytes ที่ registry ส่ง แต่ไม่แทนการประเมิน dependency, post-install behavior, account หรือ config หลังติดตั้ง

เอกสาร security ของ Codex ใช้กำหนด sandbox/approval model และ security advisories ใช้ตรวจ disclosure วันที่ตรวจ ไม่พบ known high/critical advisory สาธารณะที่ระบุว่า 0.161.0 กระทบโดยไม่มี mitigation แต่ advisory ใหม่อาจปรากฏภายหลัง

การตรวจครั้งนี้ไม่ใช้ remote installer, ไม่รัน candidate binary, ไม่ login MCP และไม่ให้ candidate แตะ private network, credentials หรือ production เราตรวจ publisher, repository, tag/commit, changelog, npm integrity, asset digest, docs, advisory และ default boundary เท่านั้น

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

ทีมที่ใช้ Codex ผ่าน Bedrock อาจได้ catalog/model/region เพิ่ม แต่ต้นทุนไม่ได้มาจาก model token อย่างเดียว Multi-agent, Ultra reasoning, retries และ MCP tools สามารถคูณ call จำนวนมาก ต้องตั้ง per-turn token/tool/time budget และรายงาน cost ต่อ merged task ไม่ใช่ต่อ request

Permission fix อาจเพิ่ม approval บางกรณีหรือทำ automation เก่าที่พึ่ง behavior กว้างล้ม นี่เป็นค่า migration ที่ควรยอมจ่ายมากกว่าปิด sandbox เพื่อให้ pipeline เขียว ให้ canary project ที่ไม่มี secret วัด denial, false allow, task success และเวลา ก่อน rollout fleet

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

Changelog อธิบาย behavior ที่แก้ แต่ไม่เผย exploit report, CVE หรือ telemetry ว่ามีการใช้ช่อง permission เหล่านี้จริงหรือไม่ เราจึงสรุปได้ว่า boundary ถูก harden ไม่ใช่ว่ารุ่นก่อนถูกโจมตีแล้ว

GitHub release มี digests และ sigstore สำหรับ artifact บางกลุ่ม ขณะที่ annotated tag ที่ API ตอบกลับเป็น unsigned สิ่งนี้ไม่แปลว่า asset ปลอม แต่หมายถึง provenance strength ต่างกันตาม artifact ผู้ใช้ต้องบันทึกว่าติดตั้งไฟล์ไหนจาก channel ใด ไม่ใช้คำกว้างว่า “release signed”

เอกสารบอก sandbox/approval model โดยรวม แต่ default จริงขึ้นกับ OS, Codex surface, managed requirements, provider และ config repository ยังไม่ชัดจาก release note ว่า policy ทุกเส้นทาง—TUI, exec, SDK, remote session, Bedrock—ให้ผลเท่ากัน ทีมจึงต้องมี contract tests ของตน

ยังไม่มี SBOM/complete transitive dependency audit ในการตรวจครั้งนี้ และเราไม่ได้ยืนยัน bytes ของ archive ด้วยการดาวน์โหลด เพราะ safety gate กำหนด read-only metadata review การผ่านเกณฑ์จึงมีขอบเขตชัด

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

Pin 0.161.0 และ checksum/integrity ใน internal mirror อย่ารัน curl | sh หรือ latest แบบลอย แยก service account ที่ไม่มี production credential และเปิด workspace เฉพาะ repo/temporary build roots

ตั้ง deny read สำหรับ credential paths, allow write แบบแคบ, network deny-by-default และ per-domain approval ทดสอบกรณีขอ write parent directory, symlink, deleted cwd, background process และ reconnect ว่า deny เดิมยังอยู่

สำหรับ MCP ให้ลงทะเบียน server ด้วย URL/issuer ที่ review แล้ว ใช้ OAuth scope ต่ำสุด แยก token ต่อ server ปิด dynamic server discovery จาก repo ที่ไม่ไว้ใจ และตรวจ tool schema/output เป็น untrusted data ทุกครั้ง

กำหนด parent-child budget สำหรับ multi-agent ปิด feature ที่ไม่ใช้ผ่าน managed policy ไม่พึ่งเมนูซ่อน และเก็บ audit log ของ approval, origin turn, resource, tool, network destination กับ resulting write

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

ผู้ใช้ยังสามารถอนุมัติ shell, write, network หรือ MCP กว้างเกินจำเป็น Model อาจถูก prompt injection จาก source/web/tool output และคำสั่งที่ “ถูกอนุมัติ” ยังทำลายข้อมูลได้หาก scope ใหญ่ Symlink/path race, plugin, login shell, credential helper และ external MCP server เป็น boundary นอก release note

Background task กับ remote session ทำให้ authority มีอายุยาวกว่า prompt ที่เห็น ความผิดพลาดใน cleanup หรือ token revocation อาจทิ้ง process/credential ไว้ Release ใหม่ก็อาจมี regression และ advisory ภายหลัง การตรวจนี้ไม่ใช่ penetration test หรือ full dependency review

ควรทำอะไร

ผู้ดูแลควรทำ canary บน repository สังเคราะห์ด้วย test matrix read-deny/write-allow/network-deny/MCP login/background task ตรวจทั้ง success path และ denial หลัง reconnect แล้วค่อย rollout แบบ ring

นักพัฒนาอย่ากด approve ตามชื่อ command อย่างเดียว ดู working directory, path, egress และผลข้างเคียง แยก build/test/publish เป็น credentials คนละชุด และให้ publish ต้อง human approval

ผมมองว่าไฮไลต์จริงของรุ่นนี้ไม่ใช่ model default แต่คือ permission ที่ละเอียดขึ้น หากทีมตอบด้วย wildcard allow เราจะทิ้งประโยชน์หลักของ release ไปเอง

Recap

  • Pin version และตรวจ digest/integrity ตาม artifact จริง
  • แยก read/write/network/MCP เป็น capability คนละชุด
  • ทดสอบ background task ว่ารักษาสิทธิ์ turn ต้นทาง
  • login MCP ด้วย scope ต่ำสุดและ server allowlist
  • ตั้ง multi-agent budget และ audit parent-child
  • ไม่ตีความ unsigned tag หรือ partial sigstore เกินหลักฐาน
  • รุ่นนี้ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ ไม่ใช่การรับประกันว่าไม่มีความเสี่ยง