agentshield-dev/agentshield

面向 Kubernetes 平台与安全工程师的 pre-1.0 工具：用变更驱动的证据回答“谁能访问谁”。如果你在用 Istio ambient、Cilium 或 agentgateway，并能接受无认证的本地 UI、尚无公开准确率结果、单进程部署，值得试。

解决什么问题

现在要弄清“谁能访问谁”，得同时翻 NetworkPolicy、CiliumNetworkPolicy、Istio 的 AuthorizationPolicy 与 PeerAuthentication、Gateway API 路由和 AWS 安全组，而且每次配置变动后都要重来一遍。用户真正想要的是：一次看似普通的配置改动，是否打开了之前不存在的路径，以及依据是什么。agentshield 改的就是这一步：插件监听这些来源，把各自的完整输出写入 PostgreSQL，形成当前图和有序变更流，检测器再把图上的变化变成信号。最终得到的是可浏览的图加发现项，而不是手工比对几种策略语言。

有什么不同

核心机制是把发现和变更合在一起：源插件（kubernetes、aws）监听云与集群 API，语义插件（istio、cilium、agentgateway）读取同样的监听并补充含义，每个插件把当前完整输出作为贡献写入 PostgreSQL。OTLP 日志、VPC Flow Logs 等遥测先进入原始存储（JSONL 或 ClickHouse），再按分钟汇总接入图。检测本身从不调用模型；只有可选的智能体调查和 Deployment 规则编写会调用，且必须显式开启。模型调查通过只读图工具工作，按 README 的说法，只有引用真实图证据的回答才会成为发现项。发现项可以提出修复，但只有人准备并批准后才执行。

代价是集中：每个数据库只运行一个进程，没有高可用，项目也明说 1.0 之前 API、schema 和参数都会破坏性变更。README 还写明目前没有公开的效果结果，现有依据是评测套件：六轮 campaign，在带 Cilium、Istio ambient 和 agentgateway 的一次性 kind 集群上运行，分为三组攻击/正常对照。

谁值得试

适合已经在用 Istio ambient、Cilium 或 agentgateway、可能还跑在 AWS 上的平台或安全工程师，想先在本地得到可达性图和变更信号，再决定是否扩大范围。不适合现在就需要带认证、高可用生产服务的人：HTTP API 和 UI 没有认证，服务默认绑定 127.0.0.1:8088，README 要求改之前先读安全模型，而且只支持单进程配单数据库。想增加插件、检测器或评测场景的贡献者也是文档列出的目标人群。如果只是想看 UI，交互式 playground 用浏览器内的假后端运行，只需 make 加 Node.js 和 pnpm，不需要 Go、数据库、集群或模型，评估不必先有集群。

使用条件与边界

快速上手需要 Go 1.27+、带 Compose v2 的 Docker（用于 PostgreSQL 16 和 kind）、kind 与 kubectl 或当前上下文里任意 Kubernetes 1.30+ 集群，构建 UI 还需 Node.js 和 pnpm 11（可用 UI=0 跳过）。发现过程只读，但 make run 会用你的 kubectl 凭据启用实时修复，因此 README 建议只想查看时使用只读上下文。目前没有发布容器镜像：二进制来自 GitHub 的 tag 发布，容器镜像需自行用 Dockerfile 构建，再用 Helm chart 部署。可选的智能体调查需要 OpenAI Responses 兼容端点并开启相应参数。真正的持续成本是维护：要预期 API、schema 和参数发生破坏性变更，并围绕单实例数据库做规划。

HotRepo 点评

HotRepo 首次记录时仓库只有 3 天，2026-10-25 在新项目榜（不是总榜或日榜）以 50 个总 star 排第 22；只有两个记录日期、缺少可比日榜历史，无法判断热度能否持续。对一个 pre-1.0 项目，投入前最该确认的是默认绑定 localhost 背后的安全模型。