นโยบายการเข้าถึงสำหรับ AGENT

กำหนดเส้นทาง AI agent ด้วยนโยบายที่คุณควบคุมได้

ตัดสินว่าระบบของคุณจะปฏิบัติต่อผู้ใช้ที่เป็นคน, ผู้ใช้ที่มี AI ช่วย และ autonomous agent อย่างไร แยกตาม route. Proof of Actor เป็นผู้ให้หลักฐาน ส่วนการตัดสินใจเป็นนโยบายของคุณเอง

ขอสิทธิ์เข้าถึงก่อนใคร สำรวจวิธีการทำงาน

โดย Toshendra Sharmaผู้ก่อตั้งและ CEO, AgentCredia · Updated November 13, 2026

นโยบายเดียวสำหรับทุกคนไม่เพียงพออีกต่อไป

แอปพลิเคชันส่วนใหญ่ถูกออกแบบโดยมีผู้ใช้เพียงประเภทเดียว คือคนที่คลิกผ่าน interface และลงชื่อเข้าใช้บัญชี การควบคุมการเข้าถึงก็อิงสมมติฐานนั้น ถ้า session ถูกต้อง request ก็ผ่าน ถ้าดูเหมือนเป็นแบบอัตโนมัติ ก็จะมี CAPTCHA หรือการบล็อกขึ้นมา

โมเดลนั้นกำลังพัง วันนี้แอปพลิเคชันเดียวกันต้องรองรับทั้งคน, คนที่ใช้ AI assistant ช่วย และ autonomous agent ที่ทำงานแทนใครบางคน บาง agent เป็น integration ของลูกค้าเอง บางส่วนเป็น AI assistant ที่ดึงเอกสาร บางส่วนเป็น crawler และบางส่วนพยายามใช้ประโยชน์จากผลิตภัณฑ์ของคุณ กฎแบบตอบ yes-or-no เพียงข้อเดียวไม่สามารถรองรับทั้งหมดได้ดี

นโยบายการกำหนดเส้นทางและการเข้าถึงสำหรับ AI agent จะแทนที่กฎเดิมด้วยชุดของการตัดสินใจที่ชัดเจนว่า actor ใดควรได้รับประสบการณ์แบบไหน บน route ใด ภายใต้เงื่อนไขใด Proof of Actor ให้หลักฐานแก่ระบบของคุณเพื่อใช้ตัดสินใจ และปล่อยให้การตัดสินใจเหล่านั้นอยู่ในมือคุณเอง หากต้องการดูหลักการออกแบบเบื้องหลังแนวทางนี้ ให้อ่าน การออกแบบนโยบายของแอปสำหรับคนและ AI agent และดู กรณีใช้งานสำหรับ SaaS apps เพื่อดูว่านโยบายแมปเข้ากับ workflow ของผลิตภัณฑ์จริงอย่างไร

นโยบาย agent ที่ดีมีลักษณะอย่างไร

นโยบายที่มีประโยชน์ต้องเฉพาะเจาะจง ระบุ route หรือ workflow, class ของ actor, ความเข้มของหลักฐานที่ต้องใช้ และการตอบสนอง ตัวอย่างเช่น:

route ของแคตตาล็อกแบบอ่านอย่างเดียว: allow verified agent และส่ง structured response; allow declared agent ด้วย rate limit มาตรฐาน
การกระทำที่เปลี่ยนแปลงบัญชี: ใช้ re-authentication แบบเดิมสำหรับทุกคน; เพิ่ม review เมื่อ actor เป็น Unknown และการกระทำนั้นมีผลกระทบสูง
การส่งคำขอไปยังฝ่าย support: ยอมรับเนื้อหาที่เปิดเผยว่าเป็น AI-assisted และติดป้ายกำกับเพื่อกำหนดเส้นทาง
Signup: คงการตรวจสอบเดิมไว้; ไม่ตัดสินจาก inferred actor result เพียงอย่างเดียว

