本文是 Apache Kafka overview「Multi-tenant 與配額治理」「Topic 生命週期治理」兩段的 implementation-layer deep article。Overview 說明這些議題對應哪些案例跟子議題、本文展開具體的 quota / ACL 配置、授權模型推導、故障徵兆與修法。

共享叢集的治理問題：一個叢集、多個互不信任的租戶

Multi-tenant Kafka 的核心問題是把一個物理叢集切成多個彼此隔離的邏輯空間、讓每個團隊用同一組 broker 卻不互相干擾。當 Kafka 從單一團隊的工具長成全公司的事件總線、叢集承載的不再是一條 pipeline、而是數十到數百個團隊的 producer 跟 consumer。這時叢集的瓶頸從「broker 夠不夠快」轉成「怎麼防止某個團隊的流量、權限、或 topic 失控波及其他所有人」。

Uber 的 Kafka 平台演進把這個轉換描述為「從單隊列問題提升到平台治理問題」。當事件平台服務眾多團隊、重點是配額、隔離、觀測與運維標準化、而非只擴 broker。擴 broker 解決的是總容量、解決不了「單一租戶吃光共享資源」這類隔離問題。

共享叢集的治理分三個獨立的軸、各自處理不同的失控來源：

三軸正交：quota 設好不代表權限對、ACL 鎖好不代表 topic 不會爆炸。下面逐軸展開、每軸都對應 production 踩過的失控場景。本文 quota 與 ACL 操作以 Kafka 4.2.0（KRaft 模式、apache/kafka:latest）實機驗證。

Quota：把頻寬與 request 容量切給租戶

Quota 是 broker 端對 client 的流量上限、由 broker 在超限時主動 throttle（延遲回應）而非拒絕、讓單一租戶無法把共享頻寬吃光。Kafka 的 quota 是 broker-side 強制、不依賴 client 自律 —— 即使 client 不配合、broker 也會在回應裡插入 throttle 延遲、把該 client 的有效吞吐壓回配額內。

三類 quota 度量

Kafka quota 度量三種資源、對應三類飽和：

前兩個 byte rate 防的是頻寬類飽和、適合「大訊息、穩定流量」的租戶。request_percentage 防的是另一種失控 —— 某租戶送大量極小的 request（例如每筆一個 byte、每秒幾萬筆）、byte rate 看起來很低、卻把 broker 的 request handler thread 佔滿。這種「請求數爆炸但流量不大」的攻擊型 pattern 只有 request_percentage 抓得到。一個 broker 預設有 N 個 request handler thread、request_percentage=200 代表允許該 client 用掉 2 條 thread 的時間（100% = 1 條）。

三種套用層級

Quota 可以套在三種 entity 上、精度遞增：

層級的選擇取決於認證模型。沒開認證的叢集只能用 client-id —— 但 client.id 由 client 自行宣告、可偽造、只適合內部信任環境的粗略區分。開了 SASL 認證後、user 才是可信的租戶邊界、quota 綁 user 才有隔離意義。最細的 user + client-id 組合用在「同一個租戶內、batch 匯入服務跟即時 API 服務要分開限流」這種情境：整個 billing 租戶有一個總配額、但裡面的 batch-importer 再單獨壓低、避免夜間批次把租戶配額吃光、害同租戶的即時服務沒頻寬。

設定與查詢（實機驗證）

設 client-id 層級、同時給 producer 跟 consumer byte rate：

1kafka-configs.sh --bootstrap-server localhost:9092 --alter \
2  --add-config 'producer_byte_rate=1048576,consumer_byte_rate=2097152' \
3  --entity-type clients --entity-name svc-orders
4# Completed updating config for client svc-orders.

設 user 層級、含 request_percentage：

1kafka-configs.sh --bootstrap-server localhost:9092 --alter \
2  --add-config 'producer_byte_rate=5242880,consumer_byte_rate=10485760,request_percentage=200' \
3  --entity-type users --entity-name tenant-billing
4# Completed updating config for user tenant-billing.

設 user + client-id 組合層級（同租戶內單獨壓低 batch 服務）：

1kafka-configs.sh --bootstrap-server localhost:9092 --alter \
2  --add-config 'producer_byte_rate=524288' \
3  --entity-type users --entity-name tenant-billing \
4  --entity-type clients --entity-name batch-importer
5# Completed updating config for user tenant-billing.

