วิธีให้ AI Agent ใช้งาน API Key โดยไม่ต้องเห็น Key

คำตอบแบบสรุป: หากต้องการให้ AI agent ใช้งาน API key ได้โดยไม่เห็นตัวคีย์ ให้ใส่เฉพาะ ชื่อ ของคีย์ไว้ในบริบท (context) ของ agent แล้วจัดการแปลง ค่าจริง (value) ภายนอกโมเดล ไม่ว่าจะเป็นการอ้างอิง environment variable ที่ agent เรียกใช้แต่ไม่เคยสั่งพิมพ์ออกมา, การใช้ reference ของ secret manager หรือการใช้พร็อกซีคอยแทรก header ให้ จากนั้นกำหนดให้คีย์แต่ละตัวมีอายุการใช้งานสั้น (short-lived) และจำกัดสิทธิ์เท่าที่จำเป็น (narrowly scoped) พร้อมทั้งตัดข้อมูลลับ (redact) ออกจาก log ก่อนที่ข้อมูลจะถูกส่งกลับไปยัง agent

ทีมงาน DeepSeek Harness ได้ระบุถึงปัญหานี้ไว้ในบทความ “Exploring Super-agent Design” ว่า credentials ใน context ของ agent อาจรั่วไหลได้ ดังนั้น agent จึงควรใช้งาน credentials ได้โดยไม่จำเป็นต้องเห็นค่าจริง บทความดังกล่าวจัดให้เรื่องนี้เป็นโจทย์ปลายเปิดที่ยังรอการแก้ไข แต่คุณไม่ต้องรอให้มีเฟรมเวิร์กใดมาแก้ปัญหานี้ เพราะรูปแบบและแนวทางด้านล่างนี้สามารถนำไปใช้งานได้จริงแล้วในปัจจุบัน

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

AI agent ทำ API key รั่วไหลได้อย่างไร

AI agent มีโอกาสทำ API key รั่วไหลได้ทันทีที่ค่านั้นเข้ามาอยู่ใน context ของมัน เพราะโมเดลอาจนำค่านั้นไปใส่ซ้ำในการเรียกใช้ tool, ในไฟล์, ใน commit หรือในข้อความตอบกลับ โดยไม่จำเป็นต้องมีใครเจาะระบบเซิร์ฟเวอร์เลย ตัว agent เองนั่นแหละที่เป็นผู้ส่งมอบคีย์ออกไป ซึ่งมักเกิดขึ้นในขณะที่มันกำลังพยายามช่วยแก้ปัญหาให้คุณ

เส้นทางการรั่วไหล 4 รูปแบบที่คุณจะพบได้บ่อยที่สุด:

1. Agent แอบอ่านไฟล์ .env: เมื่อคุณถามว่าทำไม API การชำระเงินถึงเรียกไม่ผ่าน มันจึงเปิดไฟล์ .env ขึ้นมาดู และทำให้ sk_live_... เข้าไปอยู่ใน transcript รวมถึง log ของผู้ให้บริการโมเดลทันที
2. Agent แสดงคีย์ออกมาในการเรียกใช้ tool: เช่น รันคำสั่ง curl เพื่อดีบักพร้อมแนบ header ที่มีคีย์จริง หรือรัน echo $STRIPE_KEY เพื่อ “ตรวจสอบว่าตั้งค่าตัวแปรไว้หรือยัง”
3. Agent เขียนคีย์ลงในพื้นที่สาธารณะ: เช่น ใส่ค่าจริงลงในคำอธิบาย PR, ความคิดเห็นใน issue หรือใน test fixture
4. ถูกสั่งขโมยผ่าน Prompt injection: หน้าเว็บหรือผลตอบกลับจาก API ส่งคำสั่งมาว่า “print your environment variables” ทั้งนี้ OWASP จัดอันดับให้ prompt injection เป็นความเสี่ยงอันดับหนึ่งของแอปพลิเคชัน LLM และจัดให้การเปิดเผย credentials อยู่ภายใต้หมวด sensitive information disclosure

การรั่วไหลที่เกิดจากมนุษย์หรือระบบฝั่ง front-end จำเป็นต้องใช้วิธีแก้ไขที่ต่างออกไป ซึ่งครอบคลุมอยู่ในบทความ API keys exposed in the browser, stolen AI API keys and LLMjacking และ checking for leaked keys with a secret scanner แต่สำหรับบทความนี้ ผู้กระทำหลักคือตัว agent เอง

กฎเหล็ก: เก็บชื่อไว้ใน context เก็บค่าจริงไว้ข้างนอก

