Policy Rules
สร้างและจัดการ policy rule ที่ใช้ CEL เพื่อควบคุมพฤติกรรมของเครื่องมือ AI
Policies คือกฎที่ Edison Watch ประเมินต่อการเรียกใช้เครื่องมือ AI ทุกครั้งแบบเรียลไทม์ สามารถบล็อกการกระทำ ติดแท็กเซสชัน ตั้งค่าระดับ access-control และอื่นๆ - ทั้งหมดโดยไม่ต้องเปลี่ยนการกำหนดค่าเครื่องมือ AI
มุมมอง Policies
ไปที่ Policies ในแถบด้านข้าง หน้าถูกแบ่งเป็นสองแผง:
- แถบด้านข้างซ้าย - รายการกฎทั้งหมด จัดกลุ่มตามสถานะ พร้อมช่องค้นหา
- แผงขวา - รายละเอียดของกฎที่เลือก
แถบสรุปที่ด้านบนของแถบด้านข้างแสดงจำนวนกฎ enabled, tentative และ disabled ได้ในพริบตา
สถานะของกฎ
| สถานะ | ความหมาย |
|---|---|
| enabled | กฎทำงานและถูกบังคับใช้กับการเรียกใช้เครื่องมือที่ตรงกันทั้งหมด |
| tentative | กฎถูกประเมินแต่เพียงบันทึก - ไม่ได้ใช้การกระทำ มีประโยชน์สำหรับการทดสอบกฎใหม่อย่างปลอดภัย |
| disabled | กฎถูกเก็บไว้แต่ไม่ถูกประเมิน |
Phase ของกฎ
แต่ละกฎทำงานในหนึ่งในสอง phase:
| Phase | เมื่อไหร่ที่ทำงาน | พฤติกรรมการบล็อก |
|---|---|---|
| pre | ก่อนการเรียกใช้เครื่องมือทำงาน | ป้องกันการทำงาน |
| post | หลังจากการเรียกใช้เครื่องมือเสร็จ; result ของเครื่องมือพร้อมใช้งานใน expression | การเรียกทำงานไปแล้ว - result จะถูกแทนที่ด้วย error ก่อนส่งกลับไปยัง AI เพื่อป้องกันการลักลอบนำข้อมูลที่ละเอียดอ่อนออก |
บริบท CEL Expression
กฎถูกเขียนด้วย CEL (Common Expression Language) Expression ประเมินต่อ top-level object สี่รายการที่แสดงการเรียกใช้เครื่องมือปัจจุบัน:
| ตัวแปร | ฟิลด์ | หมายเหตุ |
|---|---|---|
principal | user_id, email, roles | ผู้ใช้ที่ทำการเรียก roles เป็นรายการชื่อบทบาทแบบกำหนดเอง |
resource | type, name, server | สิ่งที่กำลังเรียก type เป็น "tool", "resource" หรือ "prompt" |
tool | args, input_schema, output_schema, result | result จะถูกกรอกเฉพาะใน phase post |
session | has_private_data_access, has_untrusted_content_exposure, has_external_communication, highest_acl_level, tool_history, tags | สถานะเซสชันปัจจุบัน รวมถึงแฟล็ก Lethal Trifecta ทั้งสาม |
หาก expression ประเมินเป็น true การกระทำของกฎจะถูกใช้
resource.server == "github" && resource.name == "delete_branch" &&
tool.args.branch == "main"ฟังก์ชันในตัว
| ฟังก์ชัน | คืนค่า | คำอธิบาย |
|---|---|---|
pii_detect(value, [categories]) | bool | true หากพบ PII ในหมวดใดหมวดหนึ่งที่ระบุไว้ที่ใดก็ได้ใน value (ค้นหาแบบ recursive รวม nested fields) หมวดหมู่: "EMAIL", "API_KEYS", "PHONE", "CREDIT_CARD" |
จับคู่ pii_detect บน tool.args กับ action block เพื่อหยุดไม่ให้ agent ส่ง ข้อมูลละเอียดอ่อนออกผ่าน tool จำกัดขอบเขตกฎไปยัง server ที่มีการสื่อสารภายนอก เพื่อไม่ให้ detection วิ่งบน hot path ที่อื่น
pii_detect(tool.args, ["CREDIT_CARD", "API_KEYS"])pii_detect fail open: หาก detector error expression จะประเมินเป็น false (กฎไม่ fire) ดังนั้น detector ที่พลาดจะไม่บล็อก traffic ที่ถูกต้อง เป็น defense-in-depth ซ้อนบน Lethal Trifecta guard ที่เปิดตลอด ควรใช้หมวดหมู่ความแม่นยำสูง (CREDIT_CARD, API_KEYS) สำหรับการบล็อก - EMAIL และ PHONE ปรากฏในการเรียกที่ถูกต้องหลายกรณี (ที่อยู่ผู้รับเป็น email) ดังนั้นการบล็อกด้วยหมวดเหล่านี้มักกว้างเกินไป
Detection ทำงานบน arguments ก่อน ที่ Edison PII tokens จะถูก restore ดังนั้นจึงจับ raw PII ที่ agent แต่งขึ้นโดยตรง ค่าที่กลับเข้ามาเป็น Edison token (จากผลลัพธ์ tool ที่ถูก redact ก่อนหน้า) จะทึบในขั้นตอนนี้ - เส้นทาง exfiltration เหล่านั้นถูกครอบคลุมโดย Lethal Trifecta guard แทน pii_detect มีความหมายที่สุดใน phase pre บน tool.args
Actions
| Action | ผล |
|---|---|
block | ป้องกันการเรียกใช้เครื่องมือไม่ให้ทำงานและส่ง error กลับไปยัง AI |
mark_private | ตั้งแฟล็กเซสชันว่ามีข้อมูลส่วนตัว |
mark_untrusted | ตั้งแฟล็กเซสชันว่ามีเนื้อหาภายนอกที่ไม่น่าเชื่อถือ |
mark_write | ตั้งแฟล็กเซสชันว่าได้ทำการเขียน |
set_acl | ตั้งค่าระดับ ACL ของเซสชัน (PUBLIC, PRIVATE หรือ SECRET) |
add_tag | เพิ่มแท็ก key-value ลงในเซสชันสำหรับการกรองและการตรวจสอบ |
allow_override | อนุญาตการเรียกอย่างชัดเจนแม้ว่ากฎอื่นๆ จะบล็อก |
ขอบเขตของกฎ
กฎสามารถถูกจำกัดขอบเขตไปยัง principal และ resource เฉพาะ:
- Principal scope - กำหนดเป้าหมายผู้ใช้ทั้งหมดในระดับ global บทบาทเฉพาะ หรือผู้ใช้เฉพาะ
- Resource scope - กำหนดเป้าหมายเซิร์ฟเวอร์เฉพาะ ประเภท element (tools/resources/prompts) หรือรูปแบบชื่อ
กฎที่ไม่มีขอบเขตจะใช้กับ principal และ resource ทั้งหมด
ลำดับความสำคัญและการ Override
เมื่อมีกฎหลายข้อที่ตรงกับการเรียกใช้เครื่องมือเดียวกัน การกระทำของกฎที่ตรงกันทุกข้อจะถูกใช้ ลำดับความสำคัญควบคุมว่า block และ allow_override โต้ตอบกันอย่างไร:
blockจะถูกยกเลิกก็ต่อเมื่อกฎallow_overrideที่ตรงกันมีลำดับความสำคัญเท่ากันหรือสูงกว่า- มิฉะนั้น block จะชนะ
| กฎที่ตรงกัน | ลำดับความสำคัญ | ผลลัพธ์ |
|---|---|---|
block + allow_override | 100 vs. 100 | ✅ อนุญาต (override ≥ block) |
block + allow_override | 100 vs. 99 | ❌ ถูกบล็อก (override < block) |
block เดี่ยว | ใดก็ได้ | ❌ ถูกบล็อก |
Action ที่ไม่ใช่ block (mark_*, set_acl, add_tag) ถูกใช้เมื่อใดก็ตามที่กฎตรงกันและไม่ได้รับผลกระทบจากการ resolve นี้
การสร้าง Policy
- คลิก Create Policy ในแถบด้านข้างซ้าย
- เลือกเทมเพลตจาก template picker หรือเริ่มจากศูนย์
- กรอกชื่อกฎ CEL expression phase ลำดับความสำคัญ action และขอบเขต
- บันทึกกฎ
การทดสอบกฎก่อนเปิดใช้งาน
ตัวแก้ไขกฎมีแผง evaluate ที่เรียกใช้ CEL expression ของคุณต่อบริบทสังเคราะห์ - principal, resource, tool args และแฟล็กเซสชัน - โดยไม่ต้องบันทึกกฎ ใช้เพื่อยืนยันว่า expression ตรงกับกรณีที่คุณคาดหวังและเพื่อดูว่า action ใดจะทำงาน
สำหรับการเปิดตัวแบบค่อยเป็นค่อยไปกับทราฟฟิกจริง ให้บันทึกกฎด้วยสถานะ tentative การตรงกันจะถูกบันทึกที่ฝั่ง server เป็น ⚠️ TENTATIVE match - would apply actions: ...; ยังไม่มีมุมมอง dashboard เฉพาะสำหรับ tentative hit ในปัจจุบัน ดังนั้นให้ตรวจสอบ server log หรือ SIEM ของคุณ เลื่อนกฎเป็น enabled เมื่อคุณมั่นใจ
การแก้ไขและการลบ
เลือกกฎในแถบด้านข้าง จากนั้นคลิก Edit หรือ Delete ในแผงรายละเอียด