AI 智能体身份权限审计：关联执行身份、审批与实际结果

先看一份能追溯动作的示例记录

AI 智能体身份权限审计，要让复核者能回答：是谁提出请求，哪个身份实际行动，凭什么访问，批准了哪一步，以及目标最终发生了什么。只留下“AI 已处理”或一段聊天回复，无法把这些问题串起来。

以下是建议的手工记录模板与假设示例，不是任何产品导出的真实日志：团队成员李女士请企业智能体读取指定的项目周会纪要，并准备一段回复文字；资料负责人王女士只批准这次读取，不批准发送。

同一请求可以有多个动作，状态也可能不同。读取已成功而回复尚未生成，就不能把整个任务写成成功；回复文字出现在会话中，也不能写成已发给收件人。给每一步保留动作编号，是一种手工关联方法，不代表业务系统必然提供相同字段。

凭据引用只帮助复核者定位使用了哪条连接。API 密钥认证模型或服务请求，不会自动提供执行者生命周期、资源授权和审批治理。保留对象与结果的必要引用即可，不必为审计复制整份文件、完整消息或秘密凭据。

复核记录还应注明谁核对了结果、依据在哪里。记录编号是检索线索，不是完成证明。企业需要更完整的部署与权限要求，可参考企业 AI 代理安全：为什么手机代理更需要本地优先、权限和审计。

为企业智能体选择身份与权限范围

在 Microsoft Entra 场景中，智能体身份授权说明区分委托权限与应用权限。前者让智能体代表特定用户访问资源，受该用户及获授范围约束；后者以应用自身身份访问，由管理员授予相应权限。这里描述的是 Entra 的授权方式，不应套用成所有智能体的统一机制。

Azure 资源角色、目录角色和 Microsoft Graph 权限控制的资源不同。先确定要访问的是哪个资源，再判断需要什么权限，不因为智能体承担多个任务就直接使用广泛管理员身份。Entra 对智能体身份的高权限角色和 API 权限也有相应限制，应按官方规则核对。

例如，只需读取指定资料并起草文字，就核对该资料的读取范围，不为方便授予修改全部文档或发送消息的权限。提出任务的人、持有访问权的执行身份，以及批准敏感动作的人可能是三方。一次 OAuth 授权说明某种访问范围获准，并不表示以后每一封邮件都可以直接发出。

任务从“读取并起草”变成“修改文件并发送”时，增加了新的资源、目标和外部后果。应更新授权范围与动作记录，并确认新的审批要求，而不是沿用先前读取审批。若审批只覆盖一个文件，执行目标改成另一份资料，也需要重新核对。

组织还应明确身份或连接的负责人、用途，以及自身策略要求的期限和复查方式。没有负责人或用途已结束的授权，应进入复查，而不是长期保留。工具或技能已经启用，也不等于运行时访问任何内容都合理；相关区别可阅读AI Agent 技能安全：为什么手机 Agent 不能只靠安装前扫描。

分别收集身份记录和动作结果

Microsoft 的Entra 智能体登录与审计记录说明介绍了用于关联身份的 agentType 和 blueprintId。蓝图活动作为应用事件出现，智能体身份活动作为服务主体事件出现，智能体用户账号活动作为用户事件出现。至少具备“报告读取者”角色的人员，可在 Entra ID 的“监视与运行状况”→“登录日志”中使用智能体筛选条件。

这些记录有助于回答“哪个身份登录或发生了身份管理活动”，却不能单独证明“某份文档已修改”或“消息已发给正确的人”。还要从实际业务应用取得操作、目标和结果的证据，再用请求编号、执行身份、目标资源和时间等可用标识关联。

以 R-024 为例，先定位对应身份及时间范围，再查指定纪要的读取结果，以及回复建议实际出现的位置。若系统有可用于关联的请求标识，就保留它；没有时，记录手工关联依据和不确定之处。两个事件时间接近，不足以单独证明它们属于同一动作。

应分开保存三类证据：身份或登录记录、具体动作的尝试或响应、目标中的实际结果。登录成功只说明身份访问的一环成立；工具返回成功，也应结合目标核验。下游证据缺失时，把状态写成“结果未确认”，不为了完成记录而补成成功。

若使用 Microsoft Graph 查询相关智能体日志，官方描述的查询路径属于 /beta，应按该接口的实际适用条件评估。登录审计并不保证包含每项业务操作，也不能单凭这类记录认定日志不可篡改、保留期限已满足要求或组织已经合规。

由组织确定记录的访问人、保留期限和敏感内容最小化方式。长期记忆中的错误信息还可能影响后续目标选择；如果动作指向了不该访问的资源，也要查目标从哪里来，相关核查可参考AI 智能体记忆投毒指南：Ask AI 按钮、推荐偏置与手机恢复。

记录成功、拒绝、待审批和部分失败

以下四份假设记录展示不同状态的写法。它们沿用身份、凭据引用、范围、审批和结果字段，但不把“有授权”“已批准”“已尝试”与“已完成”合并成一个成功标签。

只读成功：结果与范围对应

