一、資料安全與隱私

# 控制項目 說明 對照 OWASP 風險 優先級 負責角色
1.1 資料分級與標籤 對可能進出 AI 的資料做分級（公開/內部/機密/高度機密）並 tagging LLM03, LLM06 高 資安主管 / 資料治理負責人
1.2 最小揭露原則 只讓模型看到完成任務必要的最少資料，敏感欄位遮罩或 token 化 LLM06 高 AI 工程師 / 資安工程師
1.3 個資與機密輸出防止 模型回應前檢查是否包含個資、客戶資料、原始碼、內部文件等 LLM06 高 資安工程師
1.4 RAG / 向量資料庫權限隔離 不同使用者/部門的檢索資料要權限隔離，AI 只能看權限內資料 LLM06 高 AI 工程師 / 資料庫管理員
1.5 日誌與訓練資料保存策略 保留必要日誌但避免保存敏感資料；設定刪除與脫敏規則 LLM06 中 資安工程師 / 資料庫管理員

方案

控制項目 對應解決方案
1.1 資料分級與標籤 - 部署 資料发现與分級工具（如 Microsoft Purview, McAlee DLP, Forcepoint,open-source: graftcp + custom classifier）- 建立 資料分級政策（公開/內部/機密/高度機密）並自動 tagging- 在資料湖/向量資料庫中新增 classification 欄位，供 AI 檢索時做權限過濾
1.2 最小揭露原則 - 實作 prompt 模板引擎，只填入必要欄位- 在進入模型前加 資料遮罩層（masking/tokenization）- 對 RAG 檢索結果做 行級過濾：只回傳權限內的片段
1.3 個資與機密輸出防止 - 在 AI 回應送出前，加 輸出掃描層： - 規律表達式偵測身分證、電話、邮箱、卡號 - NLP 模型偵測個資/機密實體- 一旦命中，直接 blocked 或 自動遮罩 後再回傳
1.4 RAG / 向量資料庫權限隔離 - 使用支持 多租户 / 行級權限 的向量資料庫（如 Milvus, Weaviate, Pinecone with RBAC）- 將使用者身分（OIDC token、group）傳入檢索查詢，在建構 vector query 時加入 權限 filter- 避免把所有文件建同一個集合，按部門/專案分 collection
1.5 日誌與訓練資料保存策略 - 設定日誌 脫敏規則：自動移除或 hash 敏感欄位- 對訓練/微調資料建立 保留政策（例如 90 天後自動刪除或匿名化）- 使用 資料生命週期管理工具（如 AWS Glue DataBrew + S3 lifecycle）

二、Prompt 與輸入安全

# 控制項目 說明 對照 OWASP 風險 優先級 負責角色
2.1 Prompt Injection 防護 偵測並攔截惡意提示詞，包含直接與間接注入 LLM01 高 AI 工程師 / 資安工程師
2.2 輸入限制與速率限制 限制 prompt 長度、複雜度、請求頻率，避免 DoS LLM01, LLM04 中 DevOps / 資安工程師
2.3 分隔提示與資料 用明確分隔符號與結構化方式區分系統提示、用戶輸入、資料 LLM01 高 AI 工程師
2.4 外部輸入清洗 对來自郵件、文件、API、網頁等外部來源的輸入要先清洗再給模型 LLM01 高 AI 工程師

方案：

控制項目 對應解決方案
2.1 Prompt Injection 防護 - 使用 專為 LLM 設計的輸入過濾服務（如 Lakera Guard, Protect AI, Rebuff, Microsoft Azure AI Content Safety）- 實作 分隔策略：用明確分隔符（如 ###USER###、###SYSTEM###）區分提示與資料- 對敏感操作要求 二次確認 prompt，避免直接依賴模型決議
2.2 輸入限制與速率限制 - 在 API Gateway（如 Kong, Apigee, AWS API Gateway）設定： - max prompt length - QPS / RPM 限制 - 單一使用者/帳號限流- 使用 WAF + 自訂規則 阻擋明顯惡意 payload
2.3 分隔提示與資料 - 採用 結構化 prompt 模板（JSON/YAML），明確區分： - system instruction - user input - context / retrieved docs- 在程式碼層強制檢查：用戶輸入 нельзя 直接拼接到 system prompt
2.4 外部輸入清洗 - 對郵件、PDF、Word、網頁等外部來源：先做 ETL + 清洗（去除 HTML 標籤、腳本、隱碼）- 使用 文件解析器 + 白名單（只允許特定標籤與格式）- 對可疑內容先送 惡意文件掃描（如 ClamAV, Microsoft Defender for Office 365）再給模型

