วิธีตรวจสอบข้อมูล Telemetry จาก Coding Agent ที่คุณใช้งาน

สิ่งที่ telemetry ของ coding agent ครอบคลุมจริง ๆ

Telemetry ของ coding agent ประกอบด้วยกระแสข้อมูล 4 ส่วนที่ใช้คำเรียกเดียวกัน แต่ละกระแสมีการควบคุมแยกจากกัน Model inference จะส่ง prompt และโค้ดของคุณไปยังผู้ให้บริการโมเดล ซึ่งไม่มีการตั้งค่าใดที่ปิดการทำงานนี้ได้ Product analytics และรายงานข้อผิดพลาดจะถูกส่งไปยังผู้จำหน่าย และมักจะส่งต่อไปยังบริษัทจัดเก็บ log ที่ผู้จำหน่ายว่าจ้างอีกที ส่วนการเก็บข้อมูลไว้เพื่อฝึกฝนโมเดลเป็นเรื่องของสัญญามากกว่าเรื่องของเครือข่าย กระแสที่ 4 คือสิ่งที่คนมักมองข้าม: ทุก integration ที่คุณเพิ่มเข้าไปอาจเปิดการเชื่อมต่อกับโฮสต์ที่คุณไม่ได้เลือกไว้

รายการค่าเริ่มต้นของผู้จำหน่ายในปัจจุบันเป็นส่วนที่ล้าสมัยได้เร็วที่สุด การออก release ใหม่สามารถเปลี่ยนค่าเริ่มต้นได้ และฟีเจอร์ใหม่สามารถเพิ่มปลายทางที่สวิตช์เดิมที่มีอยู่ครอบคลุมไม่ถึง ดังนั้นทักษะที่ยั่งยืนคือการตรวจสอบที่คุณสามารถทำซ้ำกับ agent ใดก็ได้: อ่านเอกสารของผู้จำหน่าย ตรวจสอบว่า config ใดถูกนำมาใช้จริงบนเครื่องนี้ เฝ้าดู process จากตัวเครื่องเอง จากนั้นจึงเลือกการควบคุมที่คุณยอมรับได้ ทุกคำสั่งด้านล่างนี้เป็นคำสั่งที่คุณต้องรันบนเครื่องของคุณเอง เพื่อตรวจสอบ traffic ของคุณเอง

หมวดหมู่ทั้งสี่ และเหตุผลที่ต้องใช้การควบคุมที่แตกต่างกัน

Traffic สำหรับการทำ Model inference เป็นสิ่งที่หลีกเลี่ยงไม่ได้ เอเจนต์จะส่ง prompt ของคุณ, ไฟล์ที่อ่าน, ผลลัพธ์ของคำสั่งที่รัน และข้อความที่สร้างขึ้นเองไปยัง endpoint ของโมเดล นี่คือการทำงานตามปกติของผลิตภัณฑ์ สิ่งเดียวที่คุณตัดสินใจได้จริงคือใครเป็นผู้รับข้อมูลนั้น: API ที่รันโดยผู้อื่น หรือโมเดลที่คุณรันด้วยตนเอง บัญชีคลาวด์ขององค์กร (เช่น Bedrock, Vertex, Foundry) เป็นเพียงการเปลี่ยนผู้รับ แต่ไม่ได้ลดการไหลของข้อมูลนี้ เนื้อหาที่เหลือในโพสต์นี้ไม่ได้มุ่งเน้นการลด traffic ของ inference ดังนั้นให้แยกหมวดหมู่นี้ออกจากอีกสามหมวดที่เหลือในความคิดของคุณ

Product analytics และการรายงาน crash เป็นการไหลของข้อมูลที่แยกต่างหากไปยังโฮสต์อื่น ตัวนับการใช้งาน, ตัวเลข latency, การตรวจสอบ feature-flag และ stack trace มักจะถูกส่งไปยังชื่อโฮสต์ที่ไม่มีความเกี่ยวข้องกับ API ของโมเดล และบ่อยครั้งจะถูกส่งไปยังผู้ให้บริการติดตามข้อผิดพลาดภายนอก ผู้จำหน่ายมักระบุสิ่งเหล่านี้ไว้ในเอกสารว่าเป็น "metrics" และ "error reports" และมักให้ environment variable แยกกันในแต่ละหมวดหมู่ ปริมาณข้อมูลเหล่านี้มีน้อยมาก ดังนั้นการนับจำนวน byte จึงไม่สามารถตรวจพบได้ คุณต้องค้นหาจากชื่อโฮสต์ ไม่ใช่จากแบนด์วิดท์

