| บันทึกการกำกับดูแลที่ลงนาม |
ผู้กระทำ การมอบอำนาจ เครื่อง ที่นั่ง และสิทธิ์ทั้งหมดอยู่ในบันทึกแบบต่อท้ายอย่างเดียว (append-only) ที่ลงนามด้วย Ed25519 ทะเบียนที่มนุษย์อ่านได้ทุกฉบับเป็นเพียงภาพฉายของบันทึกนี้ — สร้างใหม่ได้ ไม่ใช่ต้นทาง |
ประวัติการกำกับดูแลทั้งหมด ตรวจสอบได้โดยบุคคลที่สามที่ถือเพียงกุญแจสาธารณะราก — โดยไม่ต้องเชื่อถือเครื่องที่สร้างบันทึกนั้น |
| ประตูตัดสินโดยมนุษย์ ไม่มีข้อยกเว้น |
ไม่มี auto-accept ไม่มี auto-merge ไม่มีการถือว่าหมดเวลาคือการยินยอม ที่ใดในผลิตภัณฑ์ การตัดสินที่ประตูไม่มีค่าเริ่มต้น และถูกปฏิเสธหากผิดลำดับ เครื่องยนต์ทำหน้าที่ส่งต่อเท่านั้น ไม่เคยตัดสินเอง |
หนึ่งแถวต่อหนึ่งการตัดสิน: ผู้ตัดสิน คำตัดสินจากชุดคำที่ปิด และเวลา “Merged” ไม่เคยถูกประกาศ — สังเกตได้จาก merge commit จริงเท่านั้น |
| การตัดสินที่ตรวจพบการแก้ไข |
การยอมรับแต่ละครั้งเป็นชุดข้อมูลที่ผูกกุญแจและตรวจสอบแล้ว และถูกตรวจซ้ำตอน merge แก้ช่องใดภายหลัง การตรวจสอบจะล้ม |
ชุดข้อมูลนั้น และผลการตรวจสอบตอน merge |
| ข้อเสนอ ≠ การตัดสิน |
คำปรึกษา — จาก AI หรือมนุษย์ — ถูกบันทึกเป็นความเห็น การตัดสินเป็นการกระทำของมนุษย์เอง และการตัดสินสวนทางกับข้อเสนอก็ถูกบันทึกไว้เช่นกัน |
แถวข้อเสนอและแถวการตัดสินแยกกันในทุกประตู — ไม่เพียงว่าตัดสินอะไร แต่ใครเสนออะไร |
| ตัวตนของเครื่องด้วยใบรับรอง |
ไม่มี endpoint สำหรับลงทะเบียน ไม่มี join token เครื่องถูกรับเข้าโดยการกระทำที่ชัดแจ้งของเจ้าของ ผูกกับใบรับรอง control plane เชื่อมต่อออกไปข้างนอกเท่านั้น และเครื่องรันไม่ถือ credential ใดของ control plane |
การรับเข้าในบันทึกที่ลงนาม และห่วงโซ่ใบรับรอง |
| อำนาจที่มอบหมายและมีขอบเขต |
การมอบอำนาจที่ลงนามโดยราก มีขอบเขต สายงาน และช่วงเวลาที่ใช้ได้ วันหมดอายุคือเพดาน ไม่ใช่ตัวจุดชนวน การปลดผู้กระทำมีผลทันที ไม่ว่าการมอบอำนาจใดจะยังไม่หมดอายุ |
การมอบอำนาจ พร้อมลายเซ็นครอบทุกช่อง — ใครให้อะไรแก่ใคร ถึงเมื่อไร |
| กฎประจำที่ให้สัตยาบัน |
เอกสารที่กำกับวิธีทำงานถูกลงนามโดยรากเข้าไปใน manifest ที่มีหมายเลขลำดับ เอกสารใดก็ตรวจสอบย้อนกลับถึงรากได้ เอเจนต์ทำงานภายใต้กฎที่พิสูจน์ได้ว่าได้รับแล้ว |
manifest และบันทึกของแต่ละการรันว่ากฎใดถูกฉีดเข้าไป — พร้อมแฮชของมัน |
| การกักบริเวณระดับ OS — ในเครื่อง |
นโยบายเขียนแบบปฏิเสธเป็นค่าเริ่มต้นจาก sandbox ของระบบปฏิบัติการเอง — Seatbelt บน macOS, Bubblewrap บน Linux — ประกอบขึ้นสำหรับแต่ละการรันก่อนที่เอเจนต์จะเริ่ม หากไม่มี sandbox การรันจะถูกปฏิเสธ ไม่ใช่ลดระดับความปลอดภัย |
บันทึกการรันระบุเครื่องมือที่กักบริเวณ และไดเรกทอรีที่ยังเขียนได้ — ข้อกล่าวอ้างที่ทีมของคุณทำซ้ำได้ |
| การกักบริเวณระดับ OS — เครื่องระยะไกล |
การกักบริเวณที่บังคับโดยเคอร์เนล (Landlock) สำหรับการรันที่ส่งผ่าน SSH ความสามารถในการกักบริเวณของเครื่องถูกวัดก่อนที่งานจะถูกส่งไปที่นั่น เครื่องที่ยังไม่ถูกวัด หรือวัดแล้วว่าทำไม่ได้ จะปฏิเสธการรัน |
ความสามารถที่วัดได้บนแถวที่ลงนามของเครื่อง และบันทึกการรันที่ระบุว่าอะไรเป็นตัวบังคับ |
| การเชื่อมต่อออกคือรายการ |
การรันที่ประกาศนโยบาย egress จะเข้าถึงเครือข่ายได้ผ่านประตูที่นโยบายนั้นกำกับเท่านั้น: ปลายทางถูกอนุญาตก็ต่อเมื่อนโยบายอนุญาตทั้งโฮสต์และพอร์ต และค่าเริ่มต้นไม่อนุญาตอะไรเลย โฮสต์ที่ตัดเครือข่ายไม่ได้จะปฏิเสธการรัน แทนที่จะเริ่มแบบเปิด ในรุ่นนี้เป็นแบบเลือกเปิดต่อการส่งงาน — ยังไม่มีค่าเริ่มต้นทั้งฟลีต และเราบอกไว้ตรง ๆ |
digest ของนโยบายที่คอมไพล์แล้วบนแถวของการรัน — รายการใดกำกับการรันนี้ การตัดสินต่อการเชื่อมต่อยังไม่ถูกบันทึก นั่นคือข้อจำกัดของรุ่นนี้ที่ระบุไว้ ไม่ใช่ของการออกแบบ |
| ไม่มีช่องทางลัดระหว่างเอเจนต์ |
เอเจนต์ประสานงานกันผ่านพื้นผิวที่ถูกบันทึกเท่านั้น — คำสั่งงาน ไฟล์ช่องทางใน worktree ของสายงานเองที่ถูกนำเข้าบันทึก ประตูตัดสิน และกล่องจดหมายแบบเพิ่มอย่างเดียวสำหรับคำสั่งของเจ้าของ ไม่มีการส่งข้อความระหว่างเอเจนต์ในผลิตภัณฑ์ |
“ใครบอกอะไรกับใคร เมื่อไร” คือคำค้น ไม่ใช่การสอบถาม — ประวัติการประสานงานของสายงาน เล่นซ้ำได้จากบันทึก |
| การปฏิเสธคือข้อมูล |
ทุกการปฏิเสธ — จากเครื่องยนต์ การอนุญาต สคีมา หรือนโยบาย — เป็นแถวที่บันทึกไว้โดยไม่มีต้นทุน พร้อมประเภทที่มีชื่อ สาเหตุการปฏิเสธถูกบันทึก ไม่เคยส่งกลับผ่านสาย |
สมุดบัญชีการปฏิเสธ: มาตรการควบคุมที่ทำงานจริง ไม่ใช่แค่มีอยู่ |
| การเฝ้าระวัง — เป้าหมาย Prometheus |
เดมอนที่ให้บริการเปิด GET /metrics ในรูปแบบข้อความมาตรฐานของ Prometheus: การรันแยกตามสถานะและแบ็กเอนด์ การปฏิเสธแยกตามประเภท การตัดสินที่ประตูแยกตามประตูและคำตัดสิน เวอร์ชันสคีมาของที่เก็บ ค่าของ label เป็นชื่อประเภทเท่านั้น — ไม่มีชื่อสายงาน พาธ หรือชื่อผู้กระทำ |
การปฏิเสธเป็นเมตริกชั้นหนึ่ง — ในสถาปัตยกรรมนี้ การปฏิเสธคือสัญญาณด้านความปลอดภัย ไม่ใช่เสียงรบกวน ดึงข้อมูลด้วย Prometheus ที่คุณใช้อยู่แล้ว ไม่ต้องติดตั้งอะไรเพิ่ม |
| ความลับไม่แพร่กระจาย |
ไม่มีระบบย่อยใดเก็บหรือส่งค่าความลับ — ใช้ชื่อตัวแปรและพาธเท่านั้น บังคับในระบบชนิดข้อมูล ไฟล์กุญแจถูกตรวจสิทธิ์การครอบครองก่อนอ่านเนื้อหาเสมอ |
การตั้งค่าโดยชื่อ ไม่มีค่าใดในบันทึก ล็อก หรือไฟล์ส่งออก |
| OAuth 2.1 บนพื้นผิวการจัดการ |
ป้องกันด้วย bearer โดย Team ยืนยันตัวตนผ่าน SaaS saphan-oauth ที่ Saphan ดำเนินการ ส่วน Enterprise รัน saphan-oauth ภายในหรือรับ IdP ใดๆ ของลูกค้าผ่านรายการ issuer ที่มนุษย์อนุมัติ มี scope class การแบ่งระดับแถวต่อผู้เช่า และ fail-closed เป็นค่าเริ่มต้น |
ล็อกการเข้าถึงระดับตรวจสอบบัญชีบนทุกช่องทาง — รหัสสถานะตรงไปตรงมา ไม่มีค่าหรือ query string ถูกบันทึก |
| การกำกับต้นทุน |
ใบเสนอราคาและเพดานแข็งต่อการรัน กำหนดก่อนส่งงาน ตรวจความจุก่อนเริ่ม ชั้นการเรียกเก็บเงินต่อที่นั่ง ต้นทุนจริงและส่วนต่างอยู่ข้างหลักฐาน ไม่ใช่บนใบแจ้งหนี้อีกใบ |
สมุดบัญชีต้นทุน ต่อสายงานและต่อประตู — “การเปลี่ยนแปลงนี้ราคาเท่าไร” ได้คำตอบบรรทัดเดียวเหมือน “ใครอนุมัติ” |
| การตรึงห่วงโซ่อุปทาน |
ไบนารีของเอเจนต์ถูกส่งพร้อม digest ที่คำนวณบนเครื่องผู้รับ และตัวตนถูกตรวจซ้ำ ณ ที่ที่มันทำงาน |
ต่อการรัน: digest ของไบนารี เวอร์ชัน แฮชของการตั้งค่า กฎประจำที่ถูกฉีดเข้าไปและแฮชของมัน |
| ที่เก็บบันทึกของคุณ |
ที่เก็บบันทึก PostgreSQL บนโครงสร้างพื้นฐานที่คุณควบคุม ตั้งค่าโดยชื่อ credential ผ่านชื่อตัวแปรเท่านั้น โค้ด หลักฐาน run และบันทึกการปฏิบัติงานไม่ผ่านโครงสร้างพื้นฐานของ Saphan Team ส่งตัวตนไปยัง OAuth ของ Saphan ส่วน Enterprise เก็บตัวตนไว้ภายใน ทั้งสองแบบใช้สัญญาณมือถือที่มีเพียง gate id แบบทึบและจำนวน badge ได้ |
ฐานข้อมูลของคุณ บวกไฟล์ธรรมดาใน git ของคุณ อ่านได้โดยไม่ต้องใช้เครื่องมือของเรา |
| พิสูจน์ด้วยการทดสอบ ไม่ใช่คำกล่าวอ้าง |
สถานการณ์แบบครบวงจรรันกับไบนารีจริง: วินัยที่ประตู การล็อกการส่งงาน การต้านทาน injection คำสั่งที่ส่งผิดทาง กระบวนการ OAuth การป้องกันด้วย bearer ความสอดคล้องของภาพฉาย |
ผลการทดสอบความสอดคล้อง ทำซ้ำได้บนการติดตั้งของคุณ |