แต่ละกรณีตอบสนองต่อ actor โดยไม่มองว่า agent ทุกตัวคือการละเมิด และไม่ไว้ใจ agent ทุกตัวแบบไม่มีเงื่อนไข ความสมดุลนี้คือแก่นของ access ที่รับรู้ถึง agent และบทความเกี่ยวกับ การออกแบบนโยบายของแอปสำหรับคนและ AI agent จะไล่ตัวอย่างเพิ่มเติมทีละ route

การตอบสนองทั้งห้าแบบ

ความสามารถด้าน Route ของ Proof of Actor สร้างขึ้นรอบการตอบสนอง 5 แบบที่นโยบายของคุณเลือกได้

Allow

ปล่อยให้ request ดำเนินต่อไปตามปกติ ทราฟฟิกส่วนใหญ่ รวมถึงทราฟฟิกจาก agent ส่วนใหญ่บน route สาธารณะหรือ route ความเสี่ยงต่ำ ควรถูก allow อย่างง่าย

Adapt

เปลี่ยนประสบการณ์ให้เหมาะกับ actor ส่ง structured API response หรือ Markdown version ของหน้าให้ verified agent แทน interface ที่ออกแบบมาสำหรับคน คู่มือ การให้เนื้อหาแบบมีโครงสร้างแก่ AI agent อธิบายรูปแบบนี้

Challenge

ขอสิ่งที่เข้มงวดกว่า เช่น การเข้าสู่ระบบใหม่, credential เพิ่มเติม, การยืนยันจากเจ้าของบัญชี ใช้ challenge บน route ที่ต้นทุนของการตัดสินใจผิดสูง

Review

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

Limit

กำหนด rate หรือ volume limit ให้เหมาะกับ actor และ route เพื่อให้ caller ที่ทำงานอัตโนมัติไม่สามารถถาโถม workflow ที่ออกแบบมาสำหรับคนได้

ทำไม robots.txt จึงไม่ใช่นโยบายการเข้าถึง

หลายทีมเริ่มจาก robots.txt และมันเป็นสัญญาณแรกที่เหมาะสมสำหรับ crawler แต่ไม่ใช่นโยบายการเข้าถึงสำหรับ agent ผู้ให้บริการ crawler ระบุพฤติกรรมที่ต่างกันตาม user agent ที่ต่างกัน: Anthropic ระบุว่าบอทของตนเคารพคำสั่ง robots.txt (Anthropic crawler documentation), ขณะที่ OpenAI ระบุว่า ChatGPT-User ซึ่งทำงานเมื่อผู้ใช้ถามคำถามกับ ChatGPT นั้น rules ของ robots.txt อาจไม่ใช้ เพราะการกระทำนั้นเริ่มต้นโดยผู้ใช้ (OpenAI crawler documentation) robots.txt ยังไม่บอกอะไรเกี่ยวกับ API, เครื่องมือ MCP หรือ workflow ที่ลงชื่อเข้าใช้

นโยบายการเข้าถึงต้องทำงานตรงจุดที่ request ถูกจัดการ ต้องอ่านหลักฐาน เช่น signature ที่ตรวจสอบภายใต้ RFC 9421 และเลือกการตอบสนองเป็นราย route สำหรับ MCP server, ข้อกำหนดการอนุญาตของ MCP กำหนดวิธีที่ client จะได้ access token ผ่าน HTTP; นโยบาย actor จะเพิ่มบริบทเข้าไปบนสิ่งนั้น ไม่ได้แทนที่มัน

Proof of Actor ป้อนข้อมูลให้นโยบายของคุณอย่างไร

ทุก request ที่ integration ของคุณประเมินจะให้ผลลัพธ์ของ actor ที่มี 4 ส่วนให้ policy อ่านได้:

Class: Human, Human + AI, Agent หรือ Unknown
Basis: verified, declared, inferred หรือ unknown เพื่อให้นโยบายของคุณปฏิบัติต่อ signature ที่ตรวจสอบแล้วต่างจาก client name ที่ประกาศเอง
Evidence summary: คำอธิบายที่อ่านได้ว่าผลลัพธ์นี้อาศัยอะไร ซึ่งมีประโยชน์สำหรับ logging และ review
Context: integration ใดและ route ใดเป็นผู้สร้างผลลัพธ์นี้

