Agent 工具调用该怎么留痕？Shield KYA 的本地审计与云端策略边界
编码 Agent 能读文件、执行命令、调用 MCP 工具，效率提高的同时，也让“它刚才做了什么”成为实际的安全问题。Shield KYA（Know Your Agent）提供一套面向编码 Agent 的调用留痕和策略检查工具：本地记录工具活动，并可通过策略路径返回允许、待人工审核或拒绝的决策。它值得关注的不是“装上就能拦住一切”，而是把本地可见性与真正的策略执行拆开说明。
先分清观察与强制执行
项目 README 将 KYA 描述为 CLI 与本地 MCP gate。kya start 会初始化 .kya/、尝试为检测到的编码宿主接入 MCP，并打开本地活动报告。不同宿主加载配置的时机并不相同；有些需要重新启动或新建会话。不要仅凭命令成功退出，就认为每种 Agent 都已经接入。
更重要的是策略边界。README 明确说明，本地 hooks 采用 fail-open 设计；大多数 ALLOW 与 REQUIRE_APPROVE 决策会被记录后继续放行，真正的策略评估和人工审批通过 MCP 策略路径及托管 workspace/control plane 执行。默认 wrap 是 observe 模式；因此本地报告不是离线防火墙，“已安装 hook”也不等于危险操作必定等待人工批准。若团队要求强制审批，必须让调用经过对应的策略评估路径，并测试拒绝结果确实阻止了后续副作用。
安装后验证数据链路
项目在 npm 发布为 @shield-agent/kya，当前 registry 版本为 0.33.2，许可证为 MIT，要求 Node.js 22 或更高版本（24 为推荐版本）。官方 README 给出的安装方式是：
npm i -g @shield-agent/kya@latest && kya start
Linux 上如果全局 npm 目录权限不足，不要用 sudo；可直接用一次性运行方式：
npx @shield-agent/kya@latest start
在项目目录运行后，按宿主配置确认 MCP 是否被加载，并在活动报告中检查当前会话。README 指出不同宿主重新加载行为各异；先用无副作用的工具调用验证记录链路，再评估是否接入高风险工作流。修改 MCP 配置前也应备份，并检查工具是否只向预期位置写入配置。
策略测试应从可控样例开始。项目支持离线样例评估，可查看不同决策状态：
kya eval-tool --offline --tool-id org.sample.never.event --irreversible
此类离线演示用于理解规则结果，不代表生产环境已经具备云端策略执行。README 还列出 kya wrap 的退出码语义：ALLOW 为 0，REQUIRE_APPROVE 为 4，DENY 或未知为 1；但默认 observe 模式下，wrap 遇到待审批结果也会以 0 继续。需要将待审状态变成阻断时，文档提供 --hold 或 KYA_HOLD=1。把这一区别纳入测试，避免脚本把“需要人工处理”误当成允许继续。
建议的落地顺序
先在测试仓库启用记录，盘点哪些 Agent、会话和工具调用实际可见；再挑选删除文件、读取密钥等高风险动作，分别测试允许、拒绝和待审路径，并确认下游副作用没有发生；最后才将策略纳入团队流程。不要把“没有事件”直接解释为“没有风险”，它也可能意味着 Agent 未接入监控路径。
KYA 的价值在于提供调用轨迹和策略评估入口，而不是替团队自动完成威胁建模。尤其要评估本地 hook fail-open 的后果、托管控制面的依赖，以及哪些调用可能绕过 MCP gate。只有把观测覆盖率、审批行为和失败时的默认动作都验证清楚，审计记录才真正能支撑安全决策。