查詢時 entity 指定要對齊設定時的層級。查 user 層級：

1kafka-configs.sh --bootstrap-server localhost:9092 --describe \
2  --entity-type users --entity-name tenant-billing
3# Quota configs for user-principal 'tenant-billing' are
4#   consumer_byte_rate=1.048576E7, request_percentage=200.0, producer_byte_rate=5242880.0

組合層級要兩個 entity 都帶、否則查不到：

1kafka-configs.sh --bootstrap-server localhost:9092 --describe \
2  --entity-type users --entity-name tenant-billing \
3  --entity-type clients --entity-name batch-importer
4# Quota configs for user-principal 'tenant-billing', client-id 'batch-importer' are
5#   producer_byte_rate=524288.0

不帶 --entity-name 而只給 --entity-type clients 會列出所有 client-id 層級的 quota、適合稽核整個叢集的 quota 分布。

ACL：把存取權限綁到 principal

ACL 是 broker 對每個操作的授權檢查、把「誰（principal）能對什麼資源（resource）做什麼操作（operation）從哪裡來（host）」綁成一條規則、broker 在每次 produce / fetch / admin 操作前比對。Quota 管的是「用多少」、ACL 管的是「能不能用」—— 兩者正交、quota 不限制權限、ACL 不限制流量。

授權模型四要素

一條 ACL 由四個維度構成、四個維度交集才決定一次操作是否放行：

resource 的 pattern type 是隔離設計的關鍵：LITERAL 精確匹配單一資源名、PREFIXED 匹配整個前綴。多租戶的 topic 隔離靠 prefixed ACL 加命名規範 —— 給 tenant-billing 一條 billing. 前綴的 All 權限、它就能自由管理所有 billing. 開頭的 topic、卻碰不到 orders. 或別租戶的命名空間。命名規範在這裡不只是整潔、是授權邊界本身。

operation 的選擇要對齊角色。一個 producer 需要 topic 的 Write 跟 Describe（描述 partition metadata）；一個 consumer 需要 topic 的 Read Describe 加上 consumer group 的 Read Describe（commit offset 要對 group 有權）。漏掉 group 的 ACL 是常見錯誤：consumer 能讀到訊息、卻 commit 不了 offset、表現成不斷重複消費。

KRaft 的 StandardAuthorizer

ACL 的儲存與判定由 broker 的 authorizer 負責。KRaft 模式用 org.apache.kafka.metadata.authorizer.StandardAuthorizer、ACL 存在 metadata log（取代 ZooKeeper 時代的 AclAuthorizer 把 ACL 存在 ZK）。預設的 apache/kafka 容器不開 authorizer —— 不開時所有操作放行、ACL 指令也無從生效。啟用需要在 broker 設三項：

1authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer
2super.users=User:admin
3allow.everyone.if.no.acl.found=false

super.users 列出繞過所有 ACL 檢查的管理身分、用來開機跟救援；少了它、開 authorizer 後第一個操作就會把自己鎖在外面。allow.everyone.if.no.acl.found=false 是隔離的前提 —— 設 true 時「沒有任何 ACL 的資源對所有人開放」、等於 deny-list 模式、漏設一個 topic 就全公司可讀。多租戶必須走 false 的 allow-list 模式：預設拒絕、明確授權才放行。

本文 ACL 操作以實機驗證：用上述三項 env（KAFKA_AUTHORIZER_CLASS_NAME / KAFKA_SUPER_USERS='User:ANONYMOUS' / KAFKA_ALLOW_EVERYONE_IF_NO_ACL_FOUND=false）配完整 KRaft single-node 設定起容器、PLAINTEXT 連線的 principal 為 User:ANONYMOUS、設為 super user 後即可用 kafka-acls.sh 操作。

ACL 配置（實機驗證）

給 producer 對單一 topic 的 write + describe：

1kafka-acls.sh --bootstrap-server localhost:9092 --add \
2  --allow-principal User:svc-orders \
3  --operation Write --operation Describe \
4  --topic orders.events

給 consumer topic 的 read + describe、外加 consumer group 的權限（一條指令同時建兩個 resource 的 ACL）：

1kafka-acls.sh --bootstrap-server localhost:9092 --add \
2  --allow-principal User:svc-fulfillment \
3  --operation Read --operation Describe \
4  --topic orders.events \
5  --group fulfillment-workers

