Cynative
github.com/cynative/cynative- Category
- Cybersecurity
- Rank
- No. 1152Tools index
Previous survey · No. 1136 ·
- Pricing
- Open Source
- Type
- AGENT
- Use case
- Security & Identity
- Interfaces
- CLI
- GitHub
- 224 stars
- Latest release
- v1.14.1
- Date
About
An open-source CLI framework that runs LLM-driven security agents with live, read-only access to AWS, GCP, Azure, Kubernetes, GitHub and GitLab, generating and executing sandboxed code to answer infrastructure security questions. It ships 45 built-in agents for issues like privilege escalation and public exposure, cross-checks findings against live evidence, and enforces read-only access via IAM policy gating before any credential is attached.
What it does
Cynative is a single Go binary that turns a plain-language question about your cloud and repository setup into a live investigation. Point it at AWS, GCP, Azure, a Kubernetes cluster, GitHub or GitLab with credentials in your shell, and ask something like which roles can escalate to admin. Instead of a fixed script, the model writes small programs inside an isolated sandbox with no network access of its own, calling the target APIs in parallel and tracing each answer to its origin. Forty five prewritten investigations ship inside the binary, covering exposed storage, leaked secrets and supply chain paths, and anyone can add another by writing one markdown file.
Why it's ranked here
Apache 2.0 licensed, a single static binary with no runtime dependencies, and built with a test suite that fails the build on any uncovered statement in core code, race detector included. The connector documentation reads like it expects an attacker to review it: it distinguishes an IAM read filter from a read-only policy by name, and states plainly that only AWS sessions get vendor-side credential downscoping. Azure, GCP, GitHub, GitLab and Kubernetes connections rely entirely on cynative's own client-side gate, a limit the project documents rather than hides. That mix of a hard coverage gate and an honest account of its limits is rare among security tools that advertise read-only.
What's good
Every finding gets checked against live evidence before it reaches you, and every call the sandboxed code makes is logged to a JSONL file that the process aborts rather than lose. Secrets are stripped out of API responses before the model ever sees them. The 45 built-in checks are organized by cloud, so a run against a leaked key traces the exact blast radius rather than stopping at the leak itself. Building your own check is one markdown file with a required description field, and a broken or duplicated file fails loudly by name instead of silently falling back to a built-in with the same name.
Tradeoffs
Read-only protection is not uniform across connectors. Only AWS sessions get credential downscoping at the vendor level; against Azure, GCP, GitHub, GitLab and Kubernetes, the full-scope credential in your shell is what actually runs, restricted only by cynative's own action check before each call. The GitHub connector is hardcoded to the public api.github.com host, so GitHub Enterprise Server accounts cannot use it. The model connection itself is configured and proxied separately from every other outbound call, using a different mechanism, so pointing one through a corporate proxy does not automatically point the other.
How to use it well
This fits a security or platform engineer who wants a single, auditable way to ask multi-cloud questions instead of hand-rolling scripts against six different APIs. Point it at a shell that already has your AWS, Azure, GCP, GitHub, GitLab or kubeconfig credentials, pick your own model provider, and run a built-in check non-interactively so it drops into a pipeline or a scheduled job. Writing a house-specific check is a markdown file away, so a team can encode its own audit questions and version them like any other file. It is not a fix-it tool: it only reads, so remediation, IAM redesign and RBAC policy work still happen somewhere else.
Technical notes+
about.go embeds README.md directly into the binary with go:embed and extracts the block between HTML comment markers to build the CLI's own help text, so the on-disk docs and the runtime description cannot drift apart. agents.go separately embeds every file under the agents directory as the 45 built-in checks; a comment there notes an internal test pins that count. cmd/cynative/main.go is a short entrypoint that hands off to the CLI package and maps errors to process exit codes. docs/agents.md specifies the check file format precisely: frontmatter must be exactly one YAML key named description, at most 256 bytes and a single line even against Unicode line separators, and a malformed user file is marked invalid rather than silently falling back to a built-in of the same name. docs/proxy.md explains why an https proxy scheme is rejected at startup: Go would otherwise reuse a connector's TLS trust settings for the proxy hop, and proxy credentials are scrubbed from error text only when the username or password is at least four bytes long. docs/connectors/README.md's defense table shows vendor-side credential downscoping applies only to AWS assumed-role sessions; every other connector's read-only guarantee rests on cynative's own client-side action or RBAC check. go.mod pins the toolchain and lists the AWS, Azure and Google cloud SDKs alongside spf13/cobra and k8s.io/client-go. Makefile's test target requires full statement coverage on core code under the race detector before a change can land, and LICENSE confirms the Apache-2.0 terms.
Observed
- License
- Apache-2.0
- Language and packaging
- Go; ships as a single static binary with no runtime dependencies
- Install surface
- Homebrew tap, install script, Scoop (Windows), or manual binary download
- Interfaces
- Command-line only, interactive or non-interactive with piped input; no library or MCP interface
- Platform support
- macOS (Apple Silicon and Intel), Linux, Windows
- Cloud and platform connectors
- AWS, GCP, Azure, GitHub, GitLab, EKS, GKE, AKS, and self-managed Kubernetes
- LLM provider support
- Routed through an embedded SDK supporting OpenAI, Anthropic, Azure OpenAI, Amazon Bedrock, Google Vertex/Gemini, Cohere, Mistral, Groq, Ollama and vLLM
- Agent definition format
- Markdown file with single-key YAML frontmatter (description) plus a prompt body, loaded from a user directory or the embedded binary
- Release verification
- Checksums signed with a Sigstore bundle plus a GitHub release attestation
Read from README.md, go.mod, cmd/cynative/main.go, docs/agents-catalog.md, docs/agents.md, docs/proxy.md, LICENSE, about.go, agents.go, docs/connectors/README.md, Makefile.
What it can do
Run LLM-driven security agents with live read-only access to cloud and infrastructure accounts (AWS, GCP, Azure, Kubernetes, GitHub, GitLab)
Infrastructure security question → Security analysis/answer
Generate and execute sandboxed code to answer infrastructure security questions
Security question → Executed code results
Detect security issues such as privilege escalation and public exposure using built-in agents
Cloud/infrastructure environment → Detected security findings
Cross-check findings against live evidence
Security findings → Verified findings
Enforce read-only access via IAM policy gating before attaching credentials
Credentials → Restricted read-only access
Define and run custom security agents using markdown files
Markdown agent definition → Custom security agent
Tags
Tech Stack
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.