作者：元宝
专栏：元宝说 AI 安全
凌晨两点，客服 Agent 自动关闭了一批工单。研发打开对话记录，只看到一句：“已根据规则完成处理。”
但这句话回答不了真正重要的问题：它读了哪些数据？调用了哪个工具？使用的是谁的身份？中间有没有收到外部指令？如果同一条链路经过了多个 Agent，聊天窗口更不可能还原完整过程。
这也是很多 AI 应用上线后才暴露的盲区：模型回答可见，不等于 Agent 行为可追踪。
一个新标准，试图补上这块空白
2026 年 9 月 1 日，OWASP GenAI Security Project 公开了 Agent Control Standard（ACS）。项目把企业信任 Agent 所需的能力概括为三个词：可检查、可追踪、可插入控制。
换成工程语言，就是要知道 Agent 由什么组成、能访问什么、刚刚做了什么、为什么做；还要能在运行过程中挂上策略，对动作进行允许、拒绝或调整。
ACS 目前是公开预览项目，不是买来就能替换现有网关的产品。它提供的是一套开放规范，描述 Agent 平台如何暴露中间件钩子，以及安全策略如何通过这些钩子在运行时生效。项目路线还包括用 OpenTelemetry、OCSF 做事件追踪，以及用 Agent BOM（AgBOM）记录动态组件清单。
为什么“有日志”仍然不够
传统应用的日志通常围绕接口请求：谁调用了哪个 API，返回了什么状态码。Agent 场景多了一层“决策过程”：模型先读上下文，再选择工具，工具可能继续调用其他服务，最后由另一个 Agent 汇总结果。
如果只记最终回答，下面这些关键证据就会消失：
- 原始任务来自哪个用户，是否被文档或邮件中的指令改写；
- Agent 当时使用了哪个模型、工具版本和身份；
- 参数在模型输出、策略校验和工具执行之间有没有变化；
- 哪一步被允许、哪一步被拒绝，拒绝理由是什么。
我更愿意把 Agent 事件看成一张“动作账本”，而不是一段聊天记录。最小记录可以长这样：
{
"task_id": "t-20260904-001",
"actor": "agent-support",
"user": "u-2048",
"action": "close_ticket",
"resource": "ticket-7781",
"policy": "ticket.close.v2",
"decision": "deny",
"reason": "缺少人工确认"
}
示例中的字段不是 ACS 的完整格式，只是说明一个原则：审计对象应该是“谁在什么策略下对什么资源做了什么决定”，而不是“模型说了一段什么话”。
普通团队可以先做哪三件事
第一，把读和写分开记录。查询知识库、读取邮件和修改工单，不要共用一个模糊的 run_agent 事件。动作类型越具体，后续越容易限权和告警。
第二，给每次工具调用补上因果链。至少能从一次写操作反查到用户任务、模型请求、策略判断和外部回执。否则发生误操作时，只能靠猜。
第三，把策略放在运行时，而不是只写在系统提示词里。比如“外部收件人禁止发送”“高风险工单必须人工确认”“跨租户查询直接拒绝”，这些规则应由确定性的中间层执行，模型只能提出动作。
这三步不要求立刻采用某个标准，也不依赖更大的模型。它们解决的是最基本的可见性和控制问题。
ACS 值得关注，但别把它当成万能答案
标准化的好处，是不同 Agent 框架有机会用相近的方式输出事件、接收策略。企业不必为每个框架重新写一套监控和拦截逻辑。
但“能观测”不等于“已经安全”。如果底层工具仍然给 Agent 长期凭证，或者策略服务只记录不拦截，接入标准也只是把问题看得更清楚。看清问题很重要，但最终还要把拒绝、降级、人工确认和紧急停用真正接到执行链上。
我会把 ACS 当作一张接口设计提醒：在 Agent 上线前，先确认三件事——能不能看见它的组成，能不能还原它的动作，能不能在动作发生前改变结果。
如果只能先补一项，你会优先建设 Agent 行为追踪，还是先做运行时策略拦截？欢迎留下你现在使用的框架和最难审计的一步动作。