prefixed ACL 把整個命名空間授權給一個租戶：

1kafka-acls.sh --bootstrap-server localhost:9092 --add \
2  --allow-principal User:tenant-billing \
3  --operation All \
4  --resource-pattern-type prefixed \
5  --topic billing.
6# Adding ACLs for resource
7#   `ResourcePattern(resourceType=TOPIC, name=billing., patternType=PREFIXED)`

host 限制把同一 principal 的權限綁到特定來源 IP：

1kafka-acls.sh --bootstrap-server localhost:9092 --add \
2  --allow-principal User:svc-orders \
3  --allow-host 10.0.3.21 \
4  --operation Write \
5  --topic orders.events

deny 規則的優先序高於 allow —— 同一 principal 即使有 allow、命中 deny 就拒絕。用來在大範圍 allow（如 prefixed All）之上挖一個例外：

1kafka-acls.sh --bootstrap-server localhost:9092 --add \
2  --deny-principal User:svc-orders \
3  --deny-host 10.0.9.99 \
4  --operation Write \
5  --topic orders.events

列出特定 topic 的全部 ACL、用於稽核：

1kafka-acls.sh --bootstrap-server localhost:9092 --list --topic orders.events

Topic 生命週期治理：命名、ownership 與回收

Topic 生命週期治理把「topic 的建立、歸屬、淘汰」變成有規則的流程、避免死 topic 累積與 partition 數爆炸壓垮叢集的 metadata 面。Kafka 的每個 partition 都是 controller 要追蹤的 metadata 單位；topic 只增不減時、partition 總數隨團隊數線性成長、最終 controller 的 metadata 處理、broker 的 leader election、client 的 metadata fetch 都跟著變慢。

命名規範劃出 ownership

Topic 命名規範把 ownership 跟隔離邊界編碼進名字本身。一個可治理的命名規範通常含三段：租戶 / 領域前綴、語意名、版本。例如 billing.invoices.v1 —— billing. 前綴對齊 prefixed ACL 的隔離邊界跟 quota 的租戶歸屬、invoices 是語意、v1 給 schema 演進留出平行存在的空間。命名規範在多租戶不是風格問題、是三個治理軸的共同錨點：ACL 靠前綴授權、quota 靠前綴歸屬、回收靠前綴找 owner。

實機建 topic 時 Kafka 4.2.0 對 . 跟 _ 混用會出 metric 名稱碰撞警告：

1WARNING: Due to limitations in metric names, topics with a period ('.')
2or underscore ('_') could collide. To avoid issues it is best to use
3either, but not both.

成因是 metric 名把 topic 名裡的 . 跟 _ 都正規化掉、billing.invoices 跟 billing_invoices 可能對映到同一條 metric。命名規範應在 . 跟 _ 之間選一個當分隔符、全叢集一致、避免監控數據互相污染。

活躍判準與自動回收

死 topic 的回收靠可量化的活躍判準。LinkedIn 的 TopicGC以自動治理取代手動清理未使用 topic、降低 metadata 壓力並改善 produce / consume 效能。它的判讀是：當 queue 規模擴大、僅靠容量擴充不夠、topic 生命週期與治理自動化會成為可靠性關鍵。

TopicGC 是 LinkedIn 的內部系統、不是 Kafka 內建指令；它揭示的是一套可借鏡的回收流程結構：

1. 定義活躍判準：以 last produce / last consume timestamp 判斷 topic 是否仍在使用、設一段觀察窗（例如 N 天無寫入且無讀取）。
2. 分級回收：先標記（soft）、進入待回收狀態並通知 owner、保留一段 grace period、無人認領才真正刪除（hard）。兩段式避免誤刪仍有低頻流量的 topic。
3. 保留稽核：每次標記與刪除留紀錄、回收前後比對 controller log、partition 數量、produce / consume 效能指標、確認治理有效且無誤傷。

回收條件的設定要對齊業務節奏。純看 produce timestamp 會誤判「低頻但關鍵」的 topic（如月結批次）；活躍判準要同時看 produce 跟 consume、且觀察窗要長於最長的合法閒置週期。

Production 故障演練

Case 1：單一租戶暴衝吃滿頻寬（quota 缺位）