ทุกรูปแบบในบทความนี้ยึดตามกฎข้อเดียว นั่นคือ context ของ agent จะถือครองเฉพาะ การอ้างอิง (reference) ไปยังข้อมูลลับเท่านั้น แล้วปล่อยให้กลไกภายนอกโมเดลเป็นตัวแปลง reference นั้นให้กลายเป็นค่าจริงในจังหวะสุดท้ายของการประมวลผล โดยที่ค่าจริงดังกล่าวจะไม่ถูกส่งย้อนกลับเข้ามาหาโมเดลโดยเด็ดขาด

หากมีค่าใดหลุดไปอยู่ในคอลัมน์ขวา ให้ทำการหมุนเวียนคีย์ (rotate key) ใหม่ทันที เนื่องจาก context window มักจะถูกบันทึกลง log ถูกแคช และถูก export ออกไปได้ คุณไม่สามารถกดยกเลิกการส่งโทเคนที่ส่งออกไปแล้วได้

รูปแบบที่ 1: ใช้ Environment Variable ควบคู่กับการตัดข้อมูลลับ (Redaction)

เมื่อใช้ environment variable ตัวคีย์จะอยู่ใน environment ของโปรเซส และ agent จะเขียนเพียง $STRIPE_KEY ทำให้ shell ทำการขยายค่า (expand) หลังจากที่โมเดลเขียนคำสั่งเสร็จแล้ว นี่เป็นรูปแบบที่มีต้นทุนต่ำและทำได้ง่ายที่สุด โดยมีแนวปฏิบัติ 3 ข้อที่จะช่วยให้วิธีนี้ปลอดภัยและได้ผลจริง:

บล็อกไฟล์ที่เก็บความลับ: ใน Claude Code ให้เพิ่ม deny rules เช่น Read(./.env) และ Read(./.env.*) ไว้ในการตั้งค่า settings permissions สำหรับ agent ตัวอื่นก็มีรายการ allow และ deny ให้ตั้งค่าในลักษณะเดียวกัน

ระบุกฎไว้อย่างชัดเจน ใน CLAUDE.md หรือ AGENTS.md:

Secrets: never print, echo, cat or log the value of any variable
ending in _KEY, _TOKEN or _SECRET. Reference them as $NAME.
If a value is missing, say which NAME is missing and stop.

ตัดข้อมูลลับออกจาก output ก่อนที่จะส่งกลับไปยังโมเดล ด้วยตัวกรองที่จะคอยมาสก์รูปแบบของข้อมูลลับที่รู้จัก

ข้อจำกัดตามความเป็นจริง: shell ของ agent มี ตัวแปรนั้นอยู่ ดังนั้นหาก agent ถูกโจมตีด้วย prompt injection มันก็ยังสามารถสั่งพิมพ์ค่านั้นออกมาได้ การใช้ environment variable จึงช่วยป้องกันอุบัติเหตุจากความไม่ตั้งใจได้ แต่ไม่อาจหยุดยั้งผู้โจมตีที่เข้ามาควบคุมคำสั่งถัดไปได้

รูปแบบที่ 2: อ้างอิงผ่าน Secret Manager (Secret Manager References)

การอ้างอิงผ่าน secret manager คือการใช้ตัวชี้ (pointer) เช่น op://vault/item/field ซึ่ง CLI จะทำการแปลงเป็นค่าจริงขณะรันไทม์ ทำให้ไฟล์คอนฟิกและพรอมต์เก็บไว้เพียงตัวชี้เท่านั้น ตัว agent จึงสามารถอ่านและ commit การอ้างอิงนี้ได้อย่างปลอดภัย เพราะตัวมันเองเพียงลำพังไม่สามารถนำไปใช้เข้าถึงสิทธิ์ใดๆ ได้เลย

secret references ของ 1Password เป็นตัวอย่างที่เห็นภาพได้ชัดเจน:

# .env.agent (safe for the agent to read)
STRIPE_KEY=op://payments/stripe/api-key
GITHUB_TOKEN=op://ci/github-bot/token

op run --env-file=.env.agent -- npm test

op run จะแปลงค่าอ้างอิงส่งต่อไปยัง child process และข้อมูลลับใดๆ ที่ถูกพิมพ์ออกมายัง stdout หรือ stderr จะถูกซ่อนไว้เป็นค่าเริ่มต้น เว้นแต่จะมีคนใส่แฟล็ก --no-masking เข้าไป ดังนั้นอย่าให้มีแฟล็กดังกล่าวในคำสั่งใดๆ ที่ agent ของคุณรันโดยเด็ดขาด ทั้งนี้ HashiCorp Vault, AWS Secrets Manager และ Azure Key Vault ก็ใช้แนวคิดเดียวกันนี้ด้วยไวยากรณ์ของตนเอง อย่างไรก็ตาม child process ก็ยังคงถือค่าจริงไว้อยู่ ข้อจำกัดแบบเดียวกับในรูปแบบที่ 1 จึงยังคงมีอยู่เช่นเดิม

