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

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

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.

# Google Vertex
export CYNATIVE_LLM_PROVIDER=vertex
export CYNATIVE_LLM_MODEL=gemini-3.1-pro-preview
export CYNATIVE_LLM_VERTEX_PROJECT_ID=my-gcp-project
export CYNATIVE_LLM_VERTEX_REGION=global
# CI / no gcloud: export GOOGLE_APPLICATION_CREDENTIALS=/path/to/sa.json

# OpenAI
export CYNATIVE_LLM_PROVIDER=openai
export CYNATIVE_LLM_MODEL=gpt-5.6-sol
export OPENAI_API_KEY=sk-...

# Amazon Bedrock - AWS credential chain
export CYNATIVE_LLM_PROVIDER=bedrock
export CYNATIVE_LLM_MODEL=anthropic.claude-opus-5
export CYNATIVE_LLM_BEDROCK_REGION=us-east-1

# Azure OpenAI - endpoint via env, no YAML needed
export CYNATIVE_LLM_PROVIDER=azure
export CYNATIVE_LLM_MODEL=my-gpt-5.6-sol
export AZURE_OPENAI_API_KEY=...
export CYNATIVE_LLM_AZURE_ENDPOINT=https://my-resource.openai.azure.com

# Local Ollama
export CYNATIVE_LLM_PROVIDER=ollama
export CYNATIVE_LLM_MODEL=nemotron-cascade-2
export CYNATIVE_LLM_OLLAMA_URL=http://localhost:11434

llm:
  provider: openai
  model: gpt-5.5
  api_key: env.OPENAI_API_KEY
  network_config:                 # common fields shown; see schemas.NetworkConfig for the full set
    base_url: https://my-proxy.example.com/v1
    default_request_timeout_in_seconds: 60
    max_retries: 3
    extra_headers:
      x-tenant: prod

Sessions and approvals

cynative opens an interactive session (full line editing and history with arrow keys); cynative "task" runs the task then stays interactive; -p / --print runs a single task non-interactively and exits - for scripts and pipes (e.g. cat main.tf | cynative -p "review this Terraform for misconfigurations").

Cynative calls your stack using the credentials already in your shell - it keeps no separate credential store. Always provide the least-privileged, read-only credential needed.

Approvals: each tool call waits for a single keystroke: y runs it once, a clears every later call to that tool for the session (scripts still print before running), any other key denies. With no controlling terminal, use --auto-approve.

Stopping mid-task: while a task is running, press Esc or Ctrl-C once to gracefully stop it (the agent finishes any already-running call, then stops and prints ⏸ Stopped). When the agent hits repeated tool errors or rejections it stops automatically, summarizes what it is blocked on, and asks for the missing information.

Bash Completion: See cynative completion <shell> --help for the full install notes for each shell.

Cynative prints a short operational footer (timing, token usage) to stderr - redirecting stdout (cynative -p "..." > out.txt) keeps the captured answer clean. --version prints version, commit, build date, Go version, and platform.

cynative doctor validates configuration and connector readiness without starting a research session. Pass --live-llm to also probe the configured model with a tool-less round-trip.

Connectors

On top of the credentials in your shell, Cynative enforces read-only at three layers:

• Network - every request host is pinned to its mapped service and region and the resolved IP is verified before connecting - your agent can reach your infrastructure and nothing else.
• Action gate - every operation is resolved to its required IAM actions, derived from the providers' own API definitions, then authorized by a read-only policy before any credential is attached: SecurityAudit (AWS), roles/viewer (GCP), Reader (Azure). Coverage tracks the cloud APIs as they grow, and the gate fails closed on anything it classifies as a write. For Kubernetes the policy is the cluster's own live view RBAC role, fetched at runtime and enforced per request. GitHub and GitLab are read-only by default; a connectors.{github,gitlab}.permissions setting can allow write on specific categories where a workflow needs it, enforced per request before the token is attached. Even in read-only mode, GitHub's secret-scanning endpoints stay blocked and GitLab's GraphQL API is denied.
• Credential (AWS) - for assumed-role identities, credentials are re-vended via STS AssumeRole, scoped to a managed policy (SecurityAudit by default), so AWS IAM enforces the boundary too. IAM-user and root identities run with their base credentials, gated by the action gate above.