徵兆：某團隊上線一支新 backfill job、開始全速寫入；同叢集其他租戶的 producer 端 request-latency p99 從個位數 ms 跳到數百 ms、consumer lag 全面上升；broker network out 打到網卡上限、但 CPU 不高。受害的不是暴衝者自己、是所有共用 broker 的鄰居。

根因：叢集沒設任何 producer quota、或只對部分租戶設了 quota。沒有 broker-side throttle 時、單一 client 能用滿 broker 的 network / disk I/O、把共享頻寬擠光。byte rate 飽和的特徵是 network 打滿但 CPU 不高 —— 區別於 request_percentage 缺位導致的 CPU 飽和。

修法：

1. 立即對暴衝 client 設 producer_byte_rate、broker 即時 throttle、無需重啟。
2. 建立 quota 預設值：對所有 client-id（或 user）設一個保守的 default byte rate、新租戶上線自動受限、避免「漏設就無限」。
3. 區分 byte rate 與 request_percentage 飽和：network 打滿設 byte rate、CPU 打滿（高頻小訊息）補 request_percentage。
4. 容量規劃：把各租戶 quota 總和對齊 broker 的 network / disk 容量、留 headroom、避免「每個 quota 都合理但加總超過物理上限」。

Case 2：ACL 設太鬆或太緊

徵兆（太鬆）：稽核發現某 consumer 服務能讀到不屬於它的租戶 topic；或某 topic 被預期外的 principal 寫入、資料被污染。最壞情況是 allow.everyone.if.no.acl.found=true 下漏設 ACL 的 topic 對全叢集可讀寫。

徵兆（太緊）：consumer 能讀訊息卻不斷重複消費、log 顯示 commit offset 被拒；或 producer 報 TOPIC_AUTHORIZATION_FAILED、明明該有權限。

根因：太鬆來自 deny-list 心態 —— allow.everyone.if.no.acl.found=true 把「沒設 ACL」當成「開放」、漏設就外洩。太緊通常是漏掉 operation 或 resource：consumer 只給了 topic 的 Read、漏給 consumer group 的 Read Describe、於是讀得到但 commit 不了、表現成重複消費；producer 漏給 Describe、拿不到 partition metadata。

修法：

1. 走 allow-list：allow.everyone.if.no.acl.found=false、預設拒絕、明確授權才放行。
2. ACL 對齊角色模板：producer = topic Write + Describe；consumer = topic Read + Describe 加 group Read + Describe；漏 group ACL 是重複消費的常見根因。
3. 用 prefixed ACL 而非逐 topic 設、把授權邊界對齊命名規範前綴、減少漏設。
4. 稽核流程：定期 kafka-acls.sh --list 比對預期授權矩陣、把 ACL 納入版本控制與 review、而非手動逐條加。

Case 3：Topic 數量爆炸壓垮 metadata 面

徵兆：叢集 topic / partition 總數隨團隊增長爬到數萬以上；controller failover 時間從秒級拉長到分鐘級；broker 啟動載入 metadata 變慢；client 的 metadata fetch 變大變慢、rebalance 期間出現連鎖延遲。容量沒滿、但整個叢集的 control plane 變鈍。

根因：partition 是 controller 要追蹤的 metadata 單位、數量只增不減。每個團隊隨手建 topic、每個 topic 又開高 partition 數、總 partition 數線性甚至超線性成長、壓垮 metadata 處理。KRaft 相比 ZooKeeper 提高了 metadata 上限、但上限仍存在、不是無限。

修法：

1. Partition 數規劃納入 topic 建立流程：partition 數對應並行度上限、不是越多越好；多餘 partition 是純 metadata 成本。詳見 Partition 卡。
2. 回收死 topic 釋放 partition slot：見 Case 4 與生命週期治理段。
3. 監控 metadata 壓力訊號：controller log、partition 總數、controller failover 時間設告警、在壓垮前介入。
4. 規模化路徑：單叢集 metadata 逼近上限時、評估分群（依關鍵程度分多叢集）、見 overview 的 Cross-region 與分層叢集段與 LinkedIn Tiered Clusters案例。

Case 4：Unused topic 未回收

徵兆：叢集裡大量 topic 數月無 produce 也無 consume、卻持續佔 partition slot 跟 metadata；沒人記得某些 topic 屬於哪個團隊、不敢刪；新 topic 想建時撞到 partition 上限、被迫先擴叢集而非先回收。

