我厌倦了AI代理拥有“上帝模式”,所以我为Python构建了一个工具防火墙。
摘要
ToolRampart 是一个开源的 Python 框架,它为 AI 代理的工具调用添加了安全边界,具有 Pydantic 验证、审批流程、速率限制和审计日志等功能。
我一直在用AI代理和MCP工具开发,有个问题始终困扰我:我们给代理赋予真实能力的速度,远快于给它们设定安全边界的速度。所以我做了 **ToolRampart**,这是一个开源的 Python 框架,位于你的代理和 Python 函数之间。思路很简单:你的代理可以调用有用的工具,但每次调用都可以经过以下约束:
* Pydantic 输入验证
* actor 作用域
* 自定义策略检查
* 高风险操作的审批流程
* 幂等键用于重试
* 速率限制
* 超时/重试
* 可选的子进程隔离
* 输出验证
* 脱敏审计日志
* 可选的 OpenTelemetry
* MCP 兼容的工具暴露
说白了就是:**面向安全 AI 工具的 FastAPI。**
简单示例:
```python
from toolrampart import require_approval, scope, tool
@tool("billing.refund")
@require_approval(over_amount=500)
def refund_user(user_id: str, amount: float, reason: str) -> dict:
return {"status": "refund_started", "user_id": user_id}
```
然后运行:
```
toolrampart serve my_tools
```
目前是 alpha 阶段,所以我不会假装它是什么久经考验的企业级安全产品。我真正想要的是来自那些正在构建代理、MCP 服务器、内部工具、支持机器人、运维机器人,或者任何让 LLM 接触真实系统的人的真实反馈。
我想解决的问题是:**“LLM 想调用函数”和“函数实际运行”之间,应该存在什么?**
GitHub/文档链接在评论区。欢迎大家给出尖锐反馈,尤其是关于安全模型、API 设计以及下一步应该添加哪些集成方面的意见。
相似文章
我构建了一个兼容OpenAI的AI智能体防火墙。来试试攻破它。
Arc Gate 是一个兼容OpenAI的防火墙,可跨整个AI智能体会话跟踪权限,并在工具调用执行前从允许升级到阻止。它提供了在线演示,并在GitHub上开源。
我为本地AI智能体构建了一个默认拒绝防火墙(OpenClaw/Hermes)——它会拦截每一次工具调用,并在执行任何可能存在风险的操作前征求我的批准
一个针对本地AI智能体的默认拒绝防火墙守护进程,拦截每一次工具调用,阻止危险操作,并对模棱两可的操作请求用户批准,同时具备防篡改日志记录。旨在降低提示注入风险。基于MIT许可证开源。
一个用于测试AI代理行为的开源工具,适用于生产前阶段。
作者计划开源一个工具,用于测试AI代理在生产前的行为,支持OpenAI Agents SDK、PydanticAI和自定义Python代理,并寻求开发者的贡献和反馈。
我构建了一个治理层,让AI智能体可以构建自己的工具,但不能越过我设定的红线
作者构建了Arcforge,这是一个治理层,允许AI智能体生成并注册自己的工具(例如,通过OpenAPI创建支付工具),同时在智能体持有API密钥之前就强制执行策略限制(例如,阻止一笔9,999美元的收费)。这是一个早期原型,正在寻求关于护栏的反馈。
在你的智能体和不可逆的工具调用之间,究竟有什么?
这篇推文讨论了AI智能体中不可逆工具调用缺乏安全机制的问题,并介绍了OrcaRouter的新代理防火墙功能,该功能在执行前对工具/MCP调用进行评分,同时强调了独立评估的必要性。