เพราะ basis ระบุไว้อย่างชัดเจน นโยบายของคุณจึงแม่นยำได้ "allow agents" จะกลายเป็น "allow verified agents บน route สำหรับการอ่าน, rate-limit declared agents, ใช้ Unknown fallback กับทุกอย่างที่เหลือ" กระบวนการตั้งแต่ request ไปจนถึง decision อธิบายไว้ใน How It Works

Fallback เป็นส่วนหนึ่งของนโยบาย

นโยบายจะดีได้ก็ต่อเมื่อพฤติกรรมเมื่อไม่มีหลักฐานก็ชัดเจนเช่นกัน Proof of Actor ทำให้กรณีเหล่านี้ชัดเจนแทนที่จะซ่อนไว้

Unknown: หลักฐานไม่เพียงพอที่จะสรุปได้ นโยบายของคุณระบุว่า Unknown หมายถึงอะไรในแต่ละ route มันจะไม่ถูกแปลงเป็น Human และจะไม่ถูกถือว่าเป็นอันตรายโดยค่าเริ่มต้น
Timeout: ผลลัพธ์มาไม่ทันเวลา integration ของคุณจะใช้ fallback ที่คุณเลือกไว้สำหรับ route นั้น
Missing signals: ตัวเก็บข้อมูลไม่ทำงาน หรือ header หายไป ผลลัพธ์จะแสดงสิ่งนั้น และ policy ของคุณจะปฏิบัติตามนั้น

สำหรับแต่ละ route คุณเป็นผู้เลือกว่าจะ fail open หรือ fail closed การ fail open หมายถึง request จะดำเนินต่อไปเหมือนที่ทำได้หากไม่มี Proof of Actor; การ fail closed หมายถึงจะใช้การตรวจสอบที่เข้มงวดกว่าเดิมของคุณ Route ความเสี่ยงต่ำมัก fail open การกระทำที่อ่อนไหวมัก fail closed คุณกำหนดสิ่งนี้ตามระดับความเสี่ยง ไม่ใช่กำหนดแบบรวมทั้งหมด

แยก identity, credential และ authorization ออกจากกัน

นโยบายการเข้าถึงสำหรับ agent อยู่บน 3 ชั้นที่แยกจากกัน และการแยกชั้นเหล่านี้ช่วยป้องกันความผิดพลาดที่ร้ายแรงที่สุด

Identity evidence ตอบคำถามว่าใครกำลังเรียกและมีอะไรพิสูจน์ได้บ้าง Proof of Actor เป็นผู้ให้ส่วนนี้
Credentials ตอบว่าบัญชีใดเป็นผู้รับผิดชอบ session, token หรือ API key ของคุณเป็นผู้ให้ส่วนนี้
Authorization ตอบว่าผู้เรียกนี้ทำการกระทำนี้ได้หรือไม่ โมเดลสิทธิ์ของคุณเป็นผู้ให้ส่วนนี้

การมี agent identity ที่ verified ไม่ได้แปลว่า agent นั้นได้รับอนุญาต ไม่ได้แปลว่ามีคนมอบอำนาจให้มัน หรือการกระทำนั้นปลอดภัย ใช้ผลลัพธ์ของ actor เพื่อกำหนดเส้นทางและเพิ่มบริบท ใช้โมเดล authorization ของคุณเพื่อให้สิทธิ์ หน้าที่ในหน้า Detection & Limitations อธิบายอย่างชัดเจนว่าแต่ละประเภทของหลักฐานพิสูจน์อะไรได้บ้าง

ปล่อยใช้งานโดยไม่ทำให้ระบบเสียหาย

วิธีที่ปลอดภัยที่สุดในการนำนโยบายการเข้าถึงสำหรับ agent มาใช้คือค่อย ๆ ทำเป็นขั้น