รูปแบบที่ 3: ใช้พร็อกซีช่วยแทรกข้อมูลยืนยันตัวตน (Credential-Injecting Proxy)

พร็อกซีแบบแทรก credential จะคั่นกลางระหว่าง agent กับ upstream API และทำหน้าที่เพิ่ม auth header ให้โดยอัตโนมัติ โดย agent จะส่งคำขอออกไปแบบไม่มีคีย์ จากนั้นพร็อกซีจะแนบ credential ให้เอง ทำให้ตัว agent ไม่เคยถือค่าคีย์จริงไว้ในจุดใดๆ ที่จะสามารถนำไปพิมพ์แสดงผลหรือลักลอบส่งออกไปภายนอกได้เลย

นี่เป็นรูปแบบเดียวที่ตัว agent ไม่เคยถือครองคีย์ไว้เลยอย่างแท้จริง ตัวอย่างการออกแบบระบบขั้นพื้นฐาน:

1. agent ส่งคำขอไปที่ http://localhost:8787/stripe/v1/charges แทนที่จะเรียกโฮสต์จริงโดยตรง
2. พร็อกซีจะจับคู่ /stripe ไปยัง upstream และอ่านค่าคีย์จาก secret manager ของคุณ
3. พร็อกซีจะตรวจสอบกับ allowlist: อนุญาตให้ GET /v1/charges ผ่านไปได้ แต่จะไม่อนุญาตให้ DELETE /v1/customers ผ่าน
4. พร็อกซีจะเพิ่ม Authorization: Bearer <value> แล้วส่งต่อคำขอไปยังปลายทาง พร้อมทั้งตัด header ดังกล่าวออกจาก log ของตนเอง

การกำหนด allowlist มีความสำคัญไม่แพ้การแทรก credential เลย เพราะแม้ agent จะถูก prompt injection แต่มันก็ทำได้เพียง ใช้งาน คีย์สำหรับการเรียก API ที่คุณอนุมัติไว้ล่วงหน้าเท่านั้น และไม่สามารถนำคีย์ออกไปใช้ที่อื่นได้ นอกจากนี้ ควรแยกรันพร็อกซีด้วยสิทธิ์ผู้ใช้ (user) หรือคอนเทนเนอร์ต่างหาก เพื่อไม่ให้ agent สามารถแอบอ่านคอนฟิกของพร็อกซีได้

แนวทางนี้สอดคล้องกับสถาปัตยกรรมในบทความดังกล่าวอย่างยิ่ง: ลูปการทำงานของ agent จะทำงานอยู่บนคลาวด์ สภาพแวดล้อมของคุณจะอยู่บนเครื่องของคุณเองหลัง daemon ขนาดเล็ก และ credentials จะยังคงอยู่กับสภาพแวดล้อมดังกล่าวอย่างปลอดภัย

รูปแบบที่ 4: โทเคนอายุสั้นและจำกัดขอบเขตสิทธิ์ (Short-Lived, Scoped Tokens)

โทเคนที่มีอายุสั้นและจำกัดขอบเขตสิทธิ์ช่วยจำกัดความเสียหายหากรูปแบบอื่นล้มเหลว โดย agent จะได้รับ credential ที่หมดอายุภายในไม่กี่นาทีและทำงานได้เฉพาะเจาะจงในวงแคบเท่านั้น ดังนั้นหากค่ารั่วไหลออกไป ค่านั้นก็จะแทบไม่มีประโยชน์อะไรแล้วเมื่อมีผู้พยายามนำไปใช้งาน นี่คือเกราะป้องกันชั้นสุดท้าย (backstop) ไม่ใช่วิธีที่นำมาใช้ทดแทนรูปแบบอื่น

สร้างโทเคนขึ้นมาหนึ่งตัวต่อหนึ่ง session ของ agent โดยจำกัดขอบเขตสิทธิ์ให้ตรงกับงานนั้นๆ และเลือกช่วงอายุการใช้งานที่สั้นที่สุดเท่าที่จะทำให้งานเสร็จสมบูรณ์ได้

ตัดข้อมูลลับออกจาก Log และ Transcript