根因：沒有活躍判準與回收流程、topic 只建不刪。歸屬資訊沒編碼進命名、回收時找不到 owner、於是「不敢刪」成為預設、死 topic 無限累積。這是 Case 3（metadata 爆炸）的慢性來源。

修法：

1. 建立活躍判準：以 last produce / last consume timestamp 加觀察窗判定死 topic、觀察窗長於最長合法閒置週期（避免誤刪月結類低頻 topic）。
2. 兩段式回收：先 soft 標記並通知 owner、grace period 內無人認領才 hard 刪除、避免誤刪。
3. 命名規範補 ownership：前綴對齊團隊、回收時能直接找到 owner、消除「不敢刪」。
4. 自動化加稽核：參考 TopicGC的流程結構、回收前後比對 metadata 與效能指標、留稽核紀錄。

容量與規模邊界

Quota 與 ACL 是 broker-side 即時生效、不需重啟、可隨租戶調整、運維成本低。生命週期治理是持續流程、不是一次性操作 —— 死 topic 會持續產生、回收要常態化。三軸的共同前提是命名規範：沒有可治理的命名、quota 找不到歸屬、ACL 邊界對不齊、回收找不到 owner。多租戶治理的第一步是先把命名規範立起來、再談 quota 與 ACL。

整合與下一步

跟 overview 與案例的對位

• 上游 vendor 頁：Apache Kafka —— 本文展開其「Multi-tenant 與配額治理」「Topic 生命週期治理」兩段
• 平台治理案例：3.C6 Uber Kafka 事件平台 —— 單隊列問題提升到平台治理
• 生命週期案例：3.C3 LinkedIn TopicGC —— 自動回收與 metadata 壓力
• 規模化分群：3.C4 LinkedIn Tiered Clusters —— metadata 逼近上限時的多叢集路徑
• 自管轉 managed 的 ACL cutover：3.C2 VMware → MSK

跟安全模組對位

ACL 是 Kafka 內建的授權層、處理 broker 級的 principal × resource 授權。完整的 secret 管理（SASL 認證憑證怎麼發、輪替、撤銷）屬於 07 資料保護與安全模組的範疇 —— ACL 綁的 principal 從哪來、由認證層決定、ACL 只負責「這個 principal 能做什麼」。多租戶的完整信任鏈是「認證確認身分（07）→ ACL 授權操作（本文）→ quota 限制用量（本文）」三層。

下一步議題

• Schema 治理：跨租戶共用 topic 時、schema compatibility 是另一層契約治理、見 overview 的 KRaft 與 Schema Registry段
• Consumer group ACL 細節：跟 Consumer group rebalance 的互動
• Quota 與 delivery semantics：throttle 延遲對 producer timeout / retry 的影響

相關連結

• 上游 vendor 頁：Apache Kafka
• 對位 deep article（同模組）：本模組其他 Kafka deep article 見 vendor 頁進階主題段
• 跨模組授權鏈：07 資料保護與安全模組
• 方法論：Vendor 深度技術文章的寫作方法論
• 知識卡：Topic、Partition、Consumer group

本章寫作邊界

本章聚焦 production LLM 推論的多租戶 isolation 特殊性。team / 個人 dev 場景的「多人共用本地 server」見 llm/6.5 跨進 production 的 routing 中樞；通用 IAM / 服務間信任邊界見 7.2。

本章 threat scope

In-scope：KV cache 跨租戶洩漏、prompt log 隔離、模型 artifact 訪問權、batch 推論的順序敏感性、tenant-scoped rate limit、共用 GPU 上的記憶體殘留。

Out-of-scope（路由到他章）：

• 通用 IAM / 服務間信任 → 7.2 identity-access-boundary
• workload identity → 7.7 workload-identity-and-federated-trust
• log / PII 治理 → llm-log-and-pii-governance
• model artifact 供應鏈 → llm-deployment-supply-chain
• 入口治理 → 7.3 entrypoint-and-server-protection

從本章到實作

• Mechanism：問題節點表 → knowledge-card → 看具體機制。
• Delivery：交接路由 → 05-deployment-platform / 06-reliability / 08-incident-response。

LLM 多租戶隔離的三個 LLM-specific 層

跟一般 service 的多租戶隔離（compute / network / data）相比、LLM 推論服務多了三個層次：