การเก็บรักษาข้อมูล (Retention) และการฝึกสอนโมเดล (Training) เป็นเรื่องของนโยบาย ไม่ใช่ packet การที่ผู้จำหน่ายจะเก็บ prompt ของคุณไว้นานเท่าใด และจะนำไปใช้ฝึกสอนโมเดลในอนาคตหรือไม่นั้น ถูกระบุไว้ในข้อกำหนดที่แนบมากับแผนการใช้งานของคุณ แผนสำหรับผู้บริโภคทั่วไปและแผนเชิงพาณิชย์มักมีความแตกต่างกัน และข้อตกลงเรื่องการไม่เก็บรักษาข้อมูล (zero-retention) มักเป็นข้อตกลงแยกต่างหาก คุณไม่สามารถตรวจสอบสิ่งเหล่านี้ได้ด้วย tcpdump เพราะ packet ที่ส่งออกมาจะมีลักษณะเหมือนกันไม่ว่านโยบายจะเป็นอย่างไร ให้ตรวจสอบข้อกำหนด และหากเป็นเรื่องสำคัญสำหรับนายจ้างของคุณ ควรขอเป็นลายลักษณ์อักษร

Integrations เพิ่มจุดแวะพักของข้อมูลอย่างเงียบเชียบ เซิร์ฟเวอร์ MCP (model context protocol), ตลาดปลั๊กอิน, การตรวจสอบการอัปเดตอัตโนมัติ, เครื่องมือค้นหาบนเว็บ, หรือการตรวจสอบความปลอดภัยที่แก้ไข URL ก่อนทำการดึงข้อมูล: แต่ละรายการคือคำขอไปยังโฮสต์ที่ไม่ใช่ endpoint ของโมเดล นี่คือจุดที่มักเกิดเรื่องไม่คาดคิด เพราะ harness อาจส่งต่องานที่คุณเข้าใจว่าเป็นงานภายในเครื่องผ่านบริการของตัวมันเอง และการอัปเดตเวอร์ชันอาจเริ่มทำเช่นนั้นโดยที่คุณไม่ต้องแก้ไขบรรทัดใดใน config ของคุณเลย ให้ถือว่าเครื่องมือทุกอย่างที่คุณเพิ่มเข้ามาเป็นปลายทางใหม่ จนกว่าคุณจะได้ตรวจสอบการทำงานของมันผ่านเครือข่ายด้วยตนเอง

ขั้นตอนที่ 1: เอกสารของผู้จำหน่ายระบุไว้อย่างไร

เปิดเอกสารอ้างอิงการตั้งค่าและหน้าการใช้งานข้อมูลสำหรับเอเจนต์ของคุณ แล้วอ่านโดยมีรายการคำศัพท์อยู่ในมือ ได้แก่ metrics, analytics, error reporting, crash, feedback, survey, update check, safety check และ marketplace คำเหล่านี้มักเป็นสวิตช์แยกกัน ให้จดชื่อตัวแปรที่ถูกต้องไว้ เพราะขั้นตอนที่ 2 จะใช้คำสั่ง grep เพื่อค้นหาชื่อเหล่านั้น

คำหนึ่งคำอาจทำให้คุณเข้าใจผิด ในเอเจนต์หลายตัวคำว่า "telemetry" ในเอกสารหมายถึงการส่งออกข้อมูลแบบ OpenTelemetry ซึ่งคุณต้องกำหนดค่าเพื่อส่ง metrics ไปยัง collector ที่คุณรันเอง ซึ่งเป็นคนละเรื่องกับการส่งข้อมูลไปยังผู้จำหน่าย Claude Code เป็นหนึ่งในนั้น: การตั้งค่า CLAUDE_CODE_ENABLE_TELEMETRY=1 จะเริ่มการส่งออกไปยัง endpoint ที่คุณระบุใน OTEL_EXPORTER_OTLP_ENDPOINT และไม่เกี่ยวข้องกับระบบวิเคราะห์ข้อมูลของผู้จำหน่ายเอง ซึ่งมีวิธีการเลือกไม่เข้าร่วม (opt-out) ที่แตกต่างกัน ให้ตรวจสอบทิศทางการไหลของข้อมูลให้แน่ชัดก่อนที่คุณจะตั้งค่าใดๆ

