ขอบเขตคือ API ไม่ใช่หน้าจอ#
การตรวจสอบสิทธิ์ทุกครั้งทำงานฝั่งเซิร์ฟเวอร์ ในทุกคำขอ เมนูที่คุณเห็นเป็นเพียงสัญญาณเพื่อความสะดวกในการใช้งาน — การซ่อนตัวควบคุมไม่ได้ปกป้องมัน และการรู้ URL ไม่ได้ให้สิทธิ์เข้าถึง header ชนิด selector อย่าง X-AIGrid-Project เป็นการขอบริบท มันไม่เคยพกอำนาจมาด้วย
เรื่องนี้สำคัญในทางปฏิบัติ: คุณขยายสิทธิ์ของใครด้วยการส่งลิงก์ให้เขาไม่ได้ และคุณจำกัดสิทธิ์ด้วยการซ่อนเมนูก็ไม่ได้ หากต้องการเปลี่ยนสิ่งที่คนหนึ่งทำได้ ให้เปลี่ยนสิทธิ์ (grant)ของเขา
คีย์ API#
คีย์เป็นข้อมูลรับรองแบบสุ่มขนาด 256 บิต (aig_ + token) AI Grid เก็บเพียง SHA-256 hash กับ prefix สั้น ๆ ไว้แสดงผล — การอ่านที่เก็บข้อมูลจึงไม่ได้อะไรที่ใช้งานได้ และคีย์ดิบไม่เคยถูกบันทึกลง log secret ฉบับเต็มแสดงครั้งเดียวตอนสร้าง; การเล่นซ้ำคำขอสร้างแบบ idempotent จะไม่เปิดเผยมันอีก
- การเพิกถอน ปฏิเสธ admission ครั้งถัดไปของคีย์ การเรียกที่ถูกรับเข้าไปแล้วจะตัดบัญชีตามที่บันทึกไว้ ระเบียนการเงินและการตรวจสอบจึงไม่เคยค้างคา
- การหมุนเวียน สร้าง secret ทดแทนและเพิกถอนคีย์เก่าทันที — ไม่มีช่วงเวลาคาบเกี่ยว จึงควรนำ secret ใหม่ไปติดตั้งก่อนหมุนเวียน
ข้อมูลรับรองของผู้ให้บริการ#
คีย์ของผู้ให้บริการต้นทางถูกเพิ่มโดยผู้ดูแลแพลตฟอร์มเท่านั้น — องค์กรใส่ข้อมูลรับรองของผู้ให้บริการของตัวเองไม่ได้ คีย์ของผู้ให้บริการที่จัดเก็บไว้ถูกเข้ารหัสด้วย AES-GCM ภายใต้คีย์ที่แยกโดเมนซึ่งได้มาจาก session secret โดยใช้ connection ID เป็น authenticated associated data การตอบกลับของ API ผลลัพธ์ idempotency และบันทึกการตรวจสอบไม่เคยมีทั้ง plaintext และ ciphertext
ในด้านเครือข่าย provider adapter ปิดการใช้ proxy และ redirect แปลง DNS แยกรายการเชื่อมต่อ ปฏิเสธปลายทางที่เป็น private หรือ reserved และตรึงการเชื่อมต่อไว้กับที่อยู่ที่ตรวจแล้ว ขณะยังคงการตรวจสอบ hostname ของ TLS ไว้
สิ่งที่เกิดขึ้นกับข้อมูลที่คุณส่ง#
- prompt ไม่ได้ถูกบันทึกแยกต่างหาก แถวการใช้งาน รายละเอียดการใช้งาน และ audit event พก metadata — เวลา โปรเจกต์ prefix ของคีย์ ผลิตภัณฑ์ token สถานะ เวลาตอบสนอง จำนวนเงิน — ไม่เคยมีเนื้อหาของ prompt หรือคำตอบ
- คำตอบถูกเก็บรักษาไว้ ในฐานข้อมูล Core ที่เป็นส่วนตัว เพียงเพื่อให้การเล่นซ้ำแบบ idempotent ส่งคำตอบเดิมกลับได้ มันไม่ถูกเปิดเผยบนช่องทางอ่านใด ๆ
guardrail ล้มเหลวแบบปิด#
นโยบายการเรียกใช้ที่ Owner จัดการประกอบ guardrail pack ด้านเนื้อหาได้ (PII, secret, prompt injection) โดยเลือกการกระทำหนึ่งในสามแบบ — observe, mask หรือ block — และการกระทำที่เข้มที่สุดที่ใช้บังคับได้เป็นผู้ชนะ การตรวจสอบทำงานภายใน admission transaction ก่อนมีการกันเงินใด ๆ และหากการตรวจสอบล้มเหลว การเรียกจะถูกยกเลิก แทนที่จะปล่อยผ่านโดยไม่ตรวจ
การเรียกที่ถูกบล็อกถูกปฏิเสธด้วย 403 content_policy; ข้อความข้อผิดพลาดบอกว่าคำขอถูกบล็อก ไม่ได้บอกว่าตรวจพบอะไร audit event ของ guardrail เก็บจำนวนครั้งที่กฎทำงาน ไม่เคยเก็บข้อความที่ตรวจพบ
การตรวจสอบ#
การกระทำที่มีผลตามมาจะบันทึก audit event พร้อมผู้กระทำ การกระทำ เหตุผล และเวลา ครอบคลุมการเปลี่ยนแปลงสมาชิกและ grant การยื่นและตรวจสอบผลิตภัณฑ์ การเผยแพร่และการระงับ การกำหนดผลิตภัณฑ์ วงจรชีวิตทั้งหมดของคีย์ การเปลี่ยนแปลงการเชื่อมต่อผู้ให้บริการ และทุก reservation, settlement และ reconciliation Owner และ Administrator ขององค์กรอ่านการตรวจสอบทางการเงินขององค์กรตนได้; ผู้ดูแลแพลตฟอร์มถือร่องรอยข้ามองค์กร
สถาปัตยกรรมของแพลตฟอร์ม#
การลงชื่อเข้าใช้ทำงานผ่าน Keycloak (OIDC single sign-on) การตัดสินใจเรื่องสิทธิ์ถูกประเมินผ่าน OpenFGA (grant เชิงความสัมพันธ์) และ OPA (นโยบายตามบริบท) — ทั้งคู่อยู่หลัง adapter ความจริงเชิงธุรกิจจึงยังอยู่ใน AI Grid Core และเอนจินเป็นผู้ดำเนินการตัดสินใจ ไม่ใช่เจ้าของการตัดสินใจ คอนโซลผู้ดูแลมีหน้าหลักฐานแบบอ่านอย่างเดียวสำหรับแต่ละบริการ
ถัดไป#
- คีย์ API — การออกคีย์ การหมุนเวียน และข้อจำกัด
- การแบ่งผู้เช่าและการแยกส่วน — ตัวขอบเขตเอง
- นโยบายและ guardrail — การตั้งค่านโยบายการเรียกใช้