Cynative 安全代理框架
以只读方式接入你的云与代码环境，用一个 Markdown 文件编写安全代理，自动审计权限提升、公网暴露和凭据泄露。
证据显示三层只读强制（网络主机钉扎、IAM action gate、AWS STS 限定 SecurityAudit 策略），least_privilege 满分；扣分点：user_confirmation 仅 2，因 --auto-approve 可完全跳过审批；rollback 仅 1，仓库只说明卸载方式，未说明误操作或异常运行的恢复语义（只读设计部分缓解但未明确）；source_attribution 仅 2，审计日志记录 agent 文件摘要，但发布者身份未经核实。
failure_messages 满分：文档明确列出退出码 0/1/2/130/143 语义、fail-closed 行为与中止原因提示；依赖可用性仅 2：有 `cynative doctor` 探测连接器就绪，但未执行验证；自一致性 2：README 与 workflow/测试文件描述相互吻合，但均属静态声明。
audience_and_scenarios 满分：快速上手、首个 agent、CI/无人值守、多 provider 示例面向清晰；capability_boundaries 与 trigger_precision 各 2：文档说明了 `--agent` 与 `-p` 的组合语义及 agent 命名遮蔽规则，但未说明 agent 触发误判边界；environment_fit 2：覆盖多平台与多种安装渠道，Windows 细节在折叠区且注明残留限制。
information_architecture、install_notes、examples_and_faq、license 均满分：文档结构完整、安装渠道含签名/校验/更新/卸载、有对比表与示例、LICENSE 全文存在；known_limitations 2：披露了 cosign 网络信任根、GitHub secret 端点封锁等限制，但未集中成 limitation 清单；versioning_changelog 2：有发布/校验和/Sigstore 体系，未见独立 changelog 文件；maintenance_responsibility 2：SECURITY.md 给出 3 天确认/90 天披露承诺，但团队规模与响应历史无证据。
marginal_value 满分：与 coding agent + MCP 的对比表明确给出差异化价值（并发沙箱、验证器、fail-closed 审计）；output_usability 2：stdout/stderr 分离、footer 与 exit code 设计合理但未经执行验证；cost_benefit 2：提供 token/迭代/并发上限旋钮，但实际成本数据缺失。
claim_traceability 2：审计日志含 agent 名称、来源与文件摘要，安装链有 checksums + Sigstore + GitHub attestation 三重校验；cross_source_corroboration 2：channel-smoke 与 attestation workflow、archive/unit 测试脚本与 README 声明互相印证，但属静态阅读，未运行；fact_inference_separation 2：多数声明标注来源与限制（如 attestation 异步延迟），少数营销性断言未区分。
- 发布者未经核实：二进制为主发布渠道，建议在可信环境使用 Sigstore/cosign 与 gh release verify 校验后再运行。
- --auto-approve 会跳过逐次审批；在无人值守场景务必设置 max_total_tokens、max_iterations 等上限。
- 审计日志对审批提示参数按原文记录，可能含敏感值；注意其文件权限与保留策略。
- GitHub/GitLab 连接器在配置 permissions 后可允许写操作，生产环境应保持默认只读。
- 本评审为静态源码审查（低置信度），所有运行时声明（权限执行、红action、成本）未经执行验证。
这个 Agent 能做什么，适合哪些场景？
Cynative 是一个开源（Apache-2.0）的安全代理框架，以单个 Go 静态二进制发布，通过 Homebrew、安装脚本或 Scoop 安装。它以你 Shell 中已有的凭据连接 AWS、GCP、Azure、Kubernetes（EKS/GKE/AKS 及自建）、GitHub 和 GitLab，将整个基础设施当作一个系统来推理。它在临时沙箱中生成并运行 JavaScript 代码，通过 http_request 等异步工具并发调用你的 API，再由内置验证器交叉核实每一条发现。所有调用在附加凭据之前都经过 Action Gate 按 SecurityAudit、roles/viewer、Reader 等只读策略授权，并在网络层将请求主机锁定到映射的服务与区域，属于构造上的只读设计。代理本身就是一个 Markdown 文件，放在 ~/.cynative/agents/ 目录即可运行，每次工具调用都会写入 fail-closed 的 JSONL 审计日志。它通过内嵌的 Bifrost SDK 支持 OpenAI、Anthropic、Bedrock、Vertex、Ollama 等几乎所有主流模型供应商，可完全在你的环境内运行。
安装后通过 cynative "问题" 或 cynative -p "任务" 发起查询，例如 "哪些 IAM 角色可以提升为 admin？"。代理读取 Shell 中已有的云凭据，在沙箱中编写并运行 JavaScript（借助 mapConcurrent 并发遍历 API 分页），查询 AWS/GCP/Azure/K8s/GitHub/GitLab 的实时状态。每个操作先被解析为所需 IAM 动作并对照只读策略（AWS SecurityAudit、GCP roles/viewer、Azure Reader、K8s 运行时获取的 view RBAC）授权，AWS 还通过 STS AssumeRole 重新签发受限于 SecurityAudit 的会话凭据。findings. 之类的结果可经管道回 cynative -p 做分诊；代理可用 --agent 指定 Markdown 定义的代理（如内置 aws-public-data-stores）。审计日志默认写入 ~/.cynative/audit.log，记录代理名称、来源与文件摘要，工具输出中的机密在发送给模型前会被脱敏。
- 安全工程师在 AWS 生产环境排查哪些 IAM 角色可以提权到 admin，并追踪到授予该权限的具体 PR。
- DevSecOps 团队审计 CI 与云之间的权限提升链路，例如 GitHub/GitLab 凭据在云端的爆炸半径。
- 产品安全团队在 GitLab MR 或发布流程中用 --auto-approve 以脚本方式定期扫描公网暴露的 S3、RDS 快照与 EBS 快照。
- 云架构师核查与 IaC 不一致的真实云资源漂移，使用交互式会话追问细节。
- 受管于主权或合规要求的团队在自己的 VPC 内运行 Cynative，通过 Bedrock 或 Vertex 推理，确保数据不出环境。
- 漏洞运营人员将扫描器输出的 findings. 管道传入 cynative -p 按可利用性分诊。
这个 Agent 有哪些优点和局限？
- 构造上的只读：Action Gate 在附加凭据前解析每个调用所需的 IAM 动作并按 SecurityAudit/roles/viewer/Reader 策略授权，写入类调用默认失败关闭，比 MCP 的可选读过滤更严格。
- AWS 侧通过 STS AssumeRole 重新签发受 SecurityAudit 约束的会话凭据，云平台自身也强制只读边界。
- 沙箱中并发执行生成的代码做批量调研，比逐次工具调用更省 token、更快，只有 console.log 的摘要返回给模型。
- 每个发现由验证器对照实时证据交叉核实，且审计日志记录代理名称、来源与文件摘要，可追溯到确切提示词。
- 支持几乎所有主流 LLM 供应商（含本地 Ollama），单二进制可在被审计的云内运行，数据不出环境。
- 需要用户自行准备目标云/平台的凭据并承担配置责任，README 明确要求最小权限只读凭据，误用高权限凭据有风险。
- 写入 ~/.cynative/audit.log 的内容虽然脱敏工具结果，但审批提示参数按原文保存，日志可能包含敏感值，权限与保留策略需要自行管理。
- 代理编写依赖用户理解各云 API 与 IAM 概念，Markdown 代理的能力上限取决于底层模型与连接器覆盖，非一键合规产品。
- Finding 验证（verify_findings）会产生额外模型调用，无人值守大规模运行需为 token 预算设置上限，否则成本不可控。
- GitHub/GitLab 在只读模式下 secret-scanning 端点与 GraphQL API 被封锁，某些需要更深入密钥扫描的工作流受限。
如何安装或部署这个 Agent？
macOS/Linux（推荐）：brew install cynative/tap/cynative。或脚本安装（校验 SHA-256）：curl -fsSL https://raw.githubusercontent.com/cynative/cynative/main/install.sh | sh。Windows：scoop bucket add cynative https://github.com/cynative/scoop-bucket && scoop install cynative。也可从 GitHub releases 页下载已签名的 .pkg（macOS）或静态二进制并用 checksums.txt / Sigstore 验证。安装后需设置至少一个 LLM 供应商，例如 export CYNATIVE_LLM_PROVIDER=anthropic、export CYNATIVE_LLM_MODEL=claude-opus-5、export ANTHROPIC_API_KEY=...。运行 cynative doctor 可验证配置与连接器就绪状态。
如何使用这个 Agent？
Cynative 直接使用 Shell 中已有的云凭据，不维护独立凭据存储，请提供最小权限的只读凭据。常用命令：cynative -p "which IAM roles can escalate to admin?" 单次运行；cynative "问题" 运行后进入交互会话；cynative --agent aws-public-data-stores 以预置代理启动；自定义代理：mkdir -p ~/.cynative/agents 后写入带 description 头部的 Markdown 文件，再用 cynative -p --agent <名称> 运行。每次工具调用可用 y（单次）、a（本会话该工具放行）或其他键拒绝；无终端时用 --auto-approve。无人值守运行可用 CYNATIVE_MAX_TOTAL_TOKENS、CYNATIVE_MAX_ITERATIONS 等变量控制成本。运维日志输出在 stderr，重定向 stdout 即可拿到干净的回答；退出码 0 表示产出报告，2 表示未得出答案。