คาดหวังว่าจะมีสวิตช์หลัก และคาดหวังว่ามันจะมีช่องโหว่ ณ เดือนสิงหาคม 2026 การตั้งค่า CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC ของ Claude Code จะปิดการทำงานของ metrics, รายงานข้อผิดพลาด, คำสั่ง feedback และแบบสำรวจเซสชันพร้อมกัน แต่เอกสารเดียวกันระบุว่ามันไม่ครอบคลุมถึงการตรวจสอบความปลอดภัยของโดเมน WebFetch ซึ่งจะส่งชื่อโฮสต์ที่คุณกำลังจะดึงข้อมูลไปยัง API ของผู้จำหน่าย และมีการตั้งค่าแยกต่างหาก นี่ไม่ใช่การตำหนิผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่ง แต่เป็นลักษณะของปัญหาที่พบได้ทั่วไป: สวิตช์หลักจะครอบคลุมเฉพาะหมวดหมู่ที่มีอยู่ ณ เวลาที่เขียนสวิตช์นั้นขึ้นมา

คาดหวังว่าการเลือกไม่เข้าร่วม (opt-out) อาจมีผลกระทบตามมา เอกสารชุดเดียวกันระบุว่าการปิดใช้งาน telemetry จะปิดการประเมิน feature-flag ที่ฟีเจอร์บางอย่างต้องใช้งานด้วย ดังนั้นการสลับสวิตช์เพื่อความเป็นส่วนตัวอาจทำให้ฟีเจอร์ที่คุณใช้งานอยู่ปิดตัวลง โดยไม่มีข้อความแจ้งเตือนที่เชื่อมโยงทั้งสองอย่างเข้าด้วยกัน ให้อ่านประโยคที่อยู่ถัดจากแฟล็ก ไม่ใช่แค่อ่านชื่อแฟล็กเท่านั้น

ขั้นตอนที่ 2: การตั้งค่าใดที่ถูกนำไปใช้จริง?

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

env | grep -Ei 'telemetry|otel|analytics|error_report|do_not_track|proxy'

จากนั้นให้แสดงรายการไฟล์การตั้งค่าทั้งหมดที่เครื่องมืออ่าน ตามลำดับที่ระบุไว้ในเอกสาร สำหรับ Claude Code ณ เดือนสิงหาคม 2026 ได้แก่ ไฟล์ของผู้ใช้, ไฟล์ของโปรเจกต์สองไฟล์ และไดเรกทอรีนโยบายที่มีการจัดการบน Linux

for f in ~/.claude/settings.json .claude/settings.json .claude/settings.local.json; do
  echo "== $f"; [ -f "$f" ] && cat "$f"
done
ls -l /etc/claude-code/ 2>/dev/null

ไฟล์โปรเจกต์ที่มาพร้อมกับ git clone คือการตั้งค่าที่เขียนโดยบุคคลอื่น และไฟล์นี้สามารถเปิดใช้งานสิ่งที่ไฟล์ของผู้ใช้ของคุณปิดไว้ได้ หากเอเจนต์มีคำสั่งสถานะที่แสดงรายการแหล่งที่มาที่โหลดไว้ นั่นคือวิธีตรวจสอบความจริงที่รวดเร็วที่สุด โดย Claude Code จะแสดงแหล่งที่มาของการตั้งค่าที่โหลดไว้ใน /status

การตรวจสอบที่แม่นยำที่สุดคือการอ่านจากกระบวนการที่กำลังทำงานอยู่แทนที่จะอ่านจากไฟล์ ให้กำหนดบัญชีผู้ใช้ Linux แยกต่างหากสำหรับเอเจนต์ก่อน ซึ่งจะช่วยให้คำสั่งทุกคำสั่งในโพสต์นี้สั้นลง จากนั้นจึงอ่านสภาพแวดล้อมที่กระบวนการนั้นถูกเริ่มขึ้น

pgrep -u agent -a node
sudo tr '\0' '\n' < /proc/$(pgrep -u agent -n node)/environ | grep -Ei 'telemetry|proxy|otel'

/proc/<pid>/environ จะแสดงตัวแปรที่กระบวนการมีอยู่ในขณะที่เริ่มทำงาน (exec time) ซึ่งจะช่วยตรวจพบกรณีที่คำสั่ง .bashrc export ของคุณไม่ถูกส่งไปยังบริการที่เริ่มโดย systemd หากตัวแปรที่คุณตั้งค่าไว้ไม่ปรากฏที่นี่ แสดงว่าการตั้งค่านั้นไม่มีผล ไม่ว่าไฟล์ dotfiles ของคุณจะระบุไว้อย่างไรก็ตาม

ขั้นตอนที่ 3: เอเจนต์เชื่อมต่อไปยังโฮสต์ใดบ้าง?

เริ่มต้นด้วยการตรวจสอบซ็อกเก็ตที่เปิดอยู่ โดยกรองตามบัญชีผู้ใช้ที่เอเจนต์นั้นทำงานอยู่

sudo ss -tnpe state established

