เว็บไซต์ของคุณตอนนี้มีผู้เข้าชมมากกว่าหนึ่งประเภท
ตลอดประวัติส่วนใหญ่ของเว็บ เว็บไซต์หนึ่งแห่งอาจสมมติรูปแบบง่าย ๆ ได้ว่า มีคนเปิด browser คลิกไปมา และอาจ sign in บ้าง Analytics, rate limits, onboarding flows และ security checks ต่างก็ถูกออกแบบมารองรับคนนั้น
โมเดลนั้นไม่อธิบาย traffic จริงอีกต่อไปแล้ว ทุกวันนี้เว็บไซต์เดียวต้องรองรับคนที่ browse ด้วยตัวเอง, คนที่ขอให้ AI assistant สรุปหรือกรอกบางอย่างแทน, autonomous agents ที่อ่านหน้าและเรียก endpoint ในนามของคนอื่น, และ script กับ crawler จำนวนมาก ผู้ให้บริการ AI เองก็เอกสารรองรับผู้เข้าชมเหล่านี้บางส่วนเช่นกัน: OpenAI เช่น เผยแพร่ user agent แยกกันสำหรับ search crawler, training crawler และ fetcher ที่เข้าไปดูหน้าเมื่อผู้ใช้ ChatGPT ถามคำถาม (OpenAI crawler documentation), และ Anthropic ก็ทำเช่นเดียวกันสำหรับ ClaudeBot, Claude-User และ Claude-SearchBot (Anthropic crawler documentation). ผู้เข้าชมบางส่วนเหล่านี้เป็นสิ่งที่ต้องการต้อนรับ บางส่วนต้องการประสบการณ์ที่ต่างออกไป บางส่วนต้องได้รับการพิจารณาใกล้ชิดก่อนจะทำสิ่งที่อ่อนไหวได้
ความท้าทายคือการโต้ตอบเหล่านี้ส่วนใหญ่ดูคล้ายกันในแวบแรก การ sign in บอกได้ว่าใช้งาน account ใดอยู่ แต่ไม่ได้บอกว่ามีคนกำลังคลิกอยู่, assistant กำลังทำงานผ่าน session นั้น, หรือ client อัตโนมัติกำลังอ่านหน้า pricing ของคุณให้ผู้ใช้ที่อยู่อีกแห่งหนึ่ง AI agent detection for websites คือการปิดช่องว่างนั้นด้วยหลักฐาน เพื่อให้ทีมของคุณตอบสนองต่อ actor แต่ละประเภทอย่างเหมาะสม แทนที่จะปฏิบัติต่อ traffic ทั้งหมดเหมือนกัน อ่าน how to tell if website traffic comes from AI agents เพื่อดูภาพรวมเชิงปฏิบัติของสัญญาณที่เกี่ยวข้อง และดู websites use case ว่าสิ่งนี้มีหน้าตาอย่างไรบนเว็บไซต์ที่ใช้งานจริง
ทำไม bot score เพียงค่าเดียวจึงไม่พอ
เครื่องมือจำนวนมากตอบคำถามนี้ด้วยตัวเลขเดียว: bot score, risk score, เปอร์เซ็นต์ที่อ้างว่าอธิบายได้ว่าผู้เข้าชมมีความเป็นมนุษย์มากแค่ไหน ข้อดีนั้นชัดเจน ตัวเลขเดียวใส่เข้า rule ได้ง่าย
แต่ปัญหาคือคะแนนเดียวทำให้เหตุผลเบื้องหลังหายไป เมื่อคะแนนบอกว่า session น่าจะเป็นอัตโนมัติ ทีมของคุณจะมองไม่เห็นว่าข้อสรุปนั้นอาศัยลายเซ็นที่ยืนยันได้, user-agent string ที่ใครก็ลอกได้, หรือรูปแบบที่อาจตรงกับมนุษย์ที่พิมพ์เร็ว เมื่อคะแนนนั้นเป็นตัวตัดสินว่าจะ block หรือ challenge คุณจะรับความผิดพลาดทั้งหมดของมันมาโดยไม่มีทางอธิบายให้ customer, เพื่อนร่วมงาน หรือ auditor ฟังได้
Proof of Actor ใช้วิธีที่ต่างออกไป ผลลัพธ์ทุกครั้งเป็นหนึ่งในสี่ class ที่ชัดเจน อธิบายไว้ใน Human, AI-assisted or agent: a taxonomy for app traffic และผลลัพธ์ทุกครั้งจะบอกด้วยว่าอ้างอิงจากอะไร คุณจะเห็นข้อสรุปและหลักฐานไปพร้อมกัน ซึ่งหมายความว่าคุณสามารถเชื่อถือผลลัพธ์ที่แข็งแรง, ตั้งคำถามกับผลลัพธ์ที่อ่อน, และสร้าง policies ที่สอดคล้องกับคุณภาพของหลักฐานได้
วิธีตรวจจับ AI agents บนเว็บไซต์ของคุณใน 4 ขั้นตอน
คุณสามารถเริ่มตรวจจับ AI agents บนเว็บไซต์ของคุณด้วยเครื่องมือที่มีอยู่แล้วได้ 4 ขั้นตอนนี้เป็น vendor-neutral และใช้งานได้ไม่ว่าคุณจะใช้ Proof of Actor หรือไม่ก็ตาม โพสต์บล็อกเรื่อง how to tell if website traffic comes from AI agents อธิบายแต่ละขั้นตอนละเอียดขึ้น
- รวบรวม agents ที่ประกาศตัวเอง ค้นหา server หรือ CDN logs ของคุณเพื่อดู user agents ที่ผู้ให้บริการ AI เผยแพร่ OpenAI ระบุ OAI-SearchBot, GPTBot และ ChatGPT-User และระบุว่า ChatGPT-User เข้าไปดูหน้าเมื่อผู้ใช้ถามคำถามกับ ChatGPT ไม่ได้ crawl อัตโนมัติ Anthropic ระบุ ClaudeBot, Claude-User และ Claude-SearchBot สิ่งนี้ทำให้คุณได้ภาพแรกเริ่มของ agent traffic แบบ declared แยกตาม route
- ตรวจสอบข้ออ้างแทนที่จะเชื่อ string ตรง ๆ user agent เป็น self-reported และคัดลอกได้ง่าย ตรวจสอบกับวิธีการยืนยันของ operator เอง Google อธิบายการทำ reverse DNS lookup ตามด้วย forward DNS lookup พร้อมทั้งไฟล์ IP range ที่เผยแพร่สำหรับ Googlebot (Google: verifying Googlebot); Bing อธิบายการตรวจ reverse และ forward DNS แบบเดียวกันสำหรับ Bingbot (Bing: verifying Bingbot); OpenAI เผยแพร่ไฟล์ IP range สำหรับ user agent แต่ละตัว เมื่อ client ลงนาม request ด้วย HTTP Message Signatures ตามที่กำหนดไว้ใน RFC 9421 ให้ตรวจลายเซ็นกับ key ที่เผยแพร่ของ operator นั้น
- ติดป้ายกำกับทุกผลลัพธ์ด้วยหลักฐาน และคง Unknown ไว้ บันทึกว่าข้อสรุปแต่ละรายการเป็น verified, declared หรือ inferred หรือไม่ Traffic ที่ไม่ตรงกับ agent ที่ verified หรือ declared และไม่แสดงรูปแบบมนุษย์ที่ชัดเจนควรถูกติดป้ายเป็น Unknown ไม่ใช่บังคับให้เป็นมนุษย์หรือ bot นี่คือขั้นตอนที่แยกรายงานที่มีประโยชน์ออกจากการเดา
- สังเกตตาม route ก่อนค่อยลงมือ แยกผลลัพธ์ตาม route และ workflow เป็นเวลาสองสามสัปดาห์: เนื้อหาสาธารณะ, signup, account settings, APIs หลังจากนั้นค่อยเขียน policy แบบจำกัดสำหรับ route ที่บริบทของ actor สำคัญที่สุด พร้อม fallback สำหรับ Unknown อย่างชัดเจน
Proof of Actor ทำให้ขั้นตอนเหล่านี้ทำงานอัตโนมัติภายใน application ของคุณ: รวบรวมสัญญาณที่ integration มองเห็น, ส่งกลับ class พร้อมฐานของผลลัพธ์, ติดตาม Unknown แยกตาม route และปล่อย policy ไว้ในโค้ดของคุณ
Proof of Actor ตรวจจับ AI agents บนเว็บไซต์อย่างไร
Proof of Actor สร้างขึ้นรอบเส้นทางที่เรียบง่าย: สัญญาณที่ integration ของคุณสังเกตได้, การจัดประเภทพร้อมฐานที่ระบุชัด, และการตัดสินใจที่ยังอยู่ในมือคุณเอง คุณสามารถอ่านลำดับการทำงานเต็มได้ที่หน้า How It Works นี่คือเวอร์ชันสั้น
สัญญาณจาก integration ของคุณ
แต่ละ integration จะเห็นเฉพาะสิ่งที่บริบทนั้นอนุญาต integration ฝั่ง server จะเห็น request context, รายละเอียดของ protocol และเมื่อ client รองรับ ก็จะเห็น request signature ด้วย integration ฝั่ง browser จะเห็นสัญญาณการโต้ตอบบนหน้าที่มันทำงานอยู่ แอปพลิเคชันยังสามารถบันทึก declaration ของตัวเองได้ เช่น ผู้ใช้ระบุว่าเนื้อหาถูก draft ด้วย AI assistance หรือ agent client ประกาศชื่อของตัวเอง
Proof of Actor ทำงานกับหลักฐานที่มีอยู่จริงเท่านั้น มันไม่ได้แสร้งว่าเห็นสิ่งที่เว็บไซต์ของคุณสังเกตไม่ได้
สี่ class ที่มีความหมายเฉพาะ
การโต้ตอบทุกครั้งจะลงอยู่ในหนึ่งในสี่ class:
- Human: สัญญาณที่สังเกตได้บ่งชี้ว่ามีการโต้ตอบที่ถูกขับเคลื่อนโดยมนุษย์
- Human + AI: มีการประกาศการช่วยเหลือจาก AI หรือมีการสังเกตผ่าน integration ที่รองรับและมองเห็นได้
- Agent: การโต้ตอบที่มาจากระบบอัตโนมัติหรือ agent โดยได้รับการสนับสนุนจากตัวตนที่ตรวจสอบได้หรือข้ออนุมานที่ระมัดระวัง
- Unknown: หลักฐานที่มีอยู่ยังไม่เพียงพอสำหรับการระบุที่เชื่อถือได้
แต่ละ class มาพร้อมคำจำกัดความและข้อจำกัดที่ชัดเจน ผลลัพธ์ Human ไม่ใช่การยืนยันตัวตน ผลลัพธ์ Agent ไม่ได้หมายความว่า agent นั้นได้รับอนุญาต ผลลัพธ์ Unknown ไม่ใช่ข้อกล่าวหา คุณสามารถอ่าน taxonomy ฉบับเต็มได้ที่หน้า Detection & Limitations
ฐานของผลลัพธ์ทุกครั้ง
นอกจาก class แล้ว ผลลัพธ์ทุกครั้งยังมีฐานกำกับไว้ด้วย: verified, declared, inferred หรือ unknown Request ที่มาพร้อมลายเซ็นที่ถูกต้องจาก key ที่เผยแพร่ถือว่า verified สำหรับการตรวจครั้งนั้น Client ที่ประกาศว่าตนเองเป็น agent ก็คือ declared รูปแบบพฤติกรรมที่สอดคล้องกับระบบอัตโนมัติก็คือ inferred ความแตกต่างนี้เองที่ทำให้ policies ของคุณแม่นยำได้ agent ที่ลงลายเซ็นแบบ verified บน route แบบอ่านอย่างเดียว กับ client ที่ประกาศตัวเองบนหน้า account settings ไม่ควรถูกจัดการเหมือนกัน และด้วย Proof of Actor ก็ไม่จำเป็นต้องเป็นเช่นนั้น คำอธิบายในอภิธานศัพท์ evidence basis อธิบายแต่ละแบบละเอียดขึ้น
ทีมของคุณได้รับอะไรบ้าง: Detect, Understand, Route
Proof of Actor คือหนึ่ง product ที่มีสามความสามารถทำงานร่วมกัน
Detect
รวบรวมสัญญาณของ actor ที่ integration ของคุณเข้าถึงได้ และแยกคำยืนยันที่ตรวจสอบได้ออกจากข้ออนุมานเชิงพฤติกรรม Traffic ที่ Unknown ยังมองเห็นได้ในฐานะหมวดของตัวเอง ไม่ได้ถูกหลอมรวมเป็นการเดา คุณจึงรู้เสมอว่าการโต้ตอบใดที่คุณพูดถึงได้อย่างมั่นใจ และรายการใดต้องการหลักฐานเพิ่ม
Understand
ดู AI agent traffic ในบริบทของมัน สำรวจประเภทการโต้ตอบตาม route และตามเวลา ติดตามแนวโน้มของกิจกรรม human, AI-assisted, agent และ unknown แล้วเปิดดูการจัดประเภทแต่ละรายการเพื่อดูว่าอะไรที่รู้ อะไรที่ยังไม่รู้ และผลลัพธ์นั้นอิงอะไร นี่คือจุดที่ทีม product, platform และ security ได้ภาพร่วมที่อธิบายได้ว่าใครกำลังใช้เว็บไซต์
Route
ใช้นโยบายของคุณเองเพื่อ allow, adapt, challenge, review หรือจำกัดการโต้ตอบเฉพาะบางประเภท ส่ง response แบบมีโครงสร้างให้กับ verified agent ที่อ่านเอกสารของคุณ คงประสบการณ์มาตรฐานไว้สำหรับ session ที่ขับเคลื่อนโดยมนุษย์ ขอการตรวจเพิ่มที่เข้มขึ้นสำหรับการเปลี่ยนแปลงบัญชีที่อ่อนไหวเมื่อเงื่อนไขของคุณกำหนดไว้ เลือก fallback ที่ชัดเจนสำหรับ Unknown และสำหรับ timeouts แยกตาม route การ enforce จะเกิดขึ้นเสมอใน application ของคุณ ภายใต้นโยบายที่ทีมของคุณยืนยันแล้ว
ออกแบบมาให้เข้ากับเว็บไซต์ของคุณ ไม่ใช่มาแทนที่มัน
Proof of Actor อยู่คู่กับเครื่องมือที่คุณใช้อยู่แล้ว มันไม่ได้มาแทนที่ authentication, authorization model หรือการควบคุม abuse ที่มีอยู่ มันเพิ่มบริบทของ actor เข้าไปในสิ่งเหล่านั้น
การเชื่อมต่อเว็บไซต์ทั่วไปมักเริ่มที่ route ที่บริบทของ actor สำคัญที่สุด: เนื้อหาสาธารณะที่ agent อ่านจำนวนมาก, signup และ onboarding flows, account settings และการกระทำอ่อนไหวอื่น ๆ และ any API ที่ขับเคลื่อนเว็บไซต์ ทีมผู้ก่อตั้งจะทำงานร่วมกับวิศวกรของเราเพื่อเลือก route เหล่านั้น, ตกลงสัญญาณที่อยู่ในขอบเขต และยืนยันวิธีจัดการข้อมูลก่อนโค้ดใด ๆ จะถูกนำขึ้นใช้งาน
เพราะชั้นการตัดสินใจอยู่ในโค้ดของคุณเอง คุณจึงยังคงควบคุมประสบการณ์ได้ คุณสามารถแสดงผลใน internal dashboard เป็นเวลาหลายสัปดาห์ก่อนเปลี่ยน rule ใด ๆ แล้วค่อยเปิดใช้นโยบายแบบจำกัดเพียงหนึ่งข้อสำหรับหนึ่ง route จากนั้นค่อยขยายเมื่อผลลัพธ์ได้รับความไว้วางใจแล้ว คู่มือเรื่อง handling unknown traffic อธิบายวิธีออกแบบ rule แรกเหล่านั้น
เริ่มในโหมด observation
วิธีที่เร็วที่สุดในการได้คุณค่าจากการตรวจจับ AI agent คือเริ่มจากการดู ไม่ใช่การบล็อก ในโหมด observation Proof of Actor จะบันทึกผลลัพธ์ในขณะที่เว็บไซต์ของคุณตอบสนองเหมือนเดิมทุกประการราวกับไม่มีมัน ทีมของคุณจึงสามารถเปรียบเทียบการจัดประเภทกับผลลัพธ์ที่คุณเข้าใจอยู่แล้วได้ เช่น support tickets, integrations ที่รู้จัก, internal tools และ crawler ที่คุณจำได้อยู่แล้ว
สิ่งนี้ให้ 3 อย่างก่อนมีการ enforce ใด ๆ:
- baseline ปริมาณ traffic ของคุณมีสัดส่วนแบบ human-directed, AI-assisted, agent-driven หรือ unknown เท่าไร แยกตาม route
- ความมั่นใจในหลักฐาน สัญญาณใดแข็งแรงบนเว็บไซต์ของคุณ และจุดใดที่ coverage ต้องเพิ่ม
- policies ที่ดีกว่า rules ที่ออกแบบจากรูปแบบจริงแทนสมมติฐาน พร้อมให้ review false positive ก่อนที่ใครจะได้รับผลกระทบ
เมื่อ policy พร้อมใช้งาน คุณเปิดใช้ให้กับ workflow เฉพาะที่ออกแบบไว้ และยังคงปรับได้ทุกเมื่อ
ทำไมการตรวจจับที่อิงหลักฐานจึงดีกว่าคะแนนที่คลุมเครือ
เว็บไซต์ต่าง ๆ กำลังให้บริการ agents, assistants และคนที่ทำงานร่วมกับ AI ควบคู่กันอยู่แล้ว ทีมที่รับมือกับสิ่งนี้ได้ดีไม่ใช่ทีมที่มี filters เข้มที่สุด แต่คือทีมที่อธิบายการตัดสินใจของตนได้
ผลลัพธ์ที่อิงหลักฐานให้คำอธิบายนั้นแก่คุณ เมื่อ support agent ถามว่าทำไมผู้ใช้จึงเห็นขั้นตอนตรวจสอบเพิ่ม คุณชี้ไปที่หลักฐานและ policy ที่ใช้กับกรณีนั้นได้ เมื่อ agent operator ถามว่าทำไม request ที่ลงลายเซ็นแล้วจึงได้รับ response แบบมีโครงสร้าง คุณแสดงฐานที่ verified ได้ เมื่อหลักฐานบางเบา ผลลัพธ์จะบอกว่า Unknown และ fallback ของคุณจะจัดการมันในแบบที่คุณเลือกอย่างตั้งใจ
วิธีนี้ยังขยายตัวไปพร้อมกับเว็บได้ด้วย เมื่อ agent operators ลงลายเซ็น request ของตนมากขึ้น และงานมาตรฐานอย่าง IETF Web Bot Auth working group ซึ่งมี charter เพื่อทำให้การยืนยันตัวตนเชิง cryptographic สำหรับ client อัตโนมัติเป็นมาตรฐาน พัฒนาต่อยอดจาก HTTP message signatures traffic ของคุณส่วนหนึ่งจะเลื่อนจาก inferred หรือ unknown ไปเป็น verified และ policies ของคุณจะแม่นยำขึ้นโดยไม่ต้องเขียนใหม่
เข้าร่วม founding developer program
Proof of Actor อยู่ใน private beta กับกลุ่มทีมแอปพลิเคชันขนาดเล็ก Selected founding developers สามารถได้รับสิทธิ์ใช้งานฟรีได้นานสูงสุด 12 เดือน ภายใต้ขอบเขตการใช้งานที่ตกลงกัน เพื่อแลกกับ feedback ด้านผลิตภัณฑ์แบบลงมือจริง คุณจะได้รับการสนับสนุนการเชื่อมต่อโดยตรงจากวิศวกรของเรา, สิทธิ์เข้าถึงความสามารถใหม่ก่อนเมื่อพร้อมใช้งาน และมีอิทธิพลจริงต่อสิ่งที่เราจะสร้างต่อไป
หากเว็บไซต์ของคุณให้บริการคน, ผู้ใช้ที่ได้รับการช่วยเหลือจาก AI และ agents และคุณอยากรู้ว่าใครกำลังใช้มันก่อนจะตัดสินใจว่าจะให้เกิดอะไรขึ้นต่อไป สมัครเพื่อขอ early access บอกเราเกี่ยวกับเว็บไซต์ของคุณและการโต้ตอบที่คุณอยากทำความเข้าใจมากที่สุด แล้วเราจะตรวจว่าตรงกับ beta รอบปัจจุบันหรือไม่
อยากดูรายละเอียดก่อนใช่ไหม สำรวจ Proof of Actor, อ่าน how it works, หรือทบทวนอย่างชัดเจนว่า สิ่งที่หลักฐานสามารถและไม่สามารถพิสูจน์ได้ คืออะไร
แหล่งอ้างอิง
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- Web Bot Auth (webbotauth) working group charter, IETF.
- Overview of OpenAI crawlers, OpenAI.
- Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.
- Verifying Googlebot and other Google crawlers, Google Search Central.
- How to verify that Bingbot is Bingbot, Bing Webmaster Blog.