Cynative connects AWS, GCP, Azure, EKS/GKE/AKS, self-managed Kubernetes, GitHub and GitLab. See docs/connectors/README.md for credential discovery, hardening, limitations and connector-specific examples.

Code execution & tool orchestration

For bulk work - "check every public S3 bucket", "list EKS clusters in every region" - Cynative can write and run JavaScript in a sandbox instead of issuing one tool call at a time. The agent's tools (e.g. http_request) are exposed as async JavaScript functions, so it loops, filters and chains calls in code - and runs independent calls concurrently with the built-in mapConcurrent(items, fn, limit) helper (or await Promise.all([...]) for small fixed sets). Only what the script console.logs returns to the model, keeping research fast and token-efficient.

// Discover regions, then list EKS clusters in every region concurrently,
// following pagination - only the summary returns to the model.
const r = await http_request({
  method: "GET",
  url: "https://ec2.us-east-1.amazonaws.com/?Action=DescribeRegions&Version=2016-11-15",
  auth_provider: "aws", aws_auth: { service: "ec2", region: "us-east-1" },
});
const regions = [...r.body.matchAll(/<regionName>([^<]+)<\/regionName>/g)].map((m) => m[1]);

const all = await mapConcurrent(regions, async (region) => {
  const clusters = [];
  let token = null;
  do {
    const url = `https://eks.${region}.amazonaws.com/clusters` +
      (token ? `?nextToken=${encodeURIComponent(token)}` : "");
    const resp = await http_request({
      method: "GET", url,
      auth_provider: "aws", aws_auth: { service: "eks", region },
    });
    const body = JSON.parse(resp.body);
    clusters.push(...body.clusters);
    token = body.nextToken;
  } while (token);
  return { region, clusters };
});

console.log(JSON.stringify(all.filter((x) => x.clusters.length > 0), null, 2));

• Async & concurrent: tool functions return Promises - await them, fan out over many resources with mapConcurrent(items, fn, limit) (bounded, order-preserving), or use await Promise.all([...]) for small fixed sets.
• Structured responses: http_request resolves to { status, statusText, headers, body }; body is the raw string - JSON.parse(resp.body) for JSON APIs or read it directly for XML.
• Sandboxed: a script can only call the tools Cynative exposes - it has no network or host access of its own.
• You see the whole script: each code_execution call is shown in full for approval before it runs (skip with --auto-approve; stream each inner call with -v).
• Stateful within a session: values saved on globalThis persist across calls during an interactive session, as long as the call runs to completion (one that times out or is left suspended resets them); top-level let/const/var/function are scoped to a single call.
• Bounded: scripts run under a timeout (default 120s) and a capped output size.

Audit Log

Every tool call is recorded to a persistent JSONL audit log (~/.cynative/audit.log, on by default). The log is fail-closed: if a call can't be recorded, the run aborts. Every entry from an agent run also records the agent's name, source and file digest, so a finding can be traced back to the exact prompt that produced it.

Tool results are redacted before they're written but approval-prompt arguments are stored verbatim - the log can hold sensitive values. It's readable only by the user who ran Cynative. Rotation and retention are configurable.

Configure under audit: in ~/.cynative/config.yaml, or via env:

Questions and feedback

Discussions is the best place to share your feedback - what you pointed it at, what came back, and what's missing. Stars help people find the project.

Contributing

Contributions welcome - new agents, connectors, evaluation datasets, and improvements across the board. See CONTRIBUTING.md for dev setup, the make check gate, and PR conventions, and SECURITY.md for reporting vulnerabilities.

License

Apache-2.0 License. See LICENSE for the full text.