请求 R-025 要求读取指定文档的一段内容。记录执行身份、受限连接和读取范围，并注明适用策略允许该次读取；动作确已发起，返回了对应段落，复核者核对了文件与段落引用。结果可记为“指定读取成功”，但不延伸成“整个资料库已检查”或“回复已发送”。若只是生成建议文字，单独记录它所在的位置。

写入待审批：尚未执行

请求 R-026 准备在指定目标创建一项记录。内容与范围已明确，实际策略要求审批，但尚未取得决定。记录写入目标和待批内容，审批状态为“待审批”，尝试状态为“尚未执行”。这不是工具故障，也不应自动重试。若批准后参数或目标发生变化，应重新确认审批是否覆盖新动作。

动作被拒绝：同时核对目标

请求 R-027 的写入被审批人拒绝，或被相应权限控制阻止。记录实际拒绝来源，不把权限不足写成人工拒绝。随后核对目标，若检查范围内没有预期新增或修改，可记录“动作被拒绝，目标核对未发现该变化”，并注明核对时间与依据。只有拒绝提示、未查目标时，则保留这项核验缺口。

部分失败或结果不明：暂停重复写入

请求 R-028 包含创建记录和后续通知两步。若目标记录已经存在，而通知失败，应分别记为创建已核对、通知未完成，不重新执行整个请求。若写入提交后超时，目标是否变化尚不清楚，就记为“已尝试，写入结果未确认”。先查目标及动作证据，再决定补做哪一步，不能把超时当成没有执行。

这些区别也决定恢复方式：待审批等待决定，拒绝处理授权或停止，部分完成只处理剩余步骤，未知写入先核对。一个请求可以保留多个状态，不需要为了简化报表而抹掉未完成或未知结果。

把同样的问题用在手机任务上

在 FoneClaw 中，可以把五个问题用于一次简单的安卓任务。比如用户要求“查看当前电量和省电状态”：记下请求人、所选模型配置的引用、设备状态读取能力是否启用、适用审批设置，以及工具实际返回了什么。device_battery_status 只读取状态，不改变手机设置。

我们的工具信息标明风险与默认审批，实际行为由工具审批模式及逐工具覆盖设置共同决定。只读工具的默认自动处理，不代表所有工具无需审批；某次没有提示，也不应在记录中虚构一名审批人。可以注明“按当时策略自动允许”，并与人工批准区分。

如果任务改成创建日历事项，后果就不同了。一个建议示例是：“在已确认的日期下午三点到四点创建项目讨论，提前十分钟提醒。”创建前应把日期、起止时间、时区、目标日历和提醒选择确认清楚；缺失信息先补问，不从模糊表达中猜测。

calendar_create_event 属于产生外部影响的写入工具，默认要求审批，仍需核对实际全局及逐工具策略。创建后使用返回的 actualStart 和 actualEnd 记录实际时间，并到目标日历检查事项、提醒和归属。模型说“已安排”或审批通过，都不能替代这一步；实际时间与意图不一致时，先处理现有事项，不直接再建一条。

安卓系统权限、FoneClaw 工具启用状态和模型提供方凭据是不同控制。API 凭据不能授予日历权限，启用工具也不能替代系统授权。模型服务可能处理提供给它的上下文，手机动作在本地发生并不代表全部信息留在本机。相关能力见FoneClaw 功能介绍。

这里的记录是用户自行复核任务的方法，并非 FoneClaw 原生不可变审计导出，也不代表与 Entra 的身份集成。模型对话、工具响应和目标应用各提供不同线索，记录时应保留其来源与限制。

撤销访问后，核对剩余状态

可以用一项无害的只读任务检查控制是否生效：在自己环境中，暂时停用电量读取工具，再明确请求调用该能力。预期是该工具不执行，任务说明能力不可用；若模型仍给出电量数值，应核对它是否来自旧上下文或其他来源，不能把一段数字当成新的工具结果。这是建议验证步骤，不是本文声称已完成的测试。

手工记录本次停用项、请求、实际响应和是否发生工具调用。测试后按需要恢复能力，再核对真正返回的状态。不要用高影响写入验证拒绝行为，也不要为了通过测试而给所有工具扩大权限。

工作结束后，按所属系统的管理流程撤销不再需要的连接、身份授权或工具能力，复查全局策略和逐工具覆盖是否仍适合任务。凭据暴露时应按所属服务流程轮换，并处理旧凭据的访问范围；仅从笔记中删除密钥，不等于服务端访问已撤销。

撤销未来访问与撤回已完成动作是两件事。关闭日历工具不会删除已经创建的事项，撤销业务连接也不会自动撤回已发消息。对可能已执行的写入，先到目标应用核对；需要修改或撤销时，把它作为另一个明确动作处理，并留下结果。

最后检查三项：闲置访问是否已按预期撤销，目标中有哪些已经发生的变化，以及哪些结果仍未确认。记录的读者和保留范围按自身策略管理；保留足以复核的引用，不积累无关敏感内容。只有身份、授权、尝试与后果都能对应，后续人员才知道该恢复哪一步，而不是重新运行整个任务。