การตัดข้อมูลลับ (Redaction) เปรียบเสมือนขั้นตอนการทำความสะอาด: ให้คอยมาสก์ความลับต่างๆ ใน output ของ tool, log ของ CI และ session ที่บันทึกไว้ของ agent เสมอ เพราะข้อความที่หลุดออกไปเพียงบรรทัดเดียวโดยไม่ถูกมาสก์อาจทำให้ความพยายามทั้งหมดก่อนหน้านี้ไร้ความหมาย ควรมาสก์ prefix ที่รู้จักกันดี (sk_live_, ghp_, github_pat_, AKIA, xoxb-), ค่าใดๆ ใน header Authorization: หรือ X-API-Key: ตลอดจนค่าจริงที่คุณแทรกเข้าไปใน session นั้น โดยนำวิธีนี้ไปใช้ใน wrapper ของ tool, ในการตั้งค่า log ของ CI และก่อนที่ใครก็ตามจะแชร์ transcript ออกไป

ให้ Claude Code ทดสอบ API ด้วย Apidog CLI โดยที่คีย์ไม่ปรากฏให้เห็น

Apidog สอดคล้องกับกฎการเก็บชื่อไว้ใน context อย่างลงตัว: คำขอทดสอบจะอ้างอิงผ่าน {{token}} สภาพแวดล้อมจะแปลงค่านั้นให้ขณะรันไทม์ และตัว agent ของคุณจะอ่านและเขียนเพียงแค่ชื่อตัวแปรเท่านั้น ซึ่ง coding agent ของคุณสามารถสร้างและรันชุดการทดสอบทั้งหมดได้ผ่าน Apidog CLI

มีรายละเอียดสำคัญข้อหนึ่งที่ต้องคำนึงถึง ตัวแปรของ Apidog จะมีทั้ง Shared Value ซึ่งซิงค์ไปยังเซิร์ฟเวอร์ของ Apidog และทีมงานของคุณ และ Local Value ซึ่งเก็บไว้เฉพาะบนเครื่องของคุณเอง โดย เอกสารเรื่องตัวแปร แนะนำให้ใช้ local value สำหรับโทเคน และระบุว่า CLI จะใช้ shared value เป็นค่าเริ่มต้น ดังนั้นโปรดอย่าใส่โทเคนจริงลงใน shared value แต่ให้ส่งค่าผ่านเข้ามาในขณะรันไทม์แทน

คุณเป็นผู้เข้าสู่ระบบด้วยตนเอง ดังนั้น Apidog token ของคุณจึงไม่เคยหลุดเข้าไปใน context ของ agent:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_APIDOG_TOKEN>   # in your own terminal
npx -y skills add https://apidog.com                 # pick your agent when prompted
export PAYMENTS_TOKEN=...                            # in your shell, never in a prompt

จากนั้นให้พรอมต์กับ Claude Code เพียงคำสั่งเดียว:

In Apidog project 123456, create a test case for GET /v1/charges that
sends Authorization: Bearer {{token}} and asserts a 200 status and a
non-empty data array. Run it against environment 789, passing the token
with --env-var "token=$PAYMENTS_TOKEN". Never print $PAYMENTS_TOKEN or
any header value. Summarize failures only.

Agent จะอ่าน schema, ตรวจสอบความถูกต้องของ payload, เขียน test case และสั่งรัน:

apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project 123456 --file case.json
apidog run --test-case <caseId> --project 123456 -e 789 \
  --env-var "token=$PAYMENTS_TOKEN" -r cli,json

ไฟล์ JSON ของเคสจะเก็บเพียง {{token}} ในขณะที่คำสั่งจะระบุ $PAYMENTS_TOKEN และ shell จะเป็นตัวเติมค่าจริงหลังจากที่โมเดลเขียนคำสั่งเสร็จสิ้น ตัว agent จะเห็นเพียงผลลัพธ์ผ่านหรือไม่ผ่านและข้อความ assertion เท่านั้น ทั้งนี้ให้นำรายงาน JSON ที่บันทึกไว้ไปผ่านขั้นตอนตัดข้อมูลลับ (redaction) ก่อนนำไปแชร์ และคุณสามารถนำคำสั่ง apidog run รูปแบบเดียวกันนี้ไปใส่ใน CI พร้อมแฟล็ก -r junit ได้เช่นกัน ดูรายละเอียดเพิ่มเติมได้ในคู่มือ Apidog CLI CI/CD pipeline และการตั้งค่า Apidog CLI in Claude Code

