{ "schemaVersion": 1, "version": "2026-09-15", "id": "https://hk.onyxdevslab.com/data/ai-agent-permission-audit-checklist.json", "name": "AI agent permission and audit checklist", "datePublished": "2026-09-15", "dateModified": "2026-09-15", "evidenceClass": "Provider-authored implementation checklist", "publisher": { "name": "Onyx Devs Lab", "legalName": "ONYX DEVS LAB LIMITED", "url": "https://hk.onyxdevslab.com/", "leiCode": "254900Z30CLK7HKE9H46" }, "landingPages": { "en": "https://hk.onyxdevslab.com/en/guides/ai-agent-permission-audit-checklist/", "zhHant": "https://hk.onyxdevslab.com/zh-hk/guides/ai-agent-permission-audit-checklist/", "zhHans": "https://hk.onyxdevslab.com/zh-cn/guides/ai-agent-permission-audit-checklist/" }, "languages": { "en": { "name": "What permissions and audit records does an enterprise AI agent need?", "summary": "Treat an agent as an actor with bounded authority, not as a chatbot with API keys. Every tool action should resolve to a tenant, user or service identity, allowed operation, evidence record, and safe recovery path.", "decisionSignals": [ { "name": "Authority tiers", "meaning": "Read, recommend, draft, approve, execute" }, { "name": "Least privilege", "meaning": "Identity, tenant, object, and action scope" }, { "name": "Action evidence", "meaning": "Intent, arguments, result, and recovery" } ], "sections": [ { "heading": "Design the authority model before tools", "introduction": "A single “agent access” permission is too coarse for production.", "checks": [ { "name": "Separate authority tiers", "requirement": "Define read, recommend, draft, approve, and execute independently; promotion to a higher tier requires explicit evidence and ownership." }, { "name": "Map real identities", "requirement": "Resolve the requesting user, tenant, service account, source session, and target-system identity; never rely only on a shared model credential." }, { "name": "Constrain every tool", "requirement": "Allow specific systems, objects, fields, actions, amounts, time windows, and environments; deny everything else by default." } ] }, { "heading": "Make every consequential action reconstructable", "introduction": "The audit record should explain what the system attempted and what actually happened.", "checks": [ { "name": "Intent and evidence", "requirement": "Record the user request, applicable policy, retrieved evidence, model and prompt version, decision, and human confirmation where required." }, { "name": "Execution result", "requirement": "Record tool name, validated arguments, target identity, idempotency key, timestamp, response, resulting state, and verification readback." }, { "name": "Operating controls", "requirement": "Provide revoke and kill paths, separation of duties, exception queues, retries, compensating actions, alerting, incident review, and retention rules." } ] } ], "procedure": [ { "position": 1, "name": "Inventory tools and actions", "instruction": "List every system the agent can reach and classify each operation by data sensitivity, reversibility, financial effect, and user consequence." }, { "position": 2, "name": "Map identities and policy", "instruction": "Connect users, tenants, roles, service accounts, approval thresholds, and target-system permissions to enforceable rules." }, { "position": 3, "name": "Test forbidden and failure cases", "instruction": "Attempt cross-tenant access, missing confirmation, duplicate execution, stale state, partial failure, timeout, revocation, and recovery." }, { "position": 4, "name": "Release authority gradually", "instruction": "Start with read or recommendation, measure exceptions, and promote only the actions whose evidence and recovery controls pass the agreed gates." } ], "frequentlyAskedQuestions": [ { "question": "Are application logs enough?", "answer": "Usually not. Generic logs may omit the requesting identity, policy decision, validated arguments, confirmation, resulting state, and recovery evidence needed to reconstruct an action." }, { "question": "Can an agent use one service account?", "answer": "Only if downstream authorisation still preserves tenant and user policy, action limits, and attribution. A shared credential must not erase who requested or approved the action." }, { "question": "Which actions require human approval?", "answer": "At minimum, irreversible, external, regulated, high-value, or privilege-changing actions should use explicit confirmation unless a documented risk decision approves a narrower automated envelope." }, { "question": "Is this a complete security standard?", "answer": "No. This provider-authored engineering checklist complements, but does not replace, the organisation’s security architecture, threat model, legal duties, and incident procedures." } ] }, "zhHant": { "name": "企業 AI Agent 需要哪些權限及審計記錄？", "summary": "把 Agent 視為具有限權限的行動者，而非一個持有 API Key 的聊天機械人。每次工具動作都應對應租戶、使用者或服務身份、允許操作、證據記錄及安全恢復路徑。", "decisionSignals": [ { "name": "權限層級", "meaning": "讀取、建議、草擬、批准、執行" }, { "name": "最小權限", "meaning": "身份、租戶、對象及動作範圍" }, { "name": "動作證據", "meaning": "意圖、參數、結果及恢復" } ], "sections": [ { "heading": "先設計權限模型，再連接工具", "introduction": "單一「Agent 存取」權限對生產環境過於粗疏。", "checks": [ { "name": "分開權限層級", "requirement": "獨立定義讀取、建議、草擬、批准及執行；提升至更高層級需要明確證據與負責人。" }, { "name": "映射真實身份", "requirement": "解析請求人、租戶、服務帳戶、來源會話及目標系統身份；不可只依賴共用模型憑證。" }, { "name": "限制每項工具", "requirement": "只允許指定系統、對象、欄位、動作、金額、時間及環境，其餘預設拒絕。" } ] }, { "heading": "讓每項高影響動作可以重建", "introduction": "審計記錄應說明系統嘗試甚麼，以及實際發生甚麼。", "checks": [ { "name": "意圖及證據", "requirement": "記錄使用者要求、適用政策、檢索證據、模型與提示詞版本、決定，以及需要時的人工確認。" }, { "name": "執行結果", "requirement": "記錄工具、已驗證參數、目標身份、冪等鍵、時間、回應、最終狀態及回讀驗證。" }, { "name": "營運控制", "requirement": "提供撤銷與停止路徑、職責分離、例外隊列、重試、補償動作、警報、事故覆核及保留規則。" } ] } ], "procedure": [ { "position": 1, "name": "盤點工具及動作", "instruction": "列出 Agent 可接觸的每個系統，按數據敏感度、可逆性、財務影響及使用者後果分類操作。" }, { "position": 2, "name": "映射身份及政策", "instruction": "把使用者、租戶、角色、服務帳戶、批准門檻及目標系統權限連接至可執行規則。" }, { "position": 3, "name": "測試禁止及失敗案例", "instruction": "嘗試跨租戶存取、缺少確認、重複執行、過期狀態、部分失敗、逾時、撤銷及恢復。" }, { "position": 4, "name": "逐步釋放權限", "instruction": "先由讀取或建議開始，量度例外；只有證據與恢復控制通過約定關口的動作才提升權限。" } ], "frequentlyAskedQuestions": [ { "question": "應用程式日誌是否足夠？", "answer": "通常不足。一般日誌可能缺少請求身份、政策決定、已驗證參數、確認、最終狀態及恢復證據。" }, { "question": "Agent 可以共用一個服務帳戶嗎？", "answer": "只有在下游授權仍保留租戶與使用者政策、動作限制及歸因時才可以；共用憑證不可抹去誰提出或批准動作。" }, { "question": "哪些動作需要人工批准？", "answer": "至少不可逆、對外、受監管、高價值或改變權限的動作應明確確認，除非具文件的風險決定批准更窄的自動執行範圍。" }, { "question": "這是完整安全標準嗎？", "answer": "不是。這份服務商自撰工程清單只作補充，不能取代機構的安全架構、威脅模型、法律責任及事故程序。" } ] }, "zhHans": { "name": "企业 AI Agent 需要哪些权限和审计记录？", "summary": "把 Agent 看成权限受限的行动者，而不是一个持有 API Key 的聊天机器人。每次工具动作都应该对应租户、用户或服务身份、允许操作、证据记录和安全恢复路径。", "decisionSignals": [ { "name": "权限层级", "meaning": "读取、建议、草拟、批准、执行" }, { "name": "最小权限", "meaning": "身份、租户、对象和动作范围" }, { "name": "动作证据", "meaning": "意图、参数、结果和恢复" } ], "sections": [ { "heading": "先设计权限模型，再连接工具", "introduction": "单一“Agent 访问”权限对于生产环境过于粗糙。", "checks": [ { "name": "分开权限层级", "requirement": "独立定义读取、建议、草拟、批准和执行；提升到更高层级需要明确证据和负责人。" }, { "name": "映射真实身份", "requirement": "解析请求人、租户、服务账号、来源会话和目标系统身份；不能只依赖共享模型凭证。" }, { "name": "限制每项工具", "requirement": "只允许指定系统、对象、字段、动作、金额、时间和环境，其余默认拒绝。" } ] }, { "heading": "让每项高影响动作可以重建", "introduction": "审计记录应该说明系统尝试了什么，以及实际发生了什么。", "checks": [ { "name": "意图与证据", "requirement": "记录用户要求、适用政策、检索证据、模型与提示词版本、决定，以及需要时的人工确认。" }, { "name": "执行结果", "requirement": "记录工具、已经验证的参数、目标身份、幂等键、时间、响应、最终状态和回读验证。" }, { "name": "运营控制", "requirement": "提供撤销与停止路径、职责分离、异常队列、重试、补偿动作、告警、事故复核和保留规则。" } ] } ], "procedure": [ { "position": 1, "name": "盘点工具与动作", "instruction": "列出 Agent 可以访问的每个系统，按照数据敏感度、可逆性、财务影响和用户后果分类操作。" }, { "position": 2, "name": "映射身份与政策", "instruction": "把用户、租户、角色、服务账号、批准门槛和目标系统权限连接到可以执行的规则。" }, { "position": 3, "name": "测试禁止与失败案例", "instruction": "尝试跨租户访问、缺少确认、重复执行、过期状态、部分失败、超时、撤销和恢复。" }, { "position": 4, "name": "逐步释放权限", "instruction": "先从读取或建议开始，测量异常；只有证据与恢复控制通过约定关口的动作才提升权限。" } ], "frequentlyAskedQuestions": [ { "question": "应用程序日志是否足够？", "answer": "通常不够。一般日志可能缺少请求身份、政策决定、已经验证的参数、确认、最终状态和恢复证据。" }, { "question": "Agent 可以共用一个服务账号吗？", "answer": "只有在下游授权仍保留租户与用户政策、动作限制和归因时才可以；共享凭证不能抹去谁提出或批准动作。" }, { "question": "哪些动作需要人工批准？", "answer": "至少不可逆、对外、受监管、高价值或改变权限的动作应该明确确认，除非有文档的风险决定批准更窄的自动执行范围。" }, { "question": "这是完整安全标准吗？", "answer": "不是。这份服务商自编工程清单只作补充，不能取代组织的安全架构、威胁模型、法律责任和事故程序。" } ] } }, "limitations": [ "This asset is provider-authored and is not independent validation or a claim of client results.", "It is an implementation aid, not legal, privacy, security, financial, procurement, or regulatory advice.", "Thresholds and controls must be adapted to the organisation, workflow, jurisdiction, and risk owners." ] }