software

为 LLM 实现 sudo：AI 安全的中间件方法

发布: (2026年2月1日 GMT+8 06:35)
5 分钟阅读
原文: Dev.to

Source: Dev.to

“写入访问”焦虑

我们都在急于构建 Agents——能够使用工具的 AI，而不仅仅是聊天。但当我给我的 LangChain 代理提供了 stripe_api_key 时，我感到胃里打结。

本质上，我们正在让一个概率模型（LLM）对我们的银行账户和云基础设施拥有确定性的访问权。如果 LLM 幻想出一个循环，或被提示注入攻击，我的数据库就会消失。

我意识到 “礼貌地请求 LLM”（系统提示）并不是安全策略。你不会通过让用户“请友好一点”来保护 Linux 服务器。你会使用权限控制。你会使用 sudo。

于是，我在过去几周里构建了一个 Governance Layer 用于 AI Agents。下面是对该架构以及构建 “Human‑in‑the‑Loop” 中间件时所面临挑战的深度剖析。

架构：“中间人”

核心问题在于，一旦 Agent 启动工具调用，开发者通常会失去控制。执行是同步且不透明的。

我需要一个代理——一个位于 Agent 与 关键资源 之间的中间件。

我称之为 SudoMode。它基于一个简单的 拦截与验证 循环工作：

  • 拦截： SDK 包装危险函数（例如 stripe.charge）。
  • 评估： 本地策略引擎检查 policies.yaml。
  • 暂停： 如果操作被标记为 “高风险”，Python 线程会 sleep。
  • 轮询： SDK 每 2 秒向治理服务器轮询。
  • 恢复： 一旦有人通过仪表盘批准请求，服务器返回授权令牌，脚本即可继续运行。

代码：策略即配置

我不想把规则硬编码进 Python 代码里。希望它们是声明式的，类似 Kubernetes 清单或 OPA（Open Policy Agent）。

下面是一个策略的示例。它是简单的 YAML，定义了代理的“冲击半径”：

rules:
  # Rule 1: Hard Block (The Firewall)
  - id: "protect-production-db"
    resource: "postgres"
    action: "drop_table"
    response: "DENY"

  # Rule 2: Conditional Approval (The Sudo Command)
  - id: "spending-limit"
    resource: "stripe"
    action: "charge"
    condition: "args.amount > 50"
    response: "REQUIRE_APPROVAL"

“等待”机制（工程挑战）

最棘手的工程难题是处理异步/同步不匹配。

大多数 Agent 框架（CrewAI、LangChain）都期望工具能够立即返回值。它们原生并不善于处理“等待人工”。如果抛出错误，Agent 会崩溃或尝试通过幻觉“修复”错误。

为了解决这个问题，我在客户端 SDK 中实现了一个 长轮询 循环。与其抛出异常，客户端会进入 while True 循环，模拟慢速网络请求。

def execute(self, resource, action, args):
    # 1. Initial Check
    decision = self.check(resource, action, args)

    # 2. The Waiting Game
    if decision['status'] == 'REQUIRE_APPROVAL':
        # Log to stdout so the developer sees the pause
        logger.info(f"Paused. Waiting for Admin (ID: {decision['request_id']})...")

        while True:
            time.sleep(2)

            # POLL THE SERVER
            status = self._get_request_status(decision['request_id'])

            if status == "APPROVED":
                return True
            elif status == "REJECTED":
                raise PermissionError("Request Denied by Admin.")

对 Agent 来说，这看起来就像 API 响应慢了一会儿。对人类来说，则像是仪表盘上的一个“待处理请求”。

为什么开源？

我之所以构建它，是因为我自己需要，但我意识到每个开发 Agents 的人都在重复造轮子。我们都在用奇怪的 input() 循环来检查我们的代理。

我开源了 SudoMode，希望它能成为一个标准、即插即用的安全网。它并不完美——只是一个 MVP——但它有效地将智能（LLM）与控制（策略）分离。

我目前正在征求对架构的反馈，特别是关于如果代理在等待时崩溃，如何处理分布式状态的问题。

如果你正在构建 Agents 并为安全问题而失眠，欢迎查看仓库。我很想了解这种架构是否适合你的使用场景。

GitHub 仓库：

Back to Blog

相关文章

阅读更多 »