-e จะเพิ่มฟิลด์ uid: เข้าไปในแต่ละบรรทัด เพื่อให้คุณแยกการเชื่อมต่อของเอเจนต์ออกจากเบราว์เซอร์ของคุณได้โดยไม่ต้องอ่านชื่อโพรเซส ให้จดที่อยู่ปลายทางไว้ จากนั้นจึงหาชื่อโฮสต์ที่อยู่เบื้องหลังที่อยู่เหล่านั้น แหล่งข้อมูลชื่อโฮสต์ที่ชัดเจนที่สุดคือการทำ TLS (transport layer security) handshake เนื่องจากทุกการเชื่อมต่อใหม่จะเริ่มต้นด้วย ClientHello ซึ่งมีฟิลด์ SNI (server name indication) ซึ่งก็คือชื่อโฮสต์ที่ไคลเอนต์ร้องขอ

sudo apt install -y tshark
sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' \
  -T fields -e ip.dst -e tls.handshake.extensions_server_name

คุณจะได้ข้อมูลหนึ่งบรรทัดต่อการเชื่อมต่อใหม่หนึ่งครั้ง ซึ่งเป็นรายการที่คุณต้องการพอดี ไม่ว่าจะเป็น API ของโมเดล, เซิร์ฟเวอร์อัปเดต, โฮสต์สำหรับวิเคราะห์ข้อมูล, ตัวติดตามข้อผิดพลาด และสิ่งที่การเชื่อมต่อเสริม (integration) เพิ่มเข้ามา หากคอลัมน์ชื่อว่างเปล่า หมายความว่าไคลเอนต์นั้นใช้ ECH (encrypted client hello) ทำให้ไม่สามารถมองเห็นชื่อโฮสต์บนเครือข่ายได้ ในกรณีนี้ให้ใช้วิธีตรวจสอบที่อยู่ IP ปลายทาง, ทำ reverse lookup หรือใช้พร็อกซีในขั้นตอนที่ 4 แทน

มุมมองจาก DNS (domain name system) เป็นการตรวจสอบข้ามข้อมูลที่มีประโยชน์ เพราะจะแสดงชื่อโฮสต์ที่เอเจนต์ค้นหา แม้จะเป็นการเชื่อมต่อที่ทำไม่สำเร็จก็ตาม

sudo tcpdump -ni any -l 'udp port 53'

แต่ละบรรทัดของคิวรีจะลงท้ายด้วยประเภทของเรคคอร์ดและชื่อโฮสต์ ในรูปแบบ A? host.example.net. (39) ให้ทำการดักจับข้อมูลบน any แทนที่จะเป็นอินเทอร์เฟซภายนอก เนื่องจากเมื่อใช้ systemd-resolved แอปพลิเคชันจะสื่อสารกับตัวรับฟังในเครื่อง (local stub listener) บน 127.0.0.53 และมีเพียงตัว stub เท่านั้นที่สื่อสารออกไปยังภายนอก หากคุณไม่พบทราฟฟิก DNS เลยในขณะที่เอเจนต์กำลังทำงานอยู่ แสดงว่ารันไทม์นั้นกำลังทำ DNS over HTTPS ด้วยตัวเอง และจะมีเพียงขั้นตอนที่ 4 เท่านั้นที่จะช่วยให้คุณทราบชื่อโฮสต์ได้

ให้ทำการดักจับข้อมูลในขณะที่เอเจนต์กำลังทำงานจริง เริ่มเซสชัน สั่งให้มันอ่านไฟล์ สั่งให้มันรันคำสั่ง หรือสั่งให้มันทำบางอย่างจนเกิดข้อผิดพลาด ทราฟฟิกที่เกิดขึ้นเพียงครั้งเดียวตอนเริ่มต้นระบบ หรือเกิดขึ้นเฉพาะเมื่อมีการโยนข้อยกเว้น (exception) จะไม่ปรากฏในการดักจับข้อมูลขณะที่ระบบไม่ได้ทำงาน และการดักจับข้อมูลในขณะที่ระบบว่างงานเป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้การตรวจสอบได้คำตอบที่ผิดพลาดแต่ดูน่าเชื่อถือ

ขั้นตอนที่ 4: ข้อมูลภายในคำขอคืออะไร

Hostname จะบอกคุณว่าปลายทางคือใคร หากต้องการทราบว่าข้อมูลภายในคืออะไร ให้วาง proxy ที่คุณควบคุมไว้หน้า agent และเชื่อถือ certificate authority (CA) ของ proxy นั้นเฉพาะในรันไทม์นั้นเท่านั้น เครื่องมือที่นิยมใช้คือ mitmproxy โดยทางโครงการแนะนำให้ใช้ไฟล์ binary แบบ standalone จาก mitmproxy.org และมีเอกสารระบุ uv tool install mitmproxy สำหรับการติดตั้งผ่านแพ็กเกจ Python

