Nomos：为AI智能体构建零信任执行防火墙，保障生产环境安全-平芜编程栈

1. 项目概述：为AI智能体装上“执行防火墙”

如果你正在尝试将AI智能体（Agent）集成到你的业务或开发流程中，无论是让它帮你写代码、处理客户工单，还是自动化运维，一个无法回避的终极问题就是：我该如何信任它？你精心设计的提示词（Prompt）可能被注入攻击绕过，一个错误的工具调用可能导致数据库被清空、代码被强制推送，或者未经授权的退款被执行。这种对“失控”的恐惧，是阻碍AI智能体从演示走向生产环境的核心障碍。

今天要深入探讨的Nomos，正是为解决这一痛点而生。它不是一个限制AI思考的“笼子”，而是一个部署在智能体与实际执行动作之间的“执行防火墙”。你可以把它想象成你家网络的路由器防火墙：数据包（AI的请求）在离开内网（AI的推理过程）去往互联网（真实世界）之前，必须经过它的审查和裁决。Nomos的核心哲学是“零信任”—— 不信任任何来自智能体的请求，只信任基于明确策略的显式授权。

它的工作流程极其清晰：当你的AI智能体（无论是基于LangChain、AutoGPT还是任何框架）试图执行一个真实操作时，比如读取一个文件、调用一个API或者运行一条命令，这个请求会被路由到Nomos。Nomos会做三件事：验证身份、规范化动作、评估策略，然后给出一个明确的裁决：ALLOW（允许执行）、DENY（拒绝执行）或REQUIRE_APPROVAL（需要人工审批）。只有被允许的动作才会真正发生，并且其输出在返回给智能体前，还可能根据策略进行脱敏处理。整个过程会被完整审计。

最吸引人的是它的“与智能体及模型无关”特性。无论你底层用的是Claude、GPT-4，还是开源模型，无论你的智能体框架是什么，Nomos都能通过标准协议（如MCP、HTTP）接入，用同一套策略语言来管理所有动作。这意味着你可以建立一套统一、可审计的安全控制平面，而无需为每个智能体项目重复造轮子。

1.1 核心需求解析：为什么我们需要“执行边界”？

在深入Nomos的架构之前，我们必须先理解“执行边界”这个概念为何如此关键。AI智能体的工作流通常分为“思考”和“行动”两个阶段。在思考阶段，模型进行推理、规划；在行动阶段，它调用工具（Tools）来影响外部世界。传统安全方案往往聚焦于“思考”阶段，试图通过更复杂的提示词工程或模型微调来确保安全，但这本质上是“希望模型表现良好”，是一种软性约束。

执行边界的提出，是将安全防线从“希望”转移到“强制”。它承认一个现实：无论模型多么强大，提示词多么严谨，都无法百分百杜绝恶意注入、模型幻觉或意外错误。因此，最可靠的安全措施不是在模型内部，而是在它试图“伸手”改变现实的那一刻进行拦截和验证。

具体来说，一个未受管控的智能体可能带来的风险包括：

业务逻辑绕过：用户通过巧妙的提示词注入，让客服智能体批准本不该通过的退款或优惠。
破坏性操作：编码智能体在尝试修复bug时，错误执行了rm -rf /或terraform destroy -auto-approve。
数据泄露：智能体被诱导读取包含API密钥、数据库凭证的.env或配置文件。
权限滥用：智能体获得了过宽的权限（如完整的AWS密钥），可能被用于启动昂贵的计算资源或访问敏感数据。

Nomos的价值就在于，它将上述风险的应对，从“祈祷别发生”变成了“策略强制管控”。你不再需要给智能体完整的、长期的凭证，而是通过Nomos作为中介，按需申请短期令牌。你也不再需要相信模型的每一次输出，因为每一次真实动作都必须经过策略引擎的绿灯。

2. 架构深度解析：Nomos如何实现零信任管控

理解了“为什么”之后，我们来看“怎么做”。Nomos的架构设计充分体现了“关注点分离”和“强制管控”的思想。它不是一个大而全的智能体框架，而是一个专注、可插拔的安全层。其核心架构可以用一个简化的数据流来理解，但我们需要深入每个环节的细节。

2.1 核心工作流与组件拆解

当一个动作请求抵达Nomos时，它会经历以下标准化流程：