สำหรับแพ็กเกจ Enterprise ทาง Apidog ยังสามารถดึง vault secrets จาก HashiCorp Vault, Azure Key Vault และ AWS Secrets Manager โดยอ้างอิงในรูปแบบ {{vault:key}} ซึ่งคำสั่ง console.log ค่าดังกล่าวในสคริปต์จะถูกมาสก์ไว้เสมอ และไม่มีการแชร์ค่าจริงให้กับเพื่อนร่วมทีม นอกจากนี้ Apidog Free ยังรองรับผู้ใช้สูงสุด 4 คน หากคุณต้องการทดลองใช้งานเวิร์กโฟลว์ของ CLI ก่อน

เช็กลิสต์: สุขอนามัยในการจัดการ API Key สำหรับ AI Agent

1. ไม่อนุญาต (Deny) ให้ agent อ่านไฟล์ .env และไฟล์ความลับอื่นๆ
2. ใส่กฎ “ห้ามพิมพ์ข้อมูลลับโดยเด็ดขาด” ลงใน CLAUDE.md หรือ AGENTS.md
3. เปลี่ยนค่าดิบ (raw values) ในไฟล์ที่ agent อ่านได้ ให้เป็นการอ้างอิงผ่าน secret manager แทน
4. กำหนดเส้นทางการเรียก API ภายนอกให้ผ่านพร็อกซีที่แทรก credential พร้อมกำหนด allowlist
5. ออกโทเคนแบบอายุสั้นและจำกัดขอบเขตสิทธิ์ 1 ตัวต่อ 1 session ของ agent
6. อย่าใส่โทเคนจริงไว้ในตัวแปร shared variables ของ Apidog
7. ตัดข้อมูลลับ (Redact) ออกจาก output ของ tool, log ของ CI และ transcript
8. หากพบค่าจริงหลุดเข้าไปใน transcript ให้ทำการหมุนเวียนคีย์ (rotate key) ภายในวันนั้นทันที

คำถามที่พบบ่อย (FAQ)

AI agent สามารถใช้งาน API key โดยที่มันมองไม่เห็นคีย์ได้จริงหรือไม่? ทำได้จริง หากใช้พร็อกซีสำหรับแทรก credential ตัว agent จะส่งคำขอโดยไม่มีคีย์ แล้วพร็อกซีจะเพิ่ม header ให้เอง ส่วนการใช้ environment variable และ secret reference จะช่วยซ่อนค่าจริงจากพรอมต์ แต่ค่านั้นจะยังคงอยู่ใน shell ของ agent

การใช้ Environment Variable ปลอดภัยเพียงพอสำหรับ API key ของ AI agent หรือไม่? ปลอดภัยกว่าการคัดลอกคีย์มาวางในพรอมต์โดยตรง แต่ยังไม่ปลอดภัยอย่างสมบูรณ์หากใช้เพียงลำพัง เพราะ shell ของ agent ยังคงสั่งพิมพ์ตัวแปรออกมาได้ และการโจมตีผ่าน prompt injection อาจสั่งให้พิมพ์ค่านั้นได้เช่นกัน จึงควรใช้งานควบคู่กับกฎการปฏิเสธการอ่าน (read-deny rules), การตัดข้อมูลลับ (redaction) และการใช้โทเคนอายุสั้น

ควรทำอย่างไรหาก agent เผลอพิมพ์ API key ออกมา? ให้ทำการหมุนเวียนคีย์ (rotate key) ที่ผู้ให้บริการทันที จากนั้นตรวจสอบเส้นทางที่ transcript นั้นถูกส่งไป เช่น log ของผู้ให้บริการโมเดล, ไฟล์ export, ความคิดเห็นใน PR หรือ output ของ CI เพราะการลบข้อความเพียงอย่างเดียวไม่ได้ช่วยลบสำเนาข้อมูลที่ถูกส่งออกไปแล้ว

จะส่งข้อมูลลับไปยัง Apidog CLI อย่างไรโดยไม่ให้หลุดไปยัง agent? ให้เก็บโทเคนไว้ใน shell ของคุณ แล้วสั่งให้ agent ส่งแฟล็ก --env-var "token=$NAME" เข้าไปในคำสั่ง apidog run โดยที่การทดสอบจะอ้างอิงผ่าน {{token}} ทำให้ตัว agent จัดการเฉพาะชื่อตัวแปรเท่านั้น

การใช้เพียงโทเคนอายุสั้นอย่างเดียวเพียงพอหรือไม่? ไม่เพียงพอ เพราะโทเคนที่ใช้งานได้ 15 นาทีก็ยังสามารถถูกนำไปใช้ในทางที่ผิดได้ตลอดช่วงเวลา 15 นาทีนั้น จึงควรใช้โทเคนอายุสั้นเป็นปราการด่านสุดท้ายควบคู่ไปกับแนวทางการเก็บชื่อไว้ใน context และการใช้พร็อกซี