检查点管理本身不提供访问权限控制，需在恢复入口、存储读取、外部调用链路三层面实施权限防护：校验身份与scope、隔离加密检查点文件、阻断语义回滚并审计告警。

检查点管理本身不直接提供“访问权限控制”功能，它本质是状态快照的保存与加载机制。真正需要防范的是：谁能在什么条件下触发恢复操作、恢复到哪个检查点、以及恢复后能否重新执行已产生副作用的外部调用。因此，权限防护必须落在**检查点调用入口、恢复执行上下文、以及外部工具调用链路**三个层面。

限制检查点恢复的触发权限

不能让任意用户或任意代码路径随意调用 restore()。需将恢复操作封装为受控接口：

• 在应用层做身份校验：只有具备 debugger 或 admin 角色的用户会话才能发起恢复请求
• 禁用前端暴露的“回退按钮”在生产环境：开发/测试环境可保留，但生产环境应移除或灰度开关控制
• 若通过 API 触发恢复（如 /api/agent/restore?checkpoint_id=xxx），必须校验 JWT token 中的 scope 字段，例如 require scope="agent:rollback"

隔离检查点数据的存储与读取权限

检查点文件（如 JSON、Pickle、Protobuf）一旦被未授权读取，攻击者可能提取敏感上下文、伪造恢复请求，甚至反向推测业务逻辑：

Windows 日历同步

将提醒同步至 Windows/Outlook 日历。用户提及「提醒我」「设置提醒」「加到日历」「同步到日历」「日程」「calendar」「日历」时触发。支持Microsoft Graph API 设备代码流认证，无需 Web 服务器，直接写入用户 Outlook 日历。

下载

• 将检查点存于权限受限目录，例如 Linux 下设为 0600，属主为运行 Agent 的专用服务账户
• 避免使用共享存储（如 NFS、SMB 共享卷）存放检查点，除非该卷已配置细粒度 ACL 且仅限可信服务挂载
• 对检查点内容加密：使用运行时注入的密钥（如从 Azure Key Vault 获取）进行 AES-256 加密，密钥不硬编码、不落盘

阻断语义回滚攻击的关键防护（ACRFence 思路）

即使恢复成功，也必须防止 Agent “重放”已执行过的工具调用。这不是权限问题，而是语义一致性保障：

• 在首次调用外部服务前，将意图哈希（如 SHA256("transfer_500_to_bob_at_20261009T1422")）连同生成的 request_id 一起写入持久化日志（如 Event Hubs + 时间戳 + 签名）
• 恢复后，Agent 在构造新调用前，先查该意图哈希是否已在日志中标记为 completed；若是，则跳过执行，直接返回上次结果
• 对外部服务侧，要求其支持基于意图哈希的幂等性（而非仅依赖 request_id），或由网关层统一拦截重复哈希请求

审计与告警不可省略

每次检查点恢复都应视为高风险操作，必须留痕并通知：

• 记录恢复事件：谁、何时、从哪个 checkpoint_id、恢复到哪个 session_id、是否涉及外部调用重放
• 接入 SIEM 系统（如 Microsoft Sentinel），设置规则：1 小时内同一用户触发 ≥3 次恢复 → 触发 UEBA 异常告警
• 对生产环境的恢复操作，强制要求二次确认（如输入 OTP 或审批工单编号）