请求接收与协议适配：Nomos支持两种主要接入协议：MCP和HTTP。
- MCP模式：适用于原生支持MCP协议的客户端，如Claude Code、Cursor等。Nomos作为一个MCP服务器运行，向这些客户端暴露受管控的工具（如nomos_fs_read,nomos_exec）。客户端像调用普通MCP工具一样调用它们，但请求实际被Nomos拦截和处理。
- HTTP网关模式：适用于自定义的智能体运行时或后端服务。你的智能体代码通过HTTP API（POST /action）向Nomos提交动作请求。这种方式灵活性最高，可以集成到任何技术栈中。
身份验证与动作规范化：这是零信任的基石。Nomos绝不信任请求中自带的身份信息。它会根据配置的认证方式（如Bearer Token、HMAC签名）独立验证请求来源的真实性和权限。同时，它将来自不同协议、不同格式的原始请求（如“读取文件”、“git status”），规范化为内部统一的动作表示（如{"action": "fs.read", "resource": "file:///project/.env"}）。这确保了无论请求从何而来，都能用同一套策略进行评估。
策略评估引擎：规范化后的动作，连同已验证的身份、环境变量等信息，被送入策略引擎。策略以“捆绑包”的形式加载，通常用YAML或JSON编写。引擎采用“拒绝优先”的评估逻辑：只要有任何一条策略规则明确拒绝（DENY）该动作，无论其他规则是否允许，最终结果就是拒绝。这符合安全领域“默认拒绝”的最佳实践。策略可以非常精细，例如：
```
# 示例策略：禁止读取任何以 .env 结尾的文件 - action: "fs.read" resource: "file://**/.env" effect: "DENY" description: "Prevent reading environment files"
```
策略也可以定义复杂的条件，比如“只有在工作时间内，来自特定IP的请求，才能执行部署动作”。
裁决与执行：策略引擎返回裁决（ALLOW/DENY/REQUIRE_APPROVAL）。
- DENY：请求被立即拒绝，返回错误信息给智能体。审计日志会记录此次拒绝。
- REQUIRE_APPROVAL：动作被挂起，生成一个唯一的审批请求（与动作指纹绑定）。操作员可以通过Nomos的Operator UI或API来批准或拒绝。这为高风险操作提供了人工介入的缓冲带。
- ALLOW：动作被允许执行。Nomos会代表智能体，使用它自身持有的、受控的凭证（而非智能体持有的原始凭证）去执行该动作。例如，Nomos可能用一个仅有只读权限的服务账号去读取文件，或者用一个需要二次确认的令牌去执行部署。
输出处理与审计：动作执行后的原始输出，在返回给智能体之前，会经过脱敏处理。策略可以定义需要脱敏的模式，如信用卡号、API密钥等。同时，从请求接收到最终响应的全链路信息，包括动作详情、身份、策略决策、执行结果、脱敏记录等，都会被生成结构化的审计事件，发送到配置的日志或监控系统，满足合规与溯源需求。

2.2 部署模式与保证级别

Nomos非常务实地定义了不同的“保证级别”，这直接关联到你的部署方式。理解这一点对于正确评估其安全价值至关重要。

部署模式	保证级别	含义与适用场景
强控制运行时（如K8s集群、严格管控的CI/CD环境）	`STRONG`	Nomos被部署在智能体访问真实资源的唯一路径上。智能体无法绕过Nomos直接操作系统或网络。这是生产级部署，能真正强制执行安全边界。
部分加固的受控运行时（如受管理的开发容器、有基础隔离的服务器）	`GUARDED`	Nomos能够管控它接收到的所有请求路径，但运行时环境可能存在其他未被Nomos覆盖的访问通道（如智能体仍能通过其他方式执行Shell）。安全依赖于环境和操作纪律的补充。
本地或非受管环境（如开发者本地笔记本）	`BEST_EFFORT`	Nomos可以治理被路由到它这里的动作，但无法保证智能体不会通过其他方式（如直接调用本地命令）绕过它。适用于演示、开发测试和低风险场景。

核心洞见：Nomos的强大与否，不仅在于其软件本身，更在于它被集成到系统架构中的位置。要实现STRONG保证，你必须确保智能体运行时是一个“封闭系统”，所有对外部的访问都必须经过Nomos网关。这通常需要结合容器化、网络策略和权限隔离来实现。

3. 实战指南：从零开始部署与配置Nomos

理论讲完了，我们来点实际的。假设我们有一个用LangChain编写的客服智能体，它需要查询订单（允许），但处理退款时必须经过审批。我们将通过HTTP网关模式集成Nomos。

3.1 环境准备与安装

首先，根据你的操作系统安装Nomos。这里以macOS为例：

# 使用 Homebrew 安装（推荐） brew install safe-agentic-world/nomos/nomos # 验证安装 nomos --version

对于其他系统，可以选择从源码编译或使用安装脚本，项目README中提供了详细命令。

3.2 编写核心配置文件