三、輸出處理與自動化

# 控制項目 說明 對照 OWASP 風險 優先級 負責角色
3.1 輸出驗證與沙箱 AI 輸出不可直接信任，需驗證後才進入系統或執行 LLM02 高 AI 工程師 / DevOps
3.2 自動化動作權限切割 AI 可執行的自動化動作（發信、下單、改設定）需權限分離與審批 LLM02, LLM08 高 資安主管 / 系統管理員
3.3 關鍵動作人工覆核 對高風險操作（資金、權限變更、刪除）必填二次確認或人工審批 LLM08 高 專案負責人
3.4 輸出白名單與格式驗證 對輸出內容做 schema、格式、範圍、白名單檢查 LLM02 中 AI 工程師

方案：

控制項目 對應解決方案
3.1 輸出驗證與沙箱 - 對 AI 輸出的指令/程式碼，在 沙箱環境（如 gVisor, Firecracker, Docker with seccomp）執行- 使用 輸出 schema 驗證（JSON Schema, Protobuf）確保格式正確- 對關鍵動作（如發郵件、改設定）要求 人工審核或 API 審批工作流
3.2 自動化動作權限切割 - 為 AI 建立 獨立 service account，權限只給必要 API- 對高風險操作要求 二次確認（例如：先寫入待確認隊列，由人以 UI 核准後再執行）- 使用 工作流引擎（如 Camunda, Airflow, Azure Logic Apps）做審批流程
3.3 關鍵動作人工覆核 - 在系統的 action policy 中定義：哪些操作必須人工核決（轉帳、删資料、改權限）- 建立 審批看板：AI 建議操作 → 管理者審核 → 批准/拒絕- 記錄審批過程到審計日誌
3.4 輸出白名單與格式驗證 - 對輸出內容做 白名單檢查：只允許特定命令、特定欄位、特定範圍數值- 使用 JSON Schema / OpenAPI spec 強制驗證輸出結構- 對不符合規則的輸出直接 reject，不進入後續流程

四、權限與身分管理

# 控制項目 說明 對照 OWASP 風險 優先級 負責角色
4.1 AI 系統身分與權限最小化 AI 的 API key、service account 權限只給必要範圍 LLM07, LLM08 高 IAM 工程師 / 資安主管
4.2 短暫憑證與定期輪替 使用短暫憑證，定期輪替 API key 與 secrets LLM07 中 DevOps / 資安工程師
4.3 多租户與部門隔離 多部門共用 AI 平台時，要有租户隔離與存取控制 LLM06, LLM08 高 架構師 / IAM 工程師
4.4 插件與工具存取控制 對 AI 可用的插件、工具、API 做細粒度權限控制 LLM07, LLM08 高 AI 工程師 / 資安工程師

方案：

控制項目 對應解決方案
4.1 AI 系統身分與權限最小化 - 使用 IAM 平台（Azure AD, Okta, AWS IAM）建立專門的 AI service account- 依 最小權限原則 授予只有必要 API 的權限- 用 RBAC / ABAC 做細粒度控制（例如：只能讀特定 collection）
4.2 短暫憑證與定期輪替 - 使用 短暫憑證機制（如 AWS STS, Azure AD Managed Identity）- 設定 自動輪替 policy（API key 每 30/60 天輪替）- 將 secrets 存入 Secrets Manager（AWS Secrets Manager, Azure Key Vault, HashiCorp Vault）
4.3 多租户與部門隔離 - 在 AI 平台層實作 多租户架構：每個部門/專案有獨立 tenant- 使用 tenant ID + RBAC 做資料與權限隔離- 避免跨租户 query 與資料洩漏
4.4 插件與工具存取控制 - 對每個插件/工具定義 權限 policy（讀/寫/執行）- 在 AI 调用插件前，先做 權限檢查 middleware- 使用 API Gateway + OAuth scopes 控制插件调用範圍