一个政策文件，卡住三家AI工具的"手"

周三下午，你的AI助手同时收到了三条危险指令。

Claude Code想执行shell命令清空数据库。OpenAI Agents SDK准备给客户全额退款。Claude Desktop通过MCP连接，试图删除Postgres里的所有行。

三个不同的运行时，三种不同的拦截机制。但结果一样：全被拦住了。审计日志里只多了一行记录，时间戳精确到毫秒。

这是JamJet今天发布的Phase 2想要证明的事——安全层可以跨平台通用，不需要为每个AI工具重写一遍规则。

碎片化的现实

AI代理的安全控制正在变成一场各自为政的竞赛。Anthropic给Claude Code设计了hooks：PreToolUse、PostToolUse、Notification，子进程读JSON，决定工具调用是否放行。OpenAI在Agents SDK里推guardrails，Python和TS的callable，布尔值触发中止。MCP生态更热闹——MCPX、IBM ContextForge、微软MCP Gateway、Lasso Security的网关，都在解决同一个协议层问题。

每个设计在自己语境里都合理。但政策语言不通。

上个月接触的一个真实团队：Claude Code跑工程工作流，OpenAI Agents SDK支撑客户侧copilot，两个MCP server接进Cursor做数据库操作。安全审计只问了一个问题：这些代理能干什么？

诚实的答案是：翻一遍settings.json，读一个Python guardrail文件，查两份不同YAML方言的MCP网关配置，再看内部Confluence页上写的生产环境if语句。三条审计轨迹，三种格式。三套审批流——Slack bot、PagerDuty escalation、人工翻OpenAI trace viewer。

平台不是问题。hook API没问题，guardrail API没问题，MCP代理模式也没问题。问题是接缝——每个团队都在自己造轮子。

JamJet的解法

定位很直接：AI代理的动作控制平面。一个policy.yaml，一条审计轨迹，横跨hooks、guardrails、MCP网关、SDK和自定义运行时。

底层的可移植层只有两样：统一的policy.yaml schema，统一的audit JSONL schema。每个适配器读同一份YAML，写同一种JSONL。jamjet audit show按时间线串起所有记录。

今天发布的五个包覆盖了主流场景：@jamjet/claude-code-hook挂进PreToolUse钩子，@jamjet/openai-guardrail接入TS版guardrail，@jamjet/mcp-shim挡在MCP server前面。还有@jamjet/cloud@0.3和配套组件。

演示里的三条拦截记录，最终都指向同一个审计文件路径。这才是关键——不是拦住多少次，而是事后能一次性看清全部。