Cynative：cloud、code、runtime を横断して聞ける read-only security research agent
cloud security の調査で面倒なのは、単体 scanner が alert を出せないことより、証拠がいくつもの layer に散らばることだ。
GitHub Actions workflow が OIDC で AWS role を assume し、その role が IAM policy を変更できる。Terraform 上は read-only に見えるが、実際の Kubernetes RBAC では別の permission が開いている。漏れた cloud credential がまだ使えるのか、blast radius がどこまであるのかも、source code search だけでは判断できない。GitHub、IaC、cloud account、Kubernetes、runtime logs を別々に調べ、最後に人間が evidence をつなぐことになる。
今日メモしておきたい cynative/cynative は、この問題を扱う project だ。general-purpose な coding agent ではなく、infrastructure security research 向けの local CLI で、local machine にある cloud / code platform credentials を使い、GitHub、GitLab、AWS、GCP、Azure、Kubernetes を read-only に問い合わせる。model は sandbox 内で query code を生成し、parallel に evidence を集め、finding を cross-check する。
2026-07-16 時点で GitHub repository API、repository page、README、Releases、Tags、commit history、LICENSE から確認できる公開情報では、cynative/cynative は 116 stars、21 forks。主言語は Go、license は Apache-2.0。repository 作成日は 2026-06-24 18:06:26 UTC、最近の public push は 2026-07-16 09:23:47 UTC。default branch main の最新 commit は 3f66e87、commit time は 2026-07-16 12:23:18 +0300。最新 GitHub release は v1.5.1、published at は 2026-07-10 18:43:25 UTC。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | cynative/cynative |
| 位置づけ | local で動く read-only 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 commit | 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 |
扱っているのは cross-layer evidence の問題
Cynative の README は、いくつかの問いで用途を説明している。どの IAM role が admin へ privilege escalation できるか。high-risk cloud permissions を、それを追加した PR まで trace できるか。source code に漏れた cloud credentials の現在の blast radius はどこか。live cloud resources が IaC から drift していないか。
これらに共通するのは、答えが一つの system にないことだ。code hosting platform、CI config、cloud API、Kubernetes RBAC、IaC files、runtime state をまたいで見ないといけない。普通の scanner は findings を出せるが、「この permission はどこから来たのか、今何ができるのか、evidence chain は閉じているのか」までは説明しづらい。
Cynative は agent に text を読ませるだけでなく、一つの security question を中心に investigation code を生成させ、controlled sandbox で複数 API を parallel に問い合わせ、finding を verifier に cross-check させる。security team にとって重要なのは「model が危ないと言った」ではなく、「conclusion が具体的な evidence に戻れる」ことだ。
Read-only は prompt promise ではない
この project で一番見るべき点は、read-only boundary を implementation に入れているところだ。system prompt に「書き込まないで」と書くだけではない。
README では、各 call が action gate を通ると説明されている。operation は必要な IAM actions に解決され、read-only policy と照合される。AWS は default で SecurityAudit、GCP は roles/viewer、Azure は Reader。Kubernetes では cluster の live view RBAC role を取得し、request ごとに enforcement する。AWS assumed-role identity の場合、STS で read-only managed policy に scoped された credential を再発行する。
これは「coding agent に MCP servers をいくつか接ぐ」のとは違う。MCP server 側でも permission control はできるが、production credential を agent shell に置き、prompt で書き込みを禁じるだけなら boundary は薄い。Cynative が目指しているのは fail closed だ。分類できない、authorization が通らない、audit log を書けない、といった状況では進めない設計になっている。
Sandbox は investigation code を走らせるためにある
security investigation は、一つの API call で終わらないことが多い。GitHub Actions workflow を列挙し、OIDC role を見つけ、AWS IAM policy を確認し、実際の reachable permission と比べる。agent に tool call を一回ずつ投げさせると遅く、context も消費する。
Cynative は model に investigation code を書かせ、それを ephemeral sandbox で実行する。sandbox は host access を持たず、network も mapped service と region に制限される。README は普通の coding agent + MCP との違いを、後者が一 action 一 tool call になりがちなのに対し、Cynative は sandbox code で fan out して問い合わせ、結果を verifier に戻す、と説明している。
これは infrastructure security には自然な方向だ。security engineer はもともと cloud account、CI config、permission graph を調べるために one-off script を書く。Cynative は「script を書く、走らせる、evidence を整理する、finding を verify する」という流れを agent workflow にしている。
Local-first でも credential discipline は必要
Cynative は embedded Bifrost SDK 経由で model provider と話す。README には OpenAI、Anthropic、Azure OpenAI、Amazon Bedrock、Google Vertex/Gemini、Cohere、Mistral、Groq、Ollama、vLLM などが挙がっている。tool 自体は local で動き、独自の credential store を持たず、shell にすでにある credentials を使う。
これは接続のハードルを下げる。cloud account を別の SaaS に import する必要はない。一方で、user 側の discipline も必要だ。README は、task に必要な least-privileged、read-only credential を使うよう明示している。action gate や STS scoping があっても、高権限の long-lived credential を automation に渡すべきではない。
Approvals、--auto-approve、token / iteration / concurrency ceiling、fail-closed JSONL audit log、secret redaction といった control も用意されている。security agent の難しさは「調べられるか」だけではなく、調査中の cost、permission、network、audit surface をどう制御するかでもある。
向いている場面
第一の場面は cloud permission と CI/OIDC risk の調査だ。ある GitHub workflow が最終的にどの AWS/GCP/Azure permission に到達できるのか、ある cloud role がどの PR で導入されたのかを調べたい場合に合う。
第二の場面は IaC と runtime drift だ。Terraform、Kubernetes manifest、実際の cloud resources、live RBAC は少しずつずれる。repository だけを見ると、現在の状態を見落としやすい。
第三の場面は incident 時の quick evidence gathering だ。漏れた credential がまだ有効か、どの resource に届くか、privilege escalation できるか、といった問いは code と cloud API の両方を見ないと答えられない。
第四の場面は、小さな team が AI-assisted security research を local で試したいが、infrastructure metadata を第三者 platform に渡したくない場合だ。
注意したいところ
第一に、project はかなり若い。repository 作成日は 2026-06-24。release は v1.5.1 まで進み、最近の push も活発だが、production environment ではまず read-only、low-risk account から試すべきだ。
第二に、read-only boundary は cloud 側の least privilege を置き換えない。Cynative には action gate と credential scoping があるが、base identity が広すぎるなら、logs、network scope、provider config を慎重に確認する必要がある。
第三に、model output は人間の判断を不要にしない。evidence-backed と verifier を強調していても、security finding を remediation や incident response に入れる前には、environment を知る人が review した方がよい。
第四に、接続対象が増えるほど configuration は複雑になる。GitHub、GitLab、AWS、GCP、Azure、Kubernetes にはそれぞれ permission model がある。tool が入口を統一しても、organization 側の permission governance が不要になるわけではない。
まとめ
Cynative が面白いのは、AI security tool を「もう一つの chat UI」にしていないところだ。むしろ local research desk に近い。code platform、cloud account、Kubernetes runtime を同じ read-only investigation boundary に置き、agent に script を書かせて evidence を集め、findings を cross-check する。
通常の SAST や IaC scanner だけが必要なら、これは置き換えではない。ただし「この permission はどこから来たのか、今どこまで影響するのか、evidence chain はどこにあるのか」という cross-layer question によく向き合っているなら、cynative/cynative は観察する価値がある。小さな project だが、security engineering のかなり現実的な摩擦を切っている。