mitmdump -w /tmp/agent-flows.mitm

การรันครั้งแรกจะเขียน CA ลงใน ~/.mitmproxy/ โดยที่ mitmproxy-ca-cert.pem คือไฟล์ certificate ของตัวมันเอง ใน shell ที่คุณจะใช้เปิด agent ให้กำหนดค่า client ให้ชี้ไปยัง proxy และ certificate ดังกล่าว

export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export REQUESTS_CA_BUNDLE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export SSL_CERT_FILE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"

CLI ของ agent จำนวนมากเป็นโปรแกรม Node ซึ่ง Node จะอ่านค่า NODE_EXTRA_CA_CERTS เมื่อกระบวนการเริ่มต้น ดังนั้นให้ export ค่านี้ก่อนที่คุณจะเปิด agent ไม่ใช่ทำใน terminal อื่นหลังจากนั้น ส่วน client ที่เป็น Python จะอ่านค่า REQUESTS_CA_BUNDLE หรือ SSL_CERT_FILE และ binary ที่เขียนด้วย Go ซึ่งใช้ไลบรารีมาตรฐานจะอ่านค่า SSL_CERT_FILE บน Linux ให้ทดสอบว่า path ใช้งานได้จริงด้วย curl ก่อนที่จะสรุปว่า agent มีปัญหา

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

หาก proxy ทำงานปกติจะแสดง 200 และคำขอจะปรากฏในผลลัพธ์ของ mitmdump หาก CA ไม่ได้รับความเชื่อถือจะแสดง curl: (60) SSL certificate problem: self-signed certificate in certificate chain และผลลัพธ์ที่เทียบเท่ากันจาก agent ที่เป็น Node คือข้อผิดพลาดที่มีรหัส SELF_SIGNED_CERT_IN_CHAIN หลังจากนั้นให้ดู flow ที่บันทึกไว้ด้วย console viewer ซึ่งคุณสามารถเปิดคำขอเพื่ออ่าน header และ body ได้

mitmproxy -r /tmp/agent-flows.mitm

มี 4 ผลลัพธ์ที่ควรทราบ: คุณเห็นคำขอ ซึ่งในกรณีนี้ให้ตรวจสอบและตัดสินใจ, agent ปฏิเสธที่จะเริ่มทำงานโดยแจ้งข้อผิดพลาดเกี่ยวกับ certificate ซึ่งเป็นปัญหาเรื่องความเชื่อถือในรันไทม์นั้นไม่ใช่การค้นพบเกี่ยวกับผู้ให้บริการ, คุณเห็นเฉพาะ model API ซึ่งหมายความว่าหมวดหมู่อื่นถูกปิดไว้ หรือทำงานเฉพาะเมื่อเกิดเหตุการณ์ที่คุณไม่ได้กระตุ้น, หรือคุณไม่เห็นอะไรเลยทั้งที่ agent ทำงานปกติ ซึ่งหมายความว่า client เพิกเฉยต่อ environment variable ของ proxy หรือมีการทำ certificate pinning ไว้ และไม่มีการตั้งค่าแอปพลิเคชันใดที่เชื่อถือได้ว่าจะบอกความจริงกับคุณ ผลลัพธ์สุดท้ายนี้สำคัญที่สุด และจะส่งคุณกลับไปที่ขั้นตอนที่ 3 เพราะการดักจับแพ็กเก็ต (packet capture) จะแสดงให้เห็นการเชื่อมต่ออย่างไม่อาจปฏิเสธได้

การควบคุม จากระดับอ่อนที่สุดไปจนถึงระดับเข้มงวดที่สุด

การตั้งค่าแบบ Opt-out: เป็นวิธีที่ประหยัดและอ่อนที่สุด เนื่องจากขึ้นอยู่กับว่าผู้ให้บริการจะเคารพการตั้งค่าเหล่านั้นหรือไม่ และครอบคลุมเฉพาะหมวดหมู่ที่มีอยู่เดิมเท่านั้น ให้ตั้งค่าในไฟล์การตั้งค่าของผู้ใช้หรือใน shell profile เพื่อให้การตั้งค่ายังคงอยู่หลังการรีบูตหรือการเปิดเทอร์มินัลใหม่ เพิ่ม DO_NOT_TRACK=1 ในระหว่างนั้นด้วย นี่เป็นข้อตกลงที่เครื่องมือบรรทัดคำสั่งหลายตัวให้ความเคารพ รวมถึงเอเจนต์บางตัว และไม่มีค่าใช้จ่ายใดๆ จากนั้นให้ทำตามขั้นตอนที่ 3 อีกครั้งหลังจากการอัปเดตครั้งถัดไป เนื่องจากเป็นช่วงเวลาที่ขอบเขตการครอบคลุมอาจเปลี่ยนแปลง