Observe. ติดตั้ง Proof of Actor ใน โหมดการสังเกต ไม่มีอะไรเปลี่ยนสำหรับผู้ใช้ของคุณ ผลลัพธ์จะถูกบันทึกไว้
Understand. ตรวจดูว่า actor ใดใช้ route ใด, อัตรา Unknown ของแต่ละ route และผลลัพธ์ใดที่ไม่ตรงกับสิ่งที่คุณรู้อยู่แล้ว
Preview. รัน policy แบบ preview โดยบันทึกว่ามันจะทำอะไรโดยยังไม่บังคับใช้
Enforce narrowly. เปิดใช้นโยบายใน route เดียวที่หลักฐานสนับสนุนอย่างชัดเจน ติดตามผลลัพธ์
Expand. ขยายไปยัง route อื่นมากขึ้นเมื่อความมั่นใจเพิ่มขึ้น

คู่มือ การปล่อยใช้นโยบายที่รับรู้ actor อย่างปลอดภัย จะไล่แต่ละขั้น และ การปกป้องการกระทำที่อ่อนไหวโดยไม่บล็อก agent ครอบคลุม route ที่มีความเสี่ยงสูง

ทีมของคุณจะได้อะไร

ด้วย Proof of Actor ทีมของคุณจะได้ integration เดียวที่มีความสามารถ 3 ส่วน Detect รวบรวมสัญญาณของ actor และแยกข้อยืนยันที่ตรวจสอบแล้วออกจากข้อสรุป Understand แสดง analytics ของ actor, แนวโน้ม และหลักฐานเบื้องหลังแต่ละผลลัพธ์ โดยยังคง Unknown ให้มองเห็นได้ Route ให้คุณเขียนนโยบายตามที่อธิบายในหน้านี้ และนำไปใช้ในจุดที่คุณเลือก ระหว่าง private beta นโยบายการกำหนดเส้นทางถูกออกแบบร่วมกับแต่ละ founding team และรันใน application code ของคุณเอง คุณจึงควบคุมได้เต็มที่

ความผิดพลาดด้านนโยบายที่พบบ่อยและควรหลีกเลี่ยง

ทีมที่ออกแบบการเข้าถึงสำหรับ agent เป็นครั้งแรกมักทำผิดซ้ำไม่กี่เรื่อง การหลีกเลี่ยงสิ่งเหล่านี้ช่วยประหยัดเวลาการแก้ไขซ้ำได้หลายสัปดาห์

บล็อก agent ทุกตัวโดยค่าเริ่มต้น. จากนั้น agent ที่ถูกต้องตามกฎหมายจะหาทางอ้อมเข้ามา บ่อยครั้งโดย scraping interface ที่คุณสร้างไว้สำหรับคน ซึ่งป้องกันได้ยากกว่าการมี path แบบมีโครงสร้าง
เชื่อชื่อที่ประกาศเอง. client ที่บอกชื่อของตัวเองเท่านั้นคือการอ้างสิทธิ์ ไม่ใช่หลักฐาน ให้การปฏิบัติเหมือนกับ caller ที่ยังไม่ verified
ใช้ fallback เดียวทุกที่. Unknown บนหน้า pricing สาธารณะกับ Unknown ตอนเปลี่ยนรหัสผ่านไม่ใช่สถานการณ์เดียวกัน แต่ละ route ต้องมีคำตอบของตัวเอง
ตัดสินเรื่องคนจาก inference. ผลลัพธ์ของ actor เป็นบริบทสำหรับ routing ไม่ใช่คำตัดสินเกี่ยวกับบุคคล เก็บการตัดสินใจที่มีผลกระทบไว้กับการควบคุมและ review ของคุณเอง
ข้ามขั้นตอนการสังเกต. การบังคับใช้ตั้งแต่วันแรกหมายความว่าคุณจะพบ false positive ผ่านการร้องเรียนของลูกค้า ก่อนอื่นให้สังเกต แล้วค่อยบังคับใช้ในจุดที่หลักฐานชัดเจน

การ review นโยบายสั้น ๆ กับผู้รับผิดชอบด้าน security, product และ support ก่อนแต่ละขั้นของการบังคับใช้ จะช่วยจับข้อผิดพลาดเหล่านี้ได้ส่วนใหญ่ตั้งแต่เนิ่น ๆ

เริ่มต้นด้วยโครงการสำหรับ founding developer

