Cynative：把云、代码和运行时串起来问的只读安全研究 agent
云安全排查最麻烦的地方，往往不是单个扫描器不会报警，而是线索散在太多层。
一个 GitHub Actions workflow 通过 OIDC 假设了某个 AWS role，这个 role 又能改 IAM policy；Terraform 里看起来是只读，实际运行中的 Kubernetes RBAC 却多开了一条权限；某个泄露的 cloud credential 是否还能用、影响半径有多大，也不能只靠搜索代码下结论。传统做法是把 GitHub、IaC、云账号、Kubernetes、runtime logs 分开查，再靠人把证据拼起来。
今天想记下的 cynative/cynative，切的是这个问题。它不是通用聊天式 coding agent，而是一个面向 infrastructure security research 的本地 CLI：用你本机已有的云和代码平台凭据，只读地查询 GitHub、GitLab、AWS、GCP、Azure 和 Kubernetes，再让模型在沙箱里生成查询代码、并行拉证据、交叉验证发现。
按 GitHub repository API、repository page、README、Releases、Tags、commit history 和 LICENSE 在 2026-07-16 能核验的公开信息，cynative/cynative 当前有 116 stars、21 forks。仓库主语言是 Go，许可证是 Apache-2.0。仓库创建于 2026-06-24 18:06:26 UTC，最近公开 push 是 2026-07-16 09:23:47 UTC。默认分支 main 的最新提交是 3f66e87，提交时间 2026-07-16 12:23:18 +0300。最新 GitHub release 是 v1.5.1，发布时间 2026-07-10 18:43:25 UTC。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | cynative/cynative |
| 定位 | 本地运行的只读 infrastructure security research agent |
| Stars | 116 |
| Forks | 21 |
| 主语言 | Go |
| 许可证 | Apache-2.0 |
| 仓库创建时间 | 2026-06-24 18:06:26 UTC |
| 最近 push | 2026-07-16 09:23:47 UTC |
| 最新 main 提交 | 3f66e87，2026-07-16 12:23:18 +0300 |
| Latest GitHub release | v1.5.1，2026-07-10 18:43:25 UTC |
| 连接对象 | GitHub、GitLab、AWS、GCP、Azure、Kubernetes |
| 关键词 | cloud security、read-only agent、sandbox、evidence verification、CLI |
它解决的是跨层证据问题
Cynative 的 README 用几个问题来说明目标：哪些 IAM role 可以提权到 admin，哪些高风险 cloud permissions 能追溯到引入它的 PR，源码里泄露的 cloud credentials 当前 blast radius 是什么，运行中的 cloud resources 是否偏离 IaC。
这些问题有个共同点：答案不在单个系统里。你需要读代码托管平台、CI 配置、云 API、Kubernetes RBAC、IaC 文件和当前 runtime 状态。一个普通 scanner 可以给你一批 findings，但它很难解释“这个权限是哪里来的、现在能做什么、证据链是否闭合”。
Cynative 的思路是让 agent 不只是读文本，而是围绕一个安全问题生成调查代码，在受控沙箱里并发查询多个 API，再把发现交给 verifier 交叉检查。对安全团队来说，重点不是“模型说它觉得危险”，而是“每个结论能不能回到具体证据”。
只读不是提示词承诺
这个项目最值得看的地方，是它把只读边界放进实现里，而不是只写在系统提示词里。
README 里强调每次调用都会先经过 action gate：操作会被解析到需要的 IAM actions，再对照只读策略授权。AWS 默认用 SecurityAudit，GCP 用 roles/viewer，Azure 用 Reader；Kubernetes 会读取集群当前的 view RBAC role 并按请求检查。对 AWS assumed-role 身份，它还会通过 STS 重新发放被只读 managed policy 限制过的凭据。
这和“给一个 coding agent 接几个 MCP server”有本质差异。MCP server 当然可以自己做权限控制，但如果只是把生产凭据放在 agent shell 里，再靠 prompt 要求它别写入，边界就很薄。Cynative 的设计目标是 fail closed：分类不清、授权不通过、日志写不下来的情况，都应该阻止继续执行。
沙箱是为了跑调查代码
安全排查经常不是一个 API 调用能完成的。比如要枚举所有 GitHub Actions workflow，再找 OIDC role，再查 AWS IAM policy，再对比实际可达权限。如果一轮一轮让 agent 调工具，不仅慢，也很耗上下文。
Cynative 选择让模型写一段调查代码，然后在 ephemeral sandbox 里运行。这个沙箱没有 host access，网络也会被限制到映射过的服务和 region。README 里把它和普通 coding agent + MCP 的差异说得很清楚：后者通常是一 action 一 tool call，Cynative 则让沙箱代码并发 fan out 查询，再把结果压回给 verifier。
这个方向对 infrastructure security 很自然。安全人员本来就经常写一次性脚本查云账号、CI 配置和权限图；Cynative 只是把“写脚本、跑脚本、整理证据、校验发现”这条链路封成一个 agent workflow。
本地运行，但仍然需要凭据纪律
Cynative 通过 embedded Bifrost SDK 接模型，README 列了 OpenAI、Anthropic、Azure OpenAI、Amazon Bedrock、Google Vertex/Gemini、Cohere、Mistral、Groq、Ollama、vLLM 等 provider。工具本身在本地运行，不维护自己的 credential store，而是读取你 shell 里已经存在的凭据。
这点一方面降低了接入成本：你不需要再把云账号导入某个 SaaS。另一方面也要求使用者更自律。README 明确建议只提供任务所需的 least-privileged、read-only credential。即便工具有 action gate 和 STS scope，也不应该把高权限长期凭据随手暴露给任何自动化流程。
它还提供 approvals、--auto-approve、token/iteration/concurrency ceiling、fail-closed JSONL audit log、secret redaction 等控制项。这些细节说明作者知道安全 agent 的难点不只是“能查”，还包括“查的时候怎么限制成本、权限、网络和审计面”。
适合什么场景
第一类场景，是云权限和 CI/OIDC 风险排查。比如想知道某个 GitHub workflow 最终能碰到哪些 AWS/GCP/Azure 权限，或者某个 cloud role 是哪次 PR 引入的。
第二类场景，是 IaC 与 runtime drift。Terraform、Kubernetes manifest、实际云资源和运行中 RBAC 往往会慢慢偏离，单看 repo 很容易漏掉真实状态。
第三类场景，是安全 incident 的快速取证。泄露 credential 是否仍有效、能访问哪些资源、是否能提权，这些问题需要跨代码和云 API 拉证据。
第四类场景，是小团队想在本地跑 AI-assisted security research，但还不想把基础设施元数据交给第三方平台。
需要注意的地方
第一，项目非常年轻。仓库创建于 2026-06-24，虽然 release 已经到 v1.5.1，最近 push 也很活跃，但真实生产环境里应先从只读、低风险账号开始试。
第二，只读边界不能替代云侧最小权限。Cynative 做了 action gate 和 credential scoping，但如果你给它的基础身份本身过宽，仍然要认真检查日志、网络范围和 provider 配置。
第三，模型输出仍然需要人工判断。它强调 evidence-backed 和 verifier，但安全结论进入修复或 incident response 流程前，最好由熟悉环境的人复核。
第四，连接面越多，配置越复杂。GitHub、GitLab、AWS、GCP、Azure、Kubernetes 每一层都有自己的权限模型；工具能统一入口，不代表组织内部的权限治理可以省掉。
总结
Cynative 有意思的地方，是它没有把 AI 安全工具做成“再包一层聊天 UI”。它更像一个本地研究台：把代码平台、云账号和 Kubernetes runtime 放在同一个只读调查边界里，让 agent 写脚本查证据，再把 findings 交叉验证。
如果你只需要常规 SAST 或 IaC scanner，它不是替代品。但如果你经常要回答“这个权限从哪来、现在能影响什么、证据链在哪”这类跨层问题，cynative/cynative 值得观察。小众归小众，它切到的是安全工程里很真实的一块摩擦。