การจำกัดการเชื่อมต่อขาออก (Egress restriction): ในขั้นนี้คุณจะเปลี่ยนจากการขอความร่วมมือมาเป็นการบังคับใช้จริง ให้รันเอเจนต์ด้วยบัญชีผู้ใช้เฉพาะของมันเอง จากนั้นอนุญาตให้ผู้ใช้นั้นเข้าถึงได้เพียง loopback และ DNS แล้วปฏิเสธการเชื่อมต่อส่วนที่เหลือ วิธีนี้จะเพิ่มตารางของตัวเองขึ้นมา จึงไม่ส่งผลกระทบต่อกฎ firewall ที่มีอยู่เดิม

table inet agentegress {
  chain output {
    type filter hook output priority filter; policy accept;
    meta skuid "agent" ip daddr 127.0.0.0/8 accept
    meta skuid "agent" udp dport 53 accept
    meta skuid "agent" counter log prefix "agent-egress-drop " drop
  }
}

นำไปใช้ด้วย sudo nft -f /etc/nftables.d/agent.nft, ตรวจสอบตัวนับด้วย sudo nft list table inet agentegress และอ่านรายการที่ถูกปฏิเสธด้วย sudo journalctl -k -g agent-egress-drop การที่ตัวนับการปฏิเสธเพิ่มขึ้นพร้อมกับชื่อโฮสต์ที่คุณไม่คาดคิดคือจุดประสงค์หลักของการดำเนินการนี้ มีข้อจำกัดที่ต้องพิจารณาอยู่สองประการ meta skuid จะจับคู่กับผู้ใช้ที่เป็นเจ้าของ socket ดังนั้นกฎนี้จะมีผลตราบเท่าที่บัญชีนั้นไม่สามารถเปลี่ยนเป็นผู้ใช้อื่นได้ การใช้ sudo แบบไม่ต้องใช้รหัสผ่านสำหรับเอเจนต์จะทำให้กฎนี้กลายเป็นเพียงข้อเสนอแนะเท่านั้น และการเปิดพอร์ต UDP 53 ให้กับเซิร์ฟเวอร์ใดก็ได้จะทิ้งช่องทางที่สามารถส่งข้อมูลออกไปในชื่อ query ได้ ดังนั้นควรปิดพอร์ตนี้ด้วยหากโมเดลภัยคุกคามของคุณจำเป็นต้องทำเช่นนั้น โดยการชี้ตัว resolver ของเอเจนต์ไปยังโฮสต์ที่คุณดูแลเอง รายการอนุญาต (allowlist) ของชื่อโฮสต์ควรอยู่ใน proxy แทนที่จะเป็นใน nftables เนื่องจาก API endpoint มักอยู่หลัง content delivery network ซึ่ง IP address สามารถเปลี่ยนแปลงได้ตลอดเวลา ต้นทุนของการควบคุมนี้คือความเสียหายและการดูแลรักษา: การติดตั้งแพ็กเกจ, git ผ่าน SSH และการตรวจสอบการอัปเดตของเอเจนต์เองจะล้มเหลวทั้งหมดจนกว่าคุณจะอนุญาต และรายการนั้นจะกลายเป็นภาระที่คุณต้องดูแล หากคุณกำลังตั้งค่านี้บนเซิร์ฟเวอร์แทนที่จะเป็นแล็ปท็อป บัญชีและโครงสร้าง firewall แบบเดียวกันนี้จะเป็นพื้นฐานของ การรัน Claude Code บน VPS อย่างปลอดภัย

เครื่องเสมือนแบบใช้แล้วทิ้ง (Disposable machine): ให้เอเจนต์ใช้เครื่องเสมือน (VM) ที่ไม่มีข้อมูลรับรอง (credential) ใดๆ ที่คุณกังวล และถูกทำลายทิ้งเมื่อจบงาน วิธีนี้ไม่ได้ลดสิ่งที่เอเจนต์ส่งออกไป แต่ช่วยลดสิ่งที่เอเจนต์สามารถเข้าถึงเพื่อส่งออกไปได้ ซึ่งมักเป็นความเสี่ยงที่คุณให้ความสำคัญจริงๆ ให้ใช้ร่วมกับกฎการจำกัดการเชื่อมต่อขาออกข้างต้น เพราะ VM ใหม่ที่เข้าถึงอินเทอร์เน็ตได้โดยไม่มีข้อจำกัดยังคงสามารถเข้าถึงทุกโฮสต์ที่คุณต้องการป้องกันได้ วิธีการและสถานะที่คุณต้องสร้างใหม่ทุกครั้งมีอธิบายไว้ใน การรันเอเจนต์เขียนโค้ดใน VM แบบใช้แล้วทิ้ง และคำถามเรื่องขนาดทรัพยากรใน การรันเอเจนต์เขียนโค้ดบน VPS