1. KV cache 層：KV cache 是推論時的 attention 暫存、跨 request 可能重用（prefix cache、shared prefix optimization）；跨租戶共用 cache 是直接的資料洩漏面。
2. prompt log 層：production LLM 服務通常會 log prompt + response 用於 debug / billing / abuse detection；log 的隔離與保留期限直接影響跨租戶洩漏風險。
3. model artifact 訪問權：production 可能部署多個 fine-tuned 模型（如 customer-specific 模型）、模型本身是 sensitive artifact、訪問權要對齊 IAM。

分析模型

production LLM 推論的多租戶隔離依四個層次分析：

1. memory 層：GPU VRAM、CPU RAM 中的 KV cache 跟模型權重、跨 request / 跨租戶的殘留與共享邊界。
2. storage 層：模型 artifact、prompt log、context cache 在儲存層的隔離。
3. identity 層：tenant identity 怎麼帶到 inference call、rate limit / quota 怎麼按租戶分。
4. observability 層：metric / log / trace 中的 tenant tag、跨租戶分析的允許範圍。

判讀流程

判讀流程的責任是把「能服務多個租戶的 LLM 服務」轉成「租戶間資料不互相洩漏的 LLM 服務」。

1. 先確認 tenant identity 從 API gateway 到 inference call 的傳遞路徑。
2. 再確認 KV cache、prompt log、model artifact 各自的隔離邊界。
3. 接著確認 GPU 記憶體中的跨 request 殘留是否清理。
4. 最後交接到偵測流程、確認跨租戶異常能被識別。

問題節點（案例觸發式）

常見風險邊界

風險邊界的責任是界定何時 LLM 多租戶 isolation 已進入高壓狀態。

• KV cache 共用範圍跨越 tenant 邊界時、代表記憶體層 isolation 失效。
• prompt log 沒帶 tenant tag、或 tag 後仍可跨 tenant 查時、代表 log 層 isolation 不足。
• 模型 artifact 訪問權跟 IAM 解耦時、代表 identity 層 isolation 不足。
• 推論 batch 對 tenant boundary 不敏感時、代表 batch 層的 noisy-neighbor 風險上升。

LLM 場景的特殊判讀

LLM 多租戶 isolation 相對一般 multi-tenant 服務的特殊性：

1. KV cache 是有用但敏感的優化：shared prefix cache（如多 tenant 用同一 system prompt）能省大量 prefill 算力、但跨 tenant 共用就是洩漏。判讀：可以 share 同 tenant 內的 prefix、不能 share 跨 tenant。
2. prompt log 含豐富使用者意圖：相比一般 API log 主要記 endpoint / status code、LLM prompt log 記的是「使用者實際在問什麼」、隱私敏感度高得多。
3. GPU 是稀缺資源、共用比 CPU 多：production LLM 服務常多 tenant 共用同卡、isolation 比一般 multi-tenant 服務（每 tenant 跑獨立 pod）更難做、需要更細的 batch 跟 memory 管理。
4. fine-tuned 模型本身是 customer asset：模型訓練成本高、權重是客戶 IP、訪問權混亂直接是 IP 外洩。
5. 「LLM 記住 cross-tenant 資訊」的疑慮：使用者常擔心 LLM 把 A tenant 的 prompt「記住」洩漏給 B tenant；對 inference-only 服務（無 fine-tune）這不發生（模型權重 immutable）、有 fine-tune 時要看 training data 隔離。

案例觸發參考

LLM 多租戶 isolation 的公開案例累積中、本章先沿用通用 multi-tenant 案例：

• 一般 multi-tenant 隔離案例見 7.2 身分授權邊界。
• LLM-specific 案例累積後會補入 red-team/cases/llm-multi-tenant/。

事實查核註：LLM 多租戶 isolation 的公開事件案例還在早期、社群上有些「LLM A 的 system prompt 被 B 看到」等報告、多數屬 prompt injection 範疇而非 cache 洩漏。建議引用前以最新的 OWASP LLM Top 10 跟具體 vendor 的 incident 公告為準。

引用標準

引用版本與 cadence 規則見 security-citation-currency-and-precision。Last reviewed: 2026-05-12。

下一步路由

• 身份授權邊界：7.2 identity-access-boundary
• log 治理：llm-log-and-pii-governance
• agent prompt injection 後果：llm-prompt-injection-in-agent
• 部署平台：05-deployment-platform
• 可靠性：06-reliability