Multi-Tenancy ของ AI Agent: การแยก Credential การแยก Namespace และ SOC 2
Multi-Tenancy ของ AI Agent คือคุณสมบัติทางสถาปัตยกรรมของแพลตฟอร์ม Agent ที่แยก Credential หน่วยความจำ บริบทการทำงาน และบันทึกการตรวจสอบของผู้เช่าแต่ละรายออกจากผู้เช่ารายอื่นทั้งหมด ซึ่งบังคับใช้ที่ชั้น Infrastructure ไม่ใช่โดยข้อตกลงของนักพัฒนาหรือการปฏิบัติตามคำสั่งของ Agent ต่างจาก Multi-Tenancy ของแอปพลิเคชันเว็บ Agent ถือ API Key ที่ใช้งานอยู่ สะสมหน่วยความจำถาวรระหว่างคำขอ และดำเนินการเรียกใช้เครื่องมือที่ผ่านการตรวจสอบสิทธิ์: สามมิติที่เกินกว่าการแยก Data Row ที่ต้องแบ่งพาร์ทิชันตามผู้เช่าเพื่อตอบสนอง OWASP LLM06 และ SOC 2 CC6.1
Multi-Tenancy ของ AI Agent คือคุณสมบัติทางสถาปัตยกรรมของแพลตฟอร์ม Agent ที่ทำให้แน่ใจว่า Agent ที่ให้บริการผู้เช่าต่างกันไม่สามารถเข้าถึง Credential หน่วยความจำ บริบทการทำงาน หรือบันทึกการตรวจสอบของกันและกันได้ บังคับใช้ที่ชั้น Infrastructure ผ่าน Scope ของ Credential Vault ต่อผู้เช่า ACL ของ Namespace บนกระดาน การแยกการทำงานใน Container และ Audit Log แบบแบ่งพาร์ทิชัน ทำให้ผลิตภัณฑ์ B2B SaaS ที่สร้างบนแพลตฟอร์มสืบทอดการแยกผู้เช่าเป็นการรับประกันเชิงโครงสร้างแทนที่จะเป็นความรับผิดชอบของนักพัฒนา
ทำไม Multi-Tenancy ของ Agent ถึงยากกว่าแอปพลิเคชันเว็บ
Multi-Tenancy แบบดั้งเดิมของแอปพลิเคชันเว็บแยกสิ่งเดียว: Data Row เพิ่มคอลัมน์ tenant_id กรองทุกคำสั่ง Query เสร็จสิ้น Multi-Tenancy ของ Agent ต้องแยกสามมิติเพิ่มเติมที่แอปพลิเคชันเว็บไม่เคยต้องจัดการ การล้มเหลวในมิติใดมิติหนึ่งก่อให้เกิดเหตุการณ์การรั่วไหลข้อมูลข้ามผู้เช่าภายใต้ OWASP LLM06 Sensitive Information Disclosure
สามมิติของการแยกที่แอปพลิเคชันเว็บไม่มี
การแยก Credential: แอปพลิเคชันเว็บระบุผู้ใช้ผ่าน Session Token; Session ไม่มีการเข้าถึงถาวรไปยังบริการภายนอก Agent ต้องการ API Key จริงที่กำหนดขอบเขตสำหรับผู้เช่า หาก Agent ของผู้เช่า A และ Agent ของผู้เช่า B ใช้ Key OpenAI เดียวกัน การใช้งานหนักของผู้เช่า A จะลดช่องว่าง Rate Limit ของผู้เช่า B; การเรียกเก็บเงินของผู้เช่า A กับผู้ให้บริการรวมถึงการใช้ Token ของผู้เช่า B; การเพิกถอน Key หลังจากผู้เช่า A ถูกบุกรุกก็ขัดจังหวะผู้เช่า B ด้วย
การแยกหน่วยความจำ: Agent สะสมหน่วยความจำการทำงาน (Context Window) หน่วยความจำเชิงความหมาย (Vector Store Embeddings) และสถานะการประสานงาน (Blackboard Entries) ระหว่างการโต้ตอบ หากไม่มีการแบ่งพาร์ทิชันตามผู้เช่าในพื้นที่จัดเก็บหน่วยความจำเหล่านี้ เอกสารของผู้เช่า A ที่ดึงมาในบริบทของ Agent ระหว่างงานหนึ่งอาจปรากฏในบริบทของ Agent ของผู้เช่า B ระหว่างงานที่คล้ายกันเชิงความหมาย โดยไม่ต้องมี Input ที่เป็นปรปักษ์ นี่คือสถานการณ์การรั่วไหลข้ามผู้เช่ามาตรฐานของ OWASP LLM06 v1.1
การแยก Audit Log: Audit Log ที่ใช้ร่วมกันซึ่งการเรียกใช้เครื่องมือของผู้เช่า A และผู้เช่า B ปะปนกันไม่สามารถส่งออกไปยังทีม Compliance ของผู้เช่า A โดยไม่เปิดเผยบันทึกของผู้เช่า B SOC 2 CC6.1 กำหนดให้ผู้ตรวจสอบของผู้เช่าแต่ละรายสามารถเห็นเฉพาะบันทึกของตนเองเท่านั้น
Shared-Nothing vs Pool vs Bridge: สามโมเดล Multi-Tenancy
โมเดล Silo (Shared-Nothing): ผู้เช่าแต่ละรายได้รับ Infrastructure ที่เฉพาะเจาะจงโดยสมบูรณ์ การแยกสูงสุดด้วยค่าใช้จ่ายสูงสุดต่อผู้เช่า เหมาะสำหรับผู้เช่าระดับองค์กรที่มีข้อกำหนดการอยู่อาศัยของข้อมูลที่เข้มงวดและอุตสาหกรรมที่ถูกควบคุม
โมเดล Pool: ผู้เช่าทั้งหมดใช้ Infrastructure ร่วมกัน โดยการแยกถูกบังคับใช้เฉพาะที่ชั้น Application ผ่านการกรองพารามิเตอร์ tenant_id ค่าใช้จ่ายต่ำสุด การแยกอ่อนแอที่สุด เหมาะสำหรับงานที่มีความอ่อนไหวต่ำโดยไม่มีลูกค้าระดับองค์กร
โมเดล Bridge: Infrastructure การคำนวณที่ใช้ร่วมกันโดยมีการแยกที่บังคับใช้ที่ Control Plane ผู้เช่าแต่ละรายได้รับ Credential Vault Scope เฉพาะและ Memory Namespace ที่บังคับใช้โดย ACL ของ Infrastructure การคำนวณถูกแบ่งปันแต่ควบคุมโดย Kubernetes Namespace ResourceQuota นี่คือค่าเริ่มต้นที่แนะนำสำหรับ B2B SaaS สถาปัตยกรรมตามโปรเจกต์ของ OpenLegion เป็นการใช้งานโมเดล Bridge
OWASP LLM06: การเปิดเผยข้อมูลที่ละเอียดอ่อนข้ามผู้เช่า
OWASP LLM Top 10 v1.1 จัดประเภทการรั่วไหลข้อมูลข้ามผู้เช่าภายใต้ LLM06: Sensitive Information Disclosure ว่ามีระดับความรุนแรงสูง
เวกเตอร์การโจมตีการรั่วไหลข้ามผู้เช่า
- Agent ของผู้เช่า A ประมวลผลคำขอสนับสนุนลูกค้า มันดึงเอกสารผลิตภัณฑ์ภายในและบันทึกลูกค้าของผู้เช่า A ไปยัง Context Window แล้วฝังและจัดเก็บข้อความที่เกี่ยวข้องใน Vector Store ที่ใช้ร่วมกัน
- Agent ของผู้เช่า B ประมวลผลคำขอที่คล้ายกันเชิงความหมาย มันสืบค้น Vector Store ที่ใช้ร่วมกัน; คำสั่ง Query ส่งคืนข้อความที่ฝังของผู้เช่า A เป็น Top-K Nearest Neighbors เนื่องจากมีความคล้ายกันเชิงธีมและไม่มี Index ที่แบ่งพาร์ทิชันตามผู้เช่า
- บันทึกลูกค้าภายในของผู้เช่า A ปรากฏในบริบทของ Agent ของผู้เช่า B
ไม่จำเป็นต้องมี Input ที่เป็นปรปักษ์ การรั่วไหลเป็นความล้มเหลวทางสถาปัตยกรรม
สำหรับ Framework ที่สมบูรณ์รวมถึงการ Inject Prompt (LLM01) ดู ความปลอดภัยของ AI Agent และโมเดลภัยคุกคาม OWASP LLM Top 10
การรั่วไหลของหน่วยความจำ: หน่วยความจำการทำงาน Vector Store และสถานะกระดาน
ประเภทหน่วยความจำ Agent สามประเภทแต่ละประเภทต้องการการจัดการการแยกผู้เช่าแยกต่างหาก:
หน่วยความจำการทำงาน (Context Window): Context Window ปัจจุบันของ Agent ต้องไม่ถูกแบ่งปันระหว่างคำขอของผู้เช่า
หน่วยความจำเชิงความหมาย (Vector Store): เมื่อใช้ Vector Store ที่ใช้ร่วมกัน การเขียนทุกครั้งต้องรวม tenant_id เป็นฟิลด์ Metadata ที่บังคับ และทุกคำสั่ง Query ต้องรวม Metadata Filter {tenant_id: current_tenant_id} ที่ Inject ที่ชั้น Storage Client
สถานะการประสานงาน (กระดาน): สถานะ Key-Value ที่แบ่งปันระหว่าง Agent ต้องใช้คำนำหน้า Key ที่กำหนดขอบเขตตามผู้เช่า เช่น projects/{tenant_id}/*
การแยก Credential: การกำหนดขอบเขต Vault ต่อผู้เช่า
การกำหนดขอบเขต Credential ต่อผู้เช่า: ทำไม API Key ที่ใช้ร่วมกันถึงล้มเหลว
ข้อผิดพลาด Credential Multi-Tenancy ที่พบบ่อยที่สุดคือการใช้ API Key LLM เดียวสำหรับผู้เช่าทั้งหมด ล้มเหลวสี่วิธีที่แตกต่างกัน: การแบ่งปัน Rate Limit ค่าใช้จ่ายที่ไม่สามารถระบุสาเหตุ ขอบเขตการเพิกถอน และการแยก Audit ที่เสียหาย
รูปแบบที่ถูกต้อง: ผู้เช่าแต่ละรายได้รับ API Key ของตนเอง สำหรับสถาปัตยกรรม Vault ที่สมบูรณ์ดู การจัดการ Credential และรูปแบบการกำหนดขอบเขต Vault ต่อผู้เช่า
Anti-Pattern JWT: Token Scope โดยไม่มีการเพิกถอน
มาตรการลดความเสี่ยงสามประการทั้งหมดจำเป็นพร้อมกัน:
- Token อายุสั้น: TTL ไม่เกิน 300 วินาที (5 นาที) สำหรับ Token การเรียกใช้เครื่องมือ Agent
- Registry การเพิกถอนที่ใช้งานอยู่: ตาราง ID Token ที่ถูกต้องต่อผู้เช่า
- การหมุนเวียน Token ต่องาน: ออก Token ใหม่สำหรับงาน Agent แต่ละงาน
การแยกการทำงาน: Kubernetes Namespace และ Resource Quota
Namespace ต่อผู้เช่า: RBAC, NetworkPolicy และ ResourceQuota
ต้องการสี่ส่วนประกอบ:
Namespace ต่อผู้เช่า: Agent Pod ของผู้เช่าแต่ละรายทำงานใน Kubernetes Namespace เฉพาะ
RBAC กับ ServiceAccounts ที่กำหนดขอบเขต Namespace: ผู้เช่าแต่ละรายได้รับ ServiceAccount เฉพาะพร้อม RoleBindings ที่กำหนดขอบเขตสำหรับ Namespace ของตนเอง
NetworkPolicy กับการปฏิเสธตามค่าเริ่มต้น: ใช้นโยบายปฏิเสธ Ingress และ Egress ทั้งหมดกับ Namespace ของผู้เช่าทุกรายตามค่าเริ่มต้น
ResourceQuota กับ LimitRange: ใช้ขีดจำกัด CPU หน่วยความจำ และจำนวน Pod ต่อ Namespace ผ่าน ResourceQuota
สำหรับการควบคุม Sandboxing ระดับกระบวนการดู AI Agent Sandboxing และการแยกการทำงานระดับกระบวนการ
SOC 2 Compliance สำหรับแพลตฟอร์ม Agent แบบ Multi-Tenant
CC6.1: การควบคุมการเข้าถึงเชิงตรรกะตามการจำแนกข้อมูล
SOC 2 Compliance CC6.1 ต้องการการควบคุมสามประการ: Scope ของ Credential Vault ต่อผู้เช่า Namespace หน่วยความจำต่อผู้เช่า และพาร์ทิชัน Audit Log ต่อผู้เช่า
ผู้ตรวจสอบ SOC 2 ตั้งค่าสถานะ API Key ที่ใช้ร่วมกันระหว่างผู้เช่าว่าเป็นข้อบกพร่อง CC6.1 สำหรับการแมปการควบคุมที่สมบูรณ์ดู การกำกับดูแล AI Agent และ Framework SOC 2 Compliance
CC6.6: การจำกัดการเข้าถึงที่มีสิทธิ์สำหรับ Agent ที่มีสิทธิ์สูง
SOC 2 Compliance CC6.6 ต้องการ: การป้องกันเชิงโครงสร้างของการเรียกใช้ Agent ที่มีสิทธิ์สูงข้ามผู้เช่า คำนิยามสิทธิ์ Agent ที่มีสิทธิ์ที่ตรวจสอบได้ และบันทึก Audit ต่อการเรียกใช้สำหรับการดำเนินการที่มีสิทธิ์
การแบ่งพาร์ทิชัน Audit Log ต่อผู้เช่า
รูปแบบ Key การจัดเก็บ: audit/{tenant_id}/{year}/{month}/{day}/{agent_id}/{tool_call_id}.json
นโยบาย S3 Bucket ต่อผู้เช่า: คำนำหน้า Bucket แยกต่างหากพร้อมนโยบายทรัพยากรแยกต่างหากต่อผู้เช่า
OTLP Resource Attributes: รวม tenant_id เป็น Resource Attribute ในทุก OpenTelemetry Log Record
SIEM Workspace ต่อผู้เช่า: ในการปรับใช้ SIEM ที่ใช้ร่วมกัน กำหนดค่า Index หรือ Workspace ต่อผู้เช่า
สำหรับการออกแบบ Audit Log ที่สมบูรณ์ดู AI Agent Audit Log และบันทึก Compliance ต่อผู้เช่า
Anti-Pattern: สิ่งที่ไม่ควรทำ
Anti-Pattern 1: Tenant ID ใน Agent Prompt ไม่ใช่ใน Infrastructure
การ Inject tenant_id เข้าไปใน System Prompt ของ Agent และอาศัย Agent เพื่อบังคับใช้ขอบเขตผู้เช่าของตนเองเป็น Anti-Pattern Multi-Tenancy ที่พบบ่อยที่สุดและอันตรายที่สุด ล้มเหลวเนื่องจากการข้าม Prompt Injection การล่องลอยของ Hallucination และไม่มีการบังคับใช้ Infrastructure
Anti-Pattern 2: Vector Store ที่ใช้ร่วมกันโดยไม่มี Tenant Filter
นี่คือเวกเตอร์การรั่วไหล OWASP LLM06 หลัก การแก้ไขต้องการฟิลด์ Metadata บังคับ tenant_id ในทุกการเขียนและ Metadata Filter ที่ Inject ที่ชั้น Storage Client ในทุกคำสั่ง Query
Anti-Pattern 3: API Key LLM ที่ใช้ร่วมกันพร้อม Tenant Claim ใน Prompt
Anti-Pattern นี้ล้มเหลวใน CC6.1: การแบ่งปัน Rate Limit ความล้มเหลวในการระบุสาเหตุค่าใช้จ่าย ขอบเขตการเพิกถอน และบันทึก Audit ของผู้ให้บริการที่ไม่สามารถแบ่งพาร์ทิชันต่อผู้เช่าได้
มุมมองของ OpenLegion: การแยกโดยสถาปัตยกรรมไม่ใช่ข้อตกลง
OpenLegion บังคับใช้การแยกผู้เช่าผ่านกลไกชั้น Infrastructure สามประการที่โค้ด Agent ไม่สามารถข้ามได้: การกำหนดขอบเขต Credential Vault ต่อโปรเจกต์ ACL Namespace กระดาน และการส่งข้อความ Agent ข้ามโปรเจกต์ที่ถูกบล็อกตามค่าเริ่มต้น
| การควบคุมการแยก | OpenLegion | LangChain / LangGraph | CrewAI | AutoGen | OpenAI Agents SDK |
|---|---|---|---|---|---|
| Credential Vault Scope ต่อผู้เช่า | บังคับใช้โดย Infrastructure | ข้อตกลงนักพัฒนา | ข้อตกลงนักพัฒนา | ข้อตกลงนักพัฒนา | ข้อตกลงนักพัฒนา |
| Blackboard Namespace ACL | บังคับใช้โดย Infrastructure | ไม่มี | ไม่มี | ไม่มี | ไม่มี |
| การส่งข้อความ Agent ข้ามโปรเจกต์ถูกบล็อก | บล็อกตามค่าเริ่มต้น | ไม่มี | ไม่มี | ไม่มี | ไม่มี |
| Budget Cap ต่อผู้เช่า (Zone 2) | บังคับใช้โดย Infrastructure | ข้อตกลงนักพัฒนา | ข้อตกลงนักพัฒนา | ข้อตกลงนักพัฒนา | ข้อตกลงนักพัฒนา |
| พาร์ทิชัน Audit ต่อผู้เช่า (WORM) | บังคับใช้โดย Infrastructure | ข้อตกลงนักพัฒนา | ข้อตกลงนักพัฒนา | ข้อตกลงนักพัฒนา | ข้อตกลงนักพัฒนา |
| Kubernetes Namespace + ResourceQuota | จัดการโดยแพลตฟอร์ม | จัดการเอง | จัดการเอง | จัดการเอง | จัดการเอง |
สำหรับชั้น Infrastructure ที่โฮสต์ดู แพลตฟอร์ม AI Agent ที่จัดการพร้อมการรับประกันการแยกผู้เช่า
คำถามที่พบบ่อย
Multi-Tenancy ของ AI Agent คืออะไร?
Multi-Tenancy ของ AI Agent คือคุณสมบัติทางสถาปัตยกรรมของแพลตฟอร์ม Agent ที่ทำให้แน่ใจว่า Agent ที่ให้บริการผู้เช่าต่างกันไม่สามารถเข้าถึง Credential หน่วยความจำ บริบทการทำงาน หรือบันทึกการตรวจสอบของกันและกันได้ บังคับใช้ที่ชั้น Infrastructure แทนที่จะเป็นข้อตกลงของนักพัฒนา แตกต่างจาก Multi-Tenancy แบบดั้งเดิมของแอปพลิเคชันเว็บในการต้องการสามมิติการแยกเพิ่มเติม: การกำหนดขอบเขต Credential Vault ต่อผู้เช่า การแบ่งพาร์ทิชันหน่วยความจำต่อผู้เช่า (Vector Store และกระดาน) และการแบ่งพาร์ทิชัน Audit Log ต่อผู้เช่า
OWASP LLM06 คืออะไรและส่งผลต่อระบบ Agent แบบ Multi-Tenant อย่างไร?
OWASP LLM Top 10 v1.1 LLM06 Sensitive Information Disclosure จัดประเภทการรั่วไหลข้อมูลข้ามผู้เช่าว่ามีระดับความรุนแรงสูง: สถานการณ์ที่ Agent ประมวลผลข้อมูลของผู้เช่า A จัดเก็บเอกสารที่ดึงมาในชั้นหน่วยความจำที่ใช้ร่วมกันโดยไม่มีการแบ่งพาร์ทิชันตามผู้เช่า แล้วแสดงในการตอบกลับของผู้เช่า B การโจมตีไม่ต้องการ Input ที่เป็นปรปักษ์ การลดความเสี่ยงต้องการการแบ่งพาร์ทิชันหน่วยความจำต่อผู้เช่าที่ชั้น Storage Client การกำหนดขอบเขต Credential ต่อผู้เช่า และพาร์ทิชัน Audit Log ต่อผู้เช่า
SOC 2 CC6.1 และ CC6.6 นำไปใช้กับแพลตฟอร์ม Agent แบบ Multi-Tenant อย่างไร?
SOC 2 Type II CC6.1 กำหนดให้การเข้าถึงเชิงตรรกะถูกจำกัดตามการจำแนกข้อมูล; ในระบบ Agent แบบ Multi-Tenant ขอบเขตผู้เช่าคือขอบเขตการจำแนกหลัก CC6.6 ใช้กับ Agent ที่มีสิทธิ์เครื่องมือสูง เช่น การเขียนฐานข้อมูลหรือการเรียก API ภายนอก API Key ที่ใช้ร่วมกันระหว่างผู้เช่าโดยทั่วไปจะถูกตั้งค่าสถานะว่าเป็นข้อบกพร่อง CC6.1
ช่องโหว่ JWT Token TTL ในระบบ Agent แบบ Multi-Tenant คืออะไร?
JWT Access Token ที่ใช้สำหรับบริบทผู้เช่าในการเรียกใช้เครื่องมือ Agent มักจะหมดอายุหลังจาก 3,600 วินาที (1 ชั่วโมง); หาก Token ที่ออกสำหรับผู้เช่า A ถูก Cache ไม่ถูกต้อง แบ่งปันโดย Bug ของ Infrastructure หรือถูกจับในบันทึกการ Debug สามารถใช้เพื่อทำการเรียกที่ผ่านการตรวจสอบสิทธิ์ที่ระบุว่าเป็นของผู้เช่า A ตลอดระยะเวลา TTL ทั้งหมดโดยไม่ถูกตรวจจับ การลดความเสี่ยงต้องการการควบคุมสามประการที่ใช้พร้อมกัน: Token อายุสั้นที่มี TTL ไม่เกิน 300 วินาที Registry การเพิกถอน Token ที่ใช้งานอยู่ต่อผู้เช่า และการหมุนเวียน Token ต่องาน
การแยก Kubernetes Namespace ทำงานอย่างไรสำหรับ Agent แบบ Multi-Tenant?
การแยก Kubernetes Namespace ให้การแยกการทำงานผ่านสี่ส่วนประกอบ: Namespace เฉพาะต่อผู้เช่า RBAC กับ ServiceAccounts ต่อผู้เช่าและ RoleBindings ที่กำหนดขอบเขต Namespace NetworkPolicy กับการปฏิเสธตามค่าเริ่มต้นและรายการอนุญาตที่ชัดเจนสำหรับ Endpoint ภายนอกที่จำเป็นเท่านั้น และ ResourceQuota กับขีดจำกัดการคำนวณต่อ Namespace การแยก Namespace จัดการมิติการคำนวณของ Multi-Tenancy และต้องรวมกับการกำหนดขอบเขต Credential ต่อผู้เช่าและการแบ่งพาร์ทิชันหน่วยความจำ
Anti-Pattern Vector Store ที่ใช้ร่วมกันในระบบ Agent แบบ Multi-Tenant คืออะไร?
การใช้ Vector Store ที่ใช้ร่วมกันโดยไม่มี Tenant Filter ที่บังคับต่อ Query ที่ Inject ที่ชั้น Storage Client เป็นเวกเตอร์การรั่วไหล OWASP LLM06 หลัก การใช้งานที่ถูกต้องต้องการฟิลด์ Metadata tenant_id ในทุกการเขียนและ Metadata Filter ที่ Inject ที่ชั้น Vector Store Client ในทุกคำสั่ง Query สำหรับข้อกำหนด Compliance ที่เข้มงวด Namespace ต่อผู้เช่าหรือ Index แยกต่างหากบังคับใช้ขอบเขตที่ชั้นที่อยู่ Storage
OpenLegion บังคับใช้การแยกผู้เช่าอย่างไร?
OpenLegion บังคับใช้การแยกผู้เช่าผ่านกลไกชั้น Infrastructure สามประการ: การกำหนดขอบเขต Credential Vault ต่อโปรเจกต์ (Zone 2 แก้ไข Handle $CRED{} โดยใช้บริบทโปรเจกต์ที่ตรวจสอบสิทธิ์แล้วจาก Mesh Session ไม่ใช่พารามิเตอร์ที่ Agent ให้มา; การแก้ไข Credential ข้ามโปรเจกต์เป็นไปไม่ได้ทางสถาปัตยกรรม) ACL Namespace กระดาน (Agent มีสิทธิ์อ่านและเขียนเฉพาะสำหรับคำนำหน้า Key ของโปรเจกต์ของตนเอง บังคับใช้โดย Mesh Supervisor) และการส่งข้อความ Agent ข้ามโปรเจกต์ที่ถูกบล็อกตามค่าเริ่มต้น
สามโมเดลสถาปัตยกรรม Multi-Tenancy สำหรับแพลตฟอร์ม Agent คืออะไร?
สามโมเดล Multi-Tenancy มีการรับประกันการแยกและโปรไฟล์ค่าใช้จ่ายที่แตกต่างกัน: โมเดล Silo (Shared-Nothing) ให้ผู้เช่าแต่ละรายมี Infrastructure ที่เฉพาะเจาะจงโดยสมบูรณ์; โมเดล Pool ใช้ Infrastructure ทั้งหมดร่วมกันโดยการแยกถูกบังคับใช้เฉพาะที่ชั้น Application; โมเดล Bridge ใช้ Infrastructure การคำนวณร่วมกันในขณะที่บังคับใช้การแยกที่ Control Plane ผ่าน Credential Vault Scope ต่อผู้เช่าและ ACL Namespace หน่วยความจำ โมเดล Bridge คือค่าเริ่มต้นที่แนะนำสำหรับ B2B SaaS