การโฮสต์โมเดลด้วยตนเอง (Self-hosting the model): เป็นการควบคุมเพียงวิธีเดียวที่ตัดวงจรการส่งข้อมูลเพื่อการประมวลผล (inference flow) ออกไป เพราะ prompt จะไม่หลุดออกจากฮาร์ดแวร์ของคุณเลย ต้นทุนที่เกิดขึ้นนั้นเป็นเรื่องจริง: คุณไม่สามารถโฮสต์โมเดลแบบปิดได้ ดังนั้นวิธีนี้หมายถึงการเลือกใช้ open weights และยอมรับช่องว่างด้านความสามารถในงานที่ซับซ้อน รวมถึงต้องมีฮาร์ดแวร์สำหรับรันโมเดลเหล่านั้นด้วย การชั่งน้ำหนักข้อดีข้อเสียมีอธิบายไว้ใน คุณสามารถโฮสต์ Claude ด้วยตนเองได้หรือไม่ และความแตกต่างด้านความสามารถระหว่างเอเจนต์หลักต่างๆ ใน ความแตกต่างระหว่าง Claude Code, Cursor, Codex และ Copilot

การควบคุมทั้งสี่วิธีนี้ไม่มีวิธีใดที่เปลี่ยนสิทธิ์การอ่านไฟล์บนดิสก์ของเอเจนต์ได้ และ traffic ของการประมวลผลจะนำข้อมูลใดก็ตามที่มันอ่านได้ติดไปด้วย หากมีไฟล์ .env อยู่ในไดเรกทอรีทำงาน ข้อมูลนั้นจะถูกส่งไปยังโมเดลทันทีที่เอเจนต์ทำการ grep หาชื่อตัวแปร การป้องกันไม่ให้ข้อมูลเหล่านั้นเข้าถึงได้เป็นงานแยกต่างหาก ซึ่งมีอธิบายไว้ใน การเก็บความลับให้พ้นจากบริบทของ AI agent

สิ่งที่ควรตรวจสอบหลังการอัปเดตทุกครั้ง

1. เปรียบเทียบหน้าการตั้งค่าและการใช้งานข้อมูลของผู้ให้บริการกับข้อมูลที่คุณบันทึกไว้ครั้งล่าสุด เพื่อมองหาตัวเลือกการตั้งค่าใหม่ๆ และบริการที่มีชื่อเรียกใหม่
2. อ่าน environment ของ process อีกครั้งจาก /proc/<pid>/environ เพื่อยืนยันว่าการตั้งค่า opt-out ของคุณยังคงมีผลกับ process ที่กำลังทำงานอยู่
3. พิมพ์ไฟล์การตั้งค่าโปรเจกต์ออกมาอีกครั้ง เนื่องจาก git pull อาจนำไฟล์ config ที่เพื่อนร่วมงานแก้ไขไว้เข้ามาแทนที่
4. ทำการดักจับ SNI สำหรับการทำงานจริงเต็มหนึ่งเซสชัน และเปรียบเทียบรายการ hostname กับรายการล่าสุดของคุณ
5. ตรวจสอบตัวนับการ drop ของ firewall เนื่องจากปลายทางใหม่มักจะปรากฏที่นั่นก่อนที่คุณจะสังเกตเห็นจากที่อื่น

ขั้นตอนนี้ใช้เวลาประมาณ 10 นาที และเป็นส่วนเดียวของกระบวนการที่ไม่ล้าสมัย ค่าเริ่มต้นที่คุณตรวจสอบในเดือนสิงหาคม 2026 เป็นข้อเท็จจริงของเดือนสิงหาคม 2026 แต่การดักจับข้อมูลคือข้อเท็จจริงของวันนี้

FAQ

ฉันจะหยุด coding agent ไม่ให้ส่งโค้ดของฉันไปยังโมเดลได้หรือไม่?