Nomos的行为由配置文件驱动。我们创建一个基础的config.json：

{ "http": { "listen_addr": ":8080", "auth": { "bearer_tokens": { "my-agent-token": { "principal": "customer-service-agent", "capabilities": ["customer:read", "refund:request"] } } } }, "policy": { "bundles": ["./policies/customer-service.yaml"] }, "audit": { "log": { "level": "info", "format": "json" } }, "identity": { "verifier": "static", "static": { "my-agent-token": "customer-service-agent" } } }

http.listen_addr：Nomos HTTP服务监听的地址和端口。
auth.bearer_tokens：定义了一个Bearer Tokenmy-agent-token，关联到主体customer-service-agent，并声明了其能力范围。你的智能体代码需要在请求头中携带Authorization: Bearer my-agent-token。
policy.bundles：指定策略捆绑包文件的路径。
audit：配置审计日志以JSON格式输出到标准输出。

3.3 编写策略捆绑包

策略是Nomos的灵魂。创建policies/customer-service.yaml：

version: 1 policies: # 策略1：允许查询订单信息 - id: "allow-order-lookup" description: "Agents can look up order details" actions: ["order:lookup"] resources: ["order:*"] effect: "ALLOW" conditions: principal: "customer-service-agent" # 策略2：退款操作需要人工审批 - id: "require-approval-for-refund" description: "Refunds must be manually approved" actions: ["refund:create"] resources: ["refund:*"] effect: "REQUIRE_APPROVAL" conditions: principal: "customer-service-agent" obligations: # 审批请求需要包含以下上下文，方便审批人决策 - type: "approval" parameters: message: "Customer service agent requested a refund for order {{.action.resource.id}}" required_tags: ["approver:finance"] # 策略3：明确拒绝任何删除订单的尝试 - id: "deny-order-deletion" description: "Agents cannot delete orders under any circumstances" actions: ["order:delete"] resources: ["order:*"] effect: "DENY" # 策略4：默认拒绝所有未明确允许的动作（安全基线） - id: "default-deny" description: "Default deny all actions not explicitly allowed" actions: ["*"] resources: ["*"] effect: "DENY"

这个策略包体现了最小权限原则和纵深防御：

allow-order-lookup：明确允许了智能体的核心只读功能。
require-approval-for-refund：对关键写操作设置了审批关卡，obligations定义了审批时需要的信息。
deny-order-deletion：对高危操作进行了硬性封锁。
default-deny：最后一条兜底策略，确保任何未在之前策略中匹配到的动作都会被拒绝。这条策略至关重要，是构建安全基线的关键。

3.4 启动Nomos并集成智能体

启动Nomos服务：

nomos serve -c ./config.json

现在，在你的LangChain智能体代码中，你需要将原本直接调用工具（如直接调用退款API）的方式，改为通过Nomos HTTP网关来发起动作请求。

import requests import json class NomosGovernedTool: def __init__(self, nomos_base_url, bearer_token): self.nomos_url = f"{nomos_base_url}/action" self.headers = { "Authorization": f"Bearer {bearer_token}", "Content-Type": "application/json" } def execute_action(self, action_name, resource, parameters=None): """通过Nomos执行一个受管控的动作""" payload = { "action": action_name, "resource": resource, "parameters": parameters or {} } response = requests.post(self.nomos_url, json=payload, headers=self.headers) result = response.json() if response.status_code == 200: if result.get("decision") == "ALLOW": # 动作被允许，返回执行结果（可能已脱敏） return result.get("output", {}).get("result") elif result.get("decision") == "REQUIRE_APPROVAL": # 动作需要审批，返回审批ID和信息 approval_id = result.get("approval", {}).get("id") return f"Action requires approval. Approval ID: {approval_id}. Please check the operator UI." else: # 动作被拒绝 raise PermissionError(f"Action denied: {result.get('reason')}") else: # 处理其他错误（如网络问题、Nomos内部错误） raise Exception(f"Nomos request failed: {response.status_code}, {result}") # 在智能体工具中使用 nomos_tool = NomosGovernedTool("http://localhost:8080", "my-agent-token") # 尝试查询订单 - 应该被允许 try: order_info = nomos_tool.execute_action("order:lookup", "order:12345") print(f"Order info: {order_info}") except Exception as e: print(f"Failed: {e}") # 尝试创建退款 - 应该触发审批 try: refund_result = nomos_tool.execute_action("refund:create", "refund:order_12345", {"amount": 50.00}) print(f"Refund result: {refund_result}") # 这里会收到需要审批的提示 except PermissionError as e: print(f"Denied: {e}")

3.5 操作员审批与监控

