agentshield 用关系图追踪 Agent 权限漂移

给 AI Agent 配好沙箱、收紧出站网络，只能说明部署时边界成立。后来有人放宽了 NetworkPolicy、换了 ServiceAccount，或者让流量走向新的目标，原来的隔离结论还算不算数？Solo.io 的 agentshield 盯的就是这些变化。

它把资源、身份、策略和流量放进同一张图，用规则发现新路径，再让人审核修复方案。值得程序员借鉴的是模型在这条链路里的位置：检测不必经过模型，模型参与时也要拿证据。不过，原文对默认行为和实测范围存在矛盾，需要分开看。

配好沙箱之后，为什么还要持续检查边界

据原文介绍，Solo.io 于 2026-10-22 发布 agentshield，采用 Apache-2.0 许可。作者此前讨论过默认拒绝出站、移除隐式可用的凭据、保留审计日志，以及通过 agentgateway 配置边界。新工具补的是后续变化的监控。

问题不只出在 Agent 自己。部署时临时放宽的网络策略忘了恢复，工作负载获得了新身份，Istio waypoint 开始转发到陌生目标，都可能让原先不存在的路径出现。

agentshield 从五类来源构建关系图：Kubernetes、Istio、Cilium、agentgateway 和 AWS。Kubernetes 侧涵盖工作负载、RBAC、NetworkPolicies、准入配置等，每种资源类型共用一个 informer；AWS 侧覆盖 EC2、ENI 和 Security Groups，还可通过 EventBridge、SQS 接收 CloudTrail 变更事件。

这张图不只是资产清单。它要连接「谁运行、用什么身份、受哪些策略约束、能去哪里」，帮助定位新路径由哪次变化产生。

图数据存入 Postgres，以带版本的贡献记录原子替换，并提供有序变更流。每条事实还记录来源插件、规则和观测记录。后面无论是规则报警还是模型调查，都有出处可查。

实际流量也会进入图：Istio waypoint 访问日志通过 OTLP/HTTP 接入，AWS VPC Flow Logs 通过 Firehose 接入；原始事件落到 JSONL 或 ClickHouse，每分钟汇总为 communicates-with 关系。

但接入有具体门槛。Istio 需要自定义 envoyOtelAls 扩展提供者，输出 agentshield.* 属性；示例还把所有调用方标成 Deployment，其他工作负载类型的流量在调整配置前会被拒绝。能读取资源，不代表已经正确识别了所有流量。

为什么检测规则要走在模型前面

agentshield 最值得借鉴的设计，是让确定性检测独立于模型运行。

内置检测器关注新增暴露、治理约束丢失、策略变化、新 RBAC 绑定，以及工作负载访问此前没去过的目标。它还会排除常规发布和扩缩容，减少日常变更造成的噪声。用户可以补充 CEL 规则，规则支持激活审计和热重载。

下面这条规则用于识别尚未分类的公网目标，作者称已对照项目测试夹具确认其形式：

Expression: "destination_ip_class == 'public' && destination_role == ''"

要看的是 destination_role == ''：公网地址本身不足以触发这条规则，还要满足目标角色尚未归类。原文说，这类发现标为中风险，原因标签是 new_public_destination。

destination_ip_class 也不是原始 IP。作者检查事件 schema 后指出，该字段只暴露粗粒度地址类别。这样可以减少这个检测字段携带的信息，但不能据此推断整套日志都不保存地址，因为原文没有给出那样的保证。

模型通过两个默认关闭的参数启用：

• --agentic-investigation：通过六个只读 MCP 图查询工具调查新路径、新暴露等信号，可以把信号提升为发现。它使用独立的采样队列，模型慢或失败不会拖住检测。
• --deployment-rule-authoring：经过基线观测窗口后，为每个 Kubernetes Deployment 的每次 Pod 模板修订草拟规则。规则先进入影子模式，经人批准才启用。

影子模式可以理解为先观察规则会命中什么，暂不把草稿直接投入正式检测。

原文还描述了模型发现的证据门槛：引用必须来自图实际返回的事实和证据，至少包含一个中风险或更高风险信号；底层资源变化后，相关发现立即失效。它限制了模型凭空下结论的空间，但证据可追溯仍不等于判断一定正确。

修复先预演，试用也要分清演示和验证

发现问题后，agentshield 可以提出 Kubernetes NetworkPolicy、CiliumNetworkPolicy 或 Istio STRICT PeerAuthentication 修复方案。人先准备变更，生成计划并向真实准入控制器执行 dry-run，再明确批准，工具随后验证结果。

dry-run 能检查变更是否会被接纳，不能证明业务一定不受影响。插件会声明支持的操作，影响范围阈值也参与执行约束。按原文描述，工具不会自行发起封堵。

README 给出的最快体验入口是：

make demo

要留意的是 demo：原文称它会执行 ui/pnpm install，启动 Vite 开发服务器，连接浏览器里的模拟后端。访问 http://127.0.0.1:5173 后，可以选择场景、触发观测、准备和批准修复，再重置环境。这个过程不需要 Go 二进制、数据库、集群或模型，适合看懂交互流程。

它不能证明真实集群的采集和修复已经跑通。

原文开头声称演示仓库和全部命令发布前都运行过，后面却明确说本次会话因沙箱限制，没有运行构建和开发服务器。作者明确列出的验证，是克隆仓库，阅读 pkg/detector/ 中的检测器、事件 schema、CEL 编译代码和测试夹具。因此，规则形式有源码核对依据，演示运行情况则存在自相矛盾的叙述。

我的判断

我认可它把检测、调查和执行分开的方向。相比让模型判断每一次变更，规则更容易复查；相比人工逐份重读 NetworkPolicy，关系图和变更流更适合追踪跨资源影响。

但原文没有给出误报率、漏报率、规模测试或运维成本对照。所谓更有纪律，首先是架构判断，还不是效果结论。排除扩缩容能否准确、基线窗口如何选择，都需要验证。

另一个矛盾直接影响试用：前文说激活规则命中会直接形成发现，FAQ 也重复了这一点；中间却说两个模型参数都不开，就没有任何发现和修复提案。这两种描述无法直接兼容。不能据此断言默认启动就能获得完整告警，也不能断言关闭模型必然失去规则检测。

项目仍是 pre-1.0，API、数据库 schema 和参数预期会发生破坏性变化。Web UI 与 HTTP API 默认没有认证，只绑定 loopback。直接把管理入口暴露出去，会改变它原先依赖的访问边界。

对只维护前端页面、没有集群治理需求的团队，它暂时不够贴近。对已经运行 Kubernetes 和相关网络组件的团队，它才有更明确的评估价值。

能拿来做什么

• 如果团队在 Kubernetes 中运行 Agent 服务，可以先选测试环境，验证一次策略放宽或 ServiceAccount 变化能否被采集、关联并解释清楚，同时核对关闭模型时是否仍有规则发现。
• 如果只是想理解操作流程，可以用 make demo 体验从发现到批准的过程，把模拟演示结果与真实集群验证分别记录。
• 如果正在开发 AI 运维助手，可以参考它的职责划分：规则负责稳定条件判断，模型通过只读工具调查，结论附带证据，执行另设审核入口。
• 如果准备试用管理界面，应先维持 loopback 访问范围；需要远程访问时，先解决认证和访问控制，再考虑扩大使用范围。