ไม่ได้ และการตั้งค่าใดๆ ที่อ้างว่าทำได้นั้นกำลังอธิบายถึงสิ่งอื่น การส่ง prompt, ไฟล์ที่ agent อ่าน และผลลัพธ์ของคำสั่งที่รันไปยัง endpoint ของโมเดลคือวิธีการทำงานของ inference ดังนั้นตัวแปรเดียวคือใครเป็นผู้รับข้อมูลนั้น คุณสามารถเปลี่ยนผู้รับได้โดยการชี้ agent ไปยังบัญชีคลาวด์ของบริษัทหรือโมเดลที่คุณโฮสต์เอง และคุณสามารถลดปริมาณข้อมูลที่ส่งได้โดยการจำกัดสิ่งที่ agent ได้รับอนุญาตให้อ่าน การปิด analytics และการรายงานข้อผิดพลาดไม่มีผลต่อกระบวนการนี้เลย

ฉันจะดูได้อย่างไรว่า coding agent เชื่อมต่อไปยังโฮสต์ใดบ้าง?

ให้รัน agent ในฐานะผู้ใช้ Linux แยกต่างหาก จากนั้นจับข้อมูล TLS ClientHello ของทุกการเชื่อมต่อใหม่ในขณะที่คุณใช้งาน: sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name จะมีหนึ่งบรรทัดปรากฏขึ้นต่อการเชื่อมต่อหนึ่งครั้ง พร้อมด้วยที่อยู่ปลายทางและ hostname ที่ร้องขอ ให้ตรวจสอบชื่อโฮสต์เทียบกับ sudo tcpdump -ni any 'udp port 53' โดยทำการ capture บน any เนื่องจาก local resolver stub บน 127.0.0.53 จะจัดการ query ก่อน ให้ทำการ capture ในขณะที่ agent กำลังทำงานจริง เนื่องจาก ping ตอนเริ่มต้นและรายงานการ crash จะไม่ปรากฏในการ capture ขณะที่เครื่องไม่ได้ใช้งาน

proxy ของฉันไม่แสดง traffic ในขณะที่ agent ทำงาน เกิดอะไรขึ้น?

เป็นไปได้ว่า client เพิกเฉยต่อ HTTP_PROXY และ HTTPS_PROXY หรือมีการทำ certificate pinning ทำให้ปฏิเสธ CA ของคุณ ให้ทดสอบ path ด้วย curl ก่อน: หาก curl สามารถเข้าถึงอินเทอร์เน็ตผ่าน proxy ได้ แต่ agent ไม่ปรากฏในรายการ flow แสดงว่า agent ไม่ได้ใช้ environment variable ของ proxy รันไทม์บางตัวต้องการการระบุ CA ในรูปแบบเฉพาะ โดยเฉพาะ Node ที่จะอ่าน NODE_EXTRA_CA_CERTS เฉพาะตอนเริ่ม process เท่านั้น ดังนั้นการ export ค่าหลังจากเปิดใช้งาน agent ไปแล้วจะไม่มีผลใดๆ เมื่อ proxy ไม่สามารถมองเห็น traffic ได้ ให้ใช้วิธี packet capture แทน ซึ่งไม่มีการตั้งค่าของแอปพลิเคชันใดสามารถหลีกเลี่ยงได้

การปิด telemetry จะหยุดไม่ให้โค้ดของฉันถูกนำไปใช้ฝึกโมเดลหรือไม่?

ไม่ การวิเคราะห์ข้อมูล (analytics) และการรายงานการ crash เป็นคนละกระบวนการกับ inference ดังนั้นการปิดฟังก์ชันเหล่านี้จะช่วยลดการส่งตัวนับการใช้งานและ stack trace เท่านั้น แต่ prompt ทุกอย่างยังคงถูกส่งไปยังโมเดลเหมือนเดิม ส่วน prompt เหล่านั้นจะถูกเก็บไว้หรือไม่ และจะถูกนำไปใช้ฝึกโมเดลในอนาคตหรือไม่นั้น ขึ้นอยู่กับข้อกำหนดในแผนการใช้งานของคุณ ซึ่งแผนสำหรับผู้บริโภคทั่วไปและแผนเชิงพาณิชย์มักจะแตกต่างกัน นี่เป็นเรื่องของสัญญาที่คุณต้องอ่านมากกว่าจะเป็นแพ็กเก็ตที่คุณจะ capture ได้ ดังนั้นให้ตรวจสอบหน้าการใช้งานข้อมูล (data usage) ของแผนของคุณ และหากเป็นเรื่องสำคัญ ให้ทำข้อตกลงเชิงพาณิชย์หรือข้อตกลงไม่เก็บข้อมูล (zero-retention agreement) ก่อนเริ่มใช้งานครั้งแรก