Proof of Actor อยู่ใน private beta ทีมพัฒนา founding ที่ผ่านการคัดเลือกสามารถรับสิทธิ์ใช้งานฟรีได้นานสูงสุด 12 เดือน ภายใต้ขอบเขตการใช้งานที่ตกลงกัน พร้อมการสนับสนุนโดยตรงจากวิศวกรของเราในขณะที่คุณออกแบบนโยบายแรก ๆ

หากคุณกำลังตัดสินใจว่าระบบของคุณควรปฏิบัติต่อ AI agent อย่างไร สมัครขอ early access บอกเราว่า route ใดสำคัญที่สุดและคุณต้องการตัดสินใจเรื่องใดบ้าง แล้วเราจะช่วยคุณสร้างนโยบายที่เหมาะสม คุณยังสามารถดูว่ามันนำไปใช้กับ APIs และ MCP server อย่างไรได้ด้วย

แหล่งอ้างอิง

Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.
Overview of OpenAI crawlers, OpenAI.
RFC 9421: HTTP Message Signatures, IETF, February 2024.
MCP authorization, modelcontextprotocol.io.

สำหรับนักพัฒนา

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent หรือ Unknown
basis: ระดับความแข็งแรงของหลักฐาน: Verified, Declared, Inferred หรือ Unknown
evidence: สัญญาณที่อยู่เบื้องหลังผลลัพธ์ เพื่อให้ทีมของคุณเห็นเหตุผล

เริ่มในโหมด observation: บันทึกผลลัพธ์ไว้ข้าง log ของคุณ และไม่เปลี่ยนแปลงอะไรจนกว่าคุณจะเลือกนโยบาย อ่านคู่มือการเชื่อมต่อ Node.js

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

นโยบายการเข้าถึงสำหรับ AI agent คืออะไร?

คือนโยบายที่ระบบของคุณนำมาใช้ตามประเภทของ actor ที่ส่ง request เช่น อนุญาต verified agent บน route แบบอ่านอย่างเดียว หรือขอ credential ที่เข้มงวดขึ้นสำหรับการกระทำที่มีผลสูง Proof of Actor ให้ผลลัพธ์ของ actor ส่วน policy ของคุณเป็นผู้ตัดสินการตอบสนอง

Proof of Actor บังคับใช้นโยบายโดยอัตโนมัติหรือไม่?

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

จะเกิดอะไรขึ้นเมื่อ actor เป็น Unknown หรือการตรวจสอบหมดเวลา?

คุณกำหนด fallback แบบชัดเจนสำหรับแต่ละ route เช่น allow การอ่านสาธารณะ และคงการตรวจสอบเดิมไว้สำหรับการเปลี่ยนข้อมูลบัญชี Unknown และ timeout จะไม่ถูกตีความเป็น Human โดยค่าเริ่มต้น

ควรบล็อก AI agent ทั้งหมดหรือไม่?

โดยทั่วไปไม่ควร agent จำนวนมากเป็นผู้มีส่วนร่วมที่ถูกต้องตามกฎหมาย นโยบายช่วยให้คุณกำหนดเส้นทางที่มีโครงสร้างให้พวกเขา จำกัดในจุดที่สำคัญ และเก็บการตรวจสอบที่เข้มงวดกว่าไว้สำหรับการกระทำที่อ่อนไหว

นโยบายสามารถตัดสินเรื่องที่เกี่ยวกับคนได้หรือไม่?

ผลลัพธ์ของ Proof of Actor ไม่ควรเป็นฐานเพียงอย่างเดียวสำหรับการตัดสินใจที่มีผลกระทบต่อบุคคล เช่น การจ้างงาน เครดิต หรือการเข้าถึงบริการจำเป็น ควรใช้เพื่อการกำหนดเส้นทางและให้บริบท ร่วมกับการควบคุมของคุณเอง

รู้ว่าใครกำลังใช้แอปของคุณ

private beta สำหรับกลุ่มเล็กๆ ของ founding developers

ขอสิทธิ์เข้าถึงก่อนใคร ดูราคา

อยากคุยก่อนหรือไม่ พูดคุยกับผู้ก่อตั้ง