开源项目推荐｜Open Policy Agent：给 AI 工具调用加上策略防线

当 Agent 开始行动，权限不能继续写在 Prompt 里

一个只回答问题的模型，主要风险是内容错误；一个可以读数据库、发邮件、改订单或调用 MCP 工具的 Agent，则可能把错误变成真实动作。很多团队会在系统提示词里写“不要访问敏感数据”“付款前先确认”，但提示词属于模型上下文，无法替代服务端强制执行的授权规则。

Open Policy Agent（OPA）是开源通用策略引擎。应用把用户、资源、动作与环境等上下文作为结构化输入，OPA 根据 Rego 策略返回决策。业务代码继续负责身份认证和实际执行，策略引擎专注回答“当前请求是否允许、还需要什么条件”，从而把权限逻辑从分散的 if 判断中抽离出来。

官方仓库：https://github.com/open-policy-agent/opa

AI 工具权限为什么适合策略即代码

模型选择工具只是建议，最终调用仍要经过确定性决策。策略输入可以包含租户、用户角色、工具名、动作类型、目标资源、数据级别、金额、当前环境和是否已人工批准。例如同一个客户查询工具，客服可以读取所属租户的数据，却不能跨租户导出；订单修改超过阈值时，即使模型参数格式正确，也必须转人工审批。

策略应默认拒绝，并把读取、生成草稿、提交、删除和付款拆成不同动作。不要用一个笼统的 admin 标志覆盖所有能力。OPA 返回 allow 之外，还可以由应用约定原因、限制条件或审批要求；真正执行前，服务仍要校验参数、幂等键和资源状态。

策略发布也需要测试、版本和回滚

权限策略会像代码一样出错。每条关键规则都应有允许与拒绝样本，覆盖缺失字段、跨租户、异常金额和角色冲突。策略与业务数据可通过 bundle 分发，版本号要随决策记录保留；先在测试环境回放历史请求，再灰度到少量流量，发现误放行或大面积误拒绝时能够回滚。

OPA 支持通过 REST API、SDK 或其他集成方式求值。部署位置要按延迟、可用性和隔离要求选择，但调用失败时不应自动放行。高风险路径可以让独立模型审阅 Agent 的计划与证据，最终是否执行仍由 OPA 规则和人工授权决定。

决策日志要可审计，也要避免二次泄露

OPA 的 decision logs 可以记录查询、输入、bundle 元数据和 decision_id，便于离线排查某次调用为什么被允许或拒绝。日志中可能包含个人信息、工具参数和业务对象，因此应在上报前脱敏，限制访问与保留时间，并把 decision_id 与 AnyAIS 请求日志、MCP 调用记录关联起来。

AnyAIS 负责统一模型、MCP、API Key、服务权限、配额与调用轨迹，OPA 负责更细的业务策略，两层结合可以同时回答“谁能访问哪个 AI 服务”和“这次具体动作是否符合业务规则”。先从一个只读工具和一组拒绝测试开始，再逐步开放写操作，通常比一次设计完整权限体系更容易验证。

适合哪些团队

当 Agent 已经连接内部系统、不同租户需要不同权限，或安全规则散落在多个服务中时，OPA 值得评估。如果应用只有简单角色且没有真实副作用，先把服务端校验做好即可；策略引擎的价值来自跨服务一致性和可审计决策，而不是增加一层技术名词。

参考资料：

• OPA 官方集成指南：https://www.openpolicyagent.org/docs/integration
• OPA REST API：https://www.openpolicyagent.org/docs/rest-api
• OPA Bundles：https://www.openpolicyagent.org/docs/management-bundles
• OPA Decision Logs：https://www.openpolicyagent.org/docs/management-decision-logs