Build your own security agents

Open-source framework for security agents with live, read-only access to your infrastructure.

Quickstart · Your first agent · Docs

Ask your infrastructure anything. Cynative runs frontier models across your code, cloud and runtime - reasoning through GitHub, GitLab, AWS, GCP, Azure and Kubernetes as one system - and comes back with verified answers.

cynative "what in my cloud is publicly exposed that shouldn't be?"

It writes and runs code in an ephemeral sandbox, querying your APIs in parallel, so one question fans out across your whole stack. Every finding is cross-checked and traced back to its origin.

Unlike coding agents and MCP servers, it's read-only by construction: every call is gated and authorized before a credential is attached - point it at production with confidence.

What your agents get

• Code-to-runtime: Reasons through AWS, GCP, Azure, any K8s, GitHub and GitLab
• Sandbox: Generates and runs code to research at scale, with no network or host access of its own
• Action-gate: Resolves every call to its required IAM actions and applies a read-only policy before a credential is attached
• Evidence-backed: Cross-checks to verify every finding
• Sovereign: One binary, your model, your data stays yours

Quickstart

Install and set an LLM:

brew install cynative/tap/cynative

export CYNATIVE_LLM_PROVIDER=anthropic
export CYNATIVE_LLM_MODEL=claude-opus-5
export ANTHROPIC_API_KEY=...

It picks up the credentials already in your shell. Ask it anything:

cynative -p "which IAM roles can escalate to admin?"
cynative -p "high-risk cloud permissions, trace each to the PR where it was granted"
cynative -p "cloud credentials leaked in source code and their current blast radius"
cynative "live cloud resources absent from IaC - drift" # starts an interactive session
cat findings.json | cynative -p "triage these findings by exploitability"

Your first agent

An agent is a markdown file: one line of description, then the prompt. The filename is the name. To add your own, create ~/.cynative/agents/ and write one in it. Cynative does not create this directory for you:

mkdir -p ~/.cynative/agents

cat > ~/.cynative/agents/aws-public-data-stores.md <<'EOF'
---
description: Finds publicly accessible data stores in an AWS account.
---
Check S3, RDS snapshots, EBS snapshots and public AMIs for exposure.
Report each finding with the resource ARN and how it is reachable.
EOF

cynative -p --agent aws-public-data-stores

See docs/agents.md for the format.

Running agents

cynative -p --agent aws-public-data-stores "AWS account ID 12814983572854 only"   # with a task
cynative -p --agent aws-public-data-stores                    # without
cynative --agent aws-public-data-stores                       # seeds an interactive session

--agent composes with -p, --auto-approve, --config and piped stdin, so the same file runs interactively while you develop it and non-interactively once it settles.

Agents are read from ~/.cynative/agents/ and from the set built into the binary; a user file wins over a built-in of the same name. cynative agents list shows every agent with its source and marks the shadowed copies, and cynative agents show <name> prints the exact file that would run.

Can't a coding agent with MCPs do this?

One binary, your model endpoint, your account. Run it on an instance in the cloud it audits, through that cloud's managed inference, and nothing leaves your environment: security on your infrastructure, from within your infrastructure.

Installation

Homebrew (macOS / Linux - recommended):

brew install cynative/tap/cynative

Install script (macOS / Linux - verifies the download's SHA-256 against the release checksums.txt, failing closed):

curl -fsSL https://raw.githubusercontent.com/cynative/cynative/main/install.sh | sh

Windows (Scoop):

scoop bucket add cynative https://github.com/cynative/scoop-bucket
scoop install cynative

Update / uninstall

Windows (PowerShell script): irm https://raw.githubusercontent.com/cynative/cynative/main/install.ps1 | iex; uninstall with & ([scriptblock]::Create((irm https://raw.githubusercontent.com/cynative/cynative/main/install.ps1))) -Uninstall.

Install-script options: pin a version with CYNATIVE_VERSION=v1.0.0; change the target directory with CYNATIVE_INSTALL_DIR (default ~/.local/bin, no sudo). The script checks the GitHub release attestation when gh is installed (advisory by default); set CYNATIVE_REQUIRE_ATTESTATION=1 to make a failed check fatal. For a high-integrity install, fetch the script from an immutable tag instead of main.

macOS (manual): download cynative_Darwin_arm64.pkg (Apple Silicon) or cynative_Darwin_x86_64.pkg (Intel) from the releases page and install with sudo installer -pkg <file> -target / (or double-click). These are signed, notarized and stapled - no first-run Gatekeeper prompt. The raw cynative_Darwin_*.tar.gz archives remain for scripting/CI; a quarantined tarball binary's first GUI launch needs internet for the online notarization check (terminal/install.sh/Homebrew use is unaffected).

Linux / Windows (manual): download a prebuilt binary and checksums.txt from the releases page, verify the SHA-256, and put the binary on your PATH. Single static binary, no dependencies.

Verify a release signature (optional). New releases ship checksums.txt.sigstore.json, a Sigstore bundle signing checksums.txt with a keyless certificate bound to this repo's release workflow. Authenticate the manifest, then check your archive against it:

cosign verify-blob checksums.txt \
  --bundle checksums.txt.sigstore.json \
  --certificate-identity "https://github.com/cynative/cynative/.github/workflows/release.yaml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

grep cynative_Linux_x86_64.tar.gz checksums.txt | sha256sum -c -      # Linux
grep cynative_Darwin_arm64.tar.gz checksums.txt | shasum -a 256 -c -  # macOS

(Get-FileHash .\cynative_Windows_x86_64.zip -Algorithm SHA256).Hash.ToLower()
Select-String -Path checksums.txt -Pattern cynative_Windows_x86_64.zip

This covers the archives named in checksums.txt. The .pkg installers are Developer ID signed, notarized and stapled instead, and every asset is additionally covered by the GitHub release attestation (gh release verify <tag>). Two limits worth knowing: cosign fetches Sigstore's trust root over the network unless you pass --trusted-root, and because the file names carry no version, the signature proves origin and integrity but not which release a loose set of files came from - the release URL or gh release verify is what binds a version.

LLM providers

Cynative talks to LLMs through the embedded Bifrost SDK and supports almost any AI provider out of the box (OpenAI, Anthropic, Azure OpenAI, Amazon Bedrock, Google Vertex/Gemini, Cohere, Mistral, Groq, Ollama, vLLM and more). Pick one from docs/providers/README.md and follow that provider's guide.