当智能体触发了REQUIRE_APPROVAL的动作时，操作员可以通过Nomos自带的Operator UI（通常运行在http://localhost:8080/ui/）来查看和审批待处理请求。

在UI中，操作员可以看到：

待审批的动作列表，包括动作详情、请求者、时间戳。
策略要求的额外上下文（如我们策略中定义的message）。
操作员可以点击“批准”或“拒绝”。一旦批准，Nomos会继续执行该动作并将结果返回给智能体；如果拒绝，智能体会收到拒绝通知。

同时，所有决策（允许、拒绝、审批创建、审批决定）都会以结构化的审计日志形式输出，你可以将其接入到ELK、Datadog等监控系统，实现完整的可观测性。

4. 高级特性与定制化开发

掌握了基础部署后，Nomos的一些高级特性能让它在复杂场景下游刃有余。

4.1 自定义动作与执行器

Nomos内置了如fs.read、process.exec等通用动作。但在实际业务中，你更需要管控的是业务动作，如chargeCreditCard、updateInventory。Nomos支持定义自定义动作。

首先，在配置中定义动作模式和执行器：

{ "actions": { "definitions": { "payment:capture": { "description": "Capture a payment for an order", "executor": { "type": "http", "config": { "url": "{{.Env.INTERNAL_PAYMENT_API}}/capture", "method": "POST", "headers": { "X-Api-Key": "{{.Secrets.PAYMENT_API_KEY}}" } } } } } } }

然后，在策略中就可以像使用内置动作一样使用payment:capture。当策略允许该动作时，Nomos会代表智能体，向配置的内部支付API发起HTTP请求，并使用Nomos管理的密钥（而非智能体持有的密钥）。这完美实现了凭证中介和权限隔离。

4.2 策略测试与解释

在将策略部署到生产环境前，充分的测试是必须的。Nomos提供了强大的命令行工具：

# 测试单个动作是否会被策略允许/拒绝 nomos policy test \ --action '{"action": "fs.read", "resource": "file:///home/user/.ssh/id_rsa"}' \ --bundle ./policies/safe.yaml # 使用文件定义的动作进行测试 nomos policy test --action ./test-actions/read-secret.json --bundle ./policies/ # 解释一个动作的决策过程，了解是哪条策略起了作用 nomos policy explain \ --action '{"action": "refund:create", "resource": "refund:order_999"}' \ --bundle ./policies/customer-service.yaml \ --principal customer-service-agent

policy explain功能在调试复杂策略时尤其有用，它能清晰地展示策略匹配的路径和最终决策的原因。

4.3 多策略捆绑包与分层管理

对于大型组织，策略管理可能需要分层。例如，公司级基础安全策略、部门级业务策略、项目级特定策略。Nomos支持同时加载多个策略捆绑包，并按照配置的顺序进行合并评估。合并规则是确定性的，且遵循“拒绝优先”。这允许你模块化地管理策略，提高复用性和可维护性。

{ "policy": { "bundles": [ "/etc/nomos/policies/company-base.yaml", "/etc/nomos/policies/division-finance.yaml", "./local-project-policies.yaml" ] } }

5. 常见问题、排查技巧与避坑指南

在实际集成和使用Nomos的过程中，你肯定会遇到各种问题。以下是我从实战中总结的一些常见场景和解决方案。

5.1 连接与认证问题

问题：智能体调用Nomos API返回401 Unauthorized。

检查点1：Token配置：确认config.json中定义的Bearer Token与智能体代码中发送的完全一致（包括大小写和任何特殊字符）。
检查点2：请求头格式：确保HTTP请求头是Authorization: Bearer <your-token-here>，注意Bearer后面有一个空格。
检查点3：Nomos服务日志：运行Nomos时添加--log-level debug参数，查看详细的认证日志。

问题：MCP客户端（如Claude Code）无法连接到Nomos服务器。

检查点1：传输方式：确认MCP服务器启动命令正确。对于stdio传输，确保命令能在子进程中正确运行。
检查点2：客户端配置：检查Claude Code或Codex的MCP配置JSON文件，确保transport、command和args字段指向正确的Nomos可执行文件和配置文件路径。
检查点3：环境变量：某些MCP客户端需要特定的环境变量才能发现本地服务器。查阅客户端文档。

5.2 策略决策不符合预期

问题：认为应该允许的动作被拒绝了，或者应该拒绝的动作被允许了。

首要工具：nomos policy explain：这是你最好的朋友。用它来对特定的动作、主体、资源组合进行决策推演，它会列出所有匹配的策略及其效果，让你一眼看出是哪条策略“搞的鬼”。
检查点：默认拒绝策略：确保你的策略包中包含一条兜底的default-deny策略。有时动作被意外允许，恰恰是因为没有匹配到任何策略，而某些配置下空匹配可能默认为允许（这取决于策略引擎的默认行为，Nomos通常要求显式定义）。
检查点：资源匹配模式：仔细检查策略中的resources模式。file:///home/*和file:///home/**是有区别的（前者匹配单层目录，后者匹配任意深层目录）。使用nomos policy test用具体的资源字符串进行测试。
检查点：条件（Conditions）：如果策略中包含conditions（如time_between: ["09:00", "17:00"]），请确认当前上下文（如系统时间、请求中的环境属性）满足这些条件。

5.3 性能与运维考量

问题：引入Nomos后，智能体动作的延迟明显增加。

优化点1：策略复杂度：评估策略的数量和复杂度。过于复杂的正则表达式或大量的策略规则会增加评估时间。尽量保持策略简洁，并使用nomos policy test进行性能基准测试。
优化点2：执行器延迟：如果自定义HTTP执行器调用的下游服务本身很慢，那么整体延迟就会高。考虑对下游服务进行优化或增加超时设置。
优化点3：部署拓扑：将Nomos部署在离智能体运行时和下游服务都尽可能近的网络位置，减少网络往返时间。在K8s中，可以考虑将Nomos作为Sidecar容器与智能体Pod部署在一起。

问题：审计日志量巨大，如何管理？

方案1：分级日志：在配置中设置audit.log.level。在生产环境，可能只需要warn和error级别的审计事件，以及所有的DENY和APPROVAL决策。
方案2：外部日志聚合：不要只依赖标准输出。配置Nomos将审计事件发送到外部系统，如OpenTelemetry Collector、Fluentd或云服务商的日志服务（如CloudWatch Logs、Google Cloud Logging）。这些系统擅长处理海量日志，并提供强大的查询和归档功能。
方案3：采样：对于极高吞吐量的ALLOW决策（如大量的只读文件查询），可以考虑在审计配置中启用采样，只记录一部分。

5.4 安全加固实践

从BEST_EFFORT到STRONG保证的升级路径：

容器化智能体运行时：将你的智能体应用和Nomos一起打包进Docker镜像。确保智能体进程只能通过localhost与Nomos通信。
移除智能体的直接凭证：在智能体运行环境中，不要配置任何可以直接访问业务数据库、云服务API的长期凭证。所有对外访问都应通过Nomos网关，由Nomos使用其独立管理的、权限最小化的凭证来执行。
使用网络策略：在K8s中，使用NetworkPolicy确保智能体Pod只能与Nomos Pod通信，而Nomos Pod只能与特定的、必要的下游服务通信。
定期轮换Nomos凭证：Nomos自身使用的服务账号凭证应定期自动轮换，并确保智能体对此毫无感知。
启用完整的审计与告警：将所有审计日志集中管理，并设置告警规则，例如：短时间内出现大量DENY决策、出现特定的高危动作尝试、审批超时等。

一个关键的避坑点：不要将Nomos的配置文件（尤其是包含令牌、密钥的配置）提交到源码仓库。使用环境变量或密钥管理服务（如HashiCorp Vault、AWS Secrets Manager）来注入敏感配置。Nomos的配置文件支持Go模板语法，可以方便地引用环境变量，如{{.Env.NOMOS_API_KEY}}。

5.5 与现有生态的集成权衡

“为什么不用OPA（Open Policy Agent）？”这是一个好问题。OPA是一个通用的策略引擎，非常强大。Nomos在策略评估上确实可能使用了类似OPA的引擎或理念。但Nomos的价值在于它提供了一个“开箱即用”的、针对AI智能体执行边界的安全产品。它集成了身份验证、动作规范化、凭证中介、审批工作流、审计和Operator UI。如果你从零开始用OPA构建这些，需要大量的集成和开发工作。Nomos让你能快速获得一个完整的解决方案。

“和Vault的角色冲突吗？”不冲突，而是互补。Vault是秘密管理的专家，用于安全地生成、存储和轮换凭证。Nomos可以作为Vault的客户端，在执行动作时动态地从Vault获取短期凭证，用完后立即丢弃。这样实现了双重安全：秘密由Vault管理，执行由Nomos管控。

集成Nomos到你的技术栈中，本质上是为你的AI应用增加了一个可编程的、可观测的“安全肌键”。它不会限制AI的创造力，而是为它的行动套上了可靠的缰绳。从一个小型的、非关键的业务流程开始试点，逐步建立对这套管控机制的信任，再将其推广到更核心的场景，这是我推荐的上手路径。