Cynative Security Agent Framework
Read-only access to your cloud and code as one system — write security agents in a single markdown file to audit privilege escalation, public exposure, and leaked credentials.
Evidence shows three-layer read-only enforcement (network host pinning, IAM action gate, AWS STS scoping to SecurityAudit), so least_privilege is full marks; deductions: user_confirmation only 2 because --auto-approve can bypass all approvals; rollback 1 because the repo documents uninstall only, not recovery semantics for a misbehaving run (read-only design partially mitigates but is not stated as such); source_attribution 2 because the audit log records agent name/source/digest, but publisher identity is unverified.
failure_messages is full marks: documented exit codes 0/1/2/130/143, fail-closed behavior, and halt-and-summarize notices; dependency_availability only 2: `cynative doctor` probes connector readiness but nothing is executed here; self_consistency 2: README matches workflow/test files, but all claims are static.
audience_and_scenarios is full marks: quickstart, first-agent walkthrough, CI/unattended runs, and multi-provider examples are clearly targeted; capability_boundaries and trigger_precision are 2: the `--agent`/-p composition and shadowing rules are documented but misuse boundaries of agent triggering are not; environment_fit 2: multi-platform with multiple install channels, with Windows details folded away and residual limits acknowledged.
information_architecture, install_notes, examples_and_faq, and license are full marks: complete doc structure, install channels with signature/checksum/update/uninstall coverage, a comparison table and examples, and full LICENSE text; known_limitations 2: cosign network trust root and GitHub secret-endpoint blocks are disclosed but no consolidated limitation list; versioning_changelog 2: a release/checksums/Sigstore regime exists but no standalone changelog file; maintenance_responsibility 2: SECURITY.md promises 3-day ack / 90-day disclosure, but team size and response history are unevidenced.
marginal_value is full marks: the coding-agent+MCP comparison table articulates concrete differentiation (concurrent sandbox, verifier, fail-closed audit); output_usability 2: stdout/stderr separation, footer, and exit-code design are reasonable but unverified by execution; cost_benefit 2: token/iteration/concurrency caps are provided, but no real cost data.
claim_traceability 2: the audit log carries agent name, source, and file digest, and the install chain has checksums + Sigstore + GitHub attestation; cross_source_corroboration 2: channel-smoke and attestation workflows plus archive/unit test scripts corroborate README claims, but statically only; fact_inference_separation 2: most claims state provenance and limits (e.g., async attestation lag), while a few marketing assertions remain undifferentiated.
- Publisher is unverified: the binary is the primary distribution channel; verify via Sigstore/cosign and gh release verify in a trusted environment before running.
- --auto-approve skips per-call approvals; in unattended settings always set max_total_tokens, max_iterations, and related caps.
- The audit log stores approval-prompt arguments verbatim and may contain sensitive values; review its permissions and retention settings.
- GitHub/GitLab connectors can be configured for write via connectors.permissions; keep read-only defaults in production.
- This is a static source review (low confidence); all runtime claims (permission enforcement, redaction, cost) are unverified by execution.
What does this agent do, and when should you use it?
Cynative is an open-source (Apache-2.0) framework for security agents, shipped as a single static Go binary installable via Homebrew, an install script, or Scoop. Using credentials already in your shell, it connects to AWS, GCP, Azure, Kubernetes (EKS/GKE/AKS and self-managed), GitHub and GitLab, reasoning across your whole infrastructure as one system. It writes and runs JavaScript in an ephemeral sandbox, fanning out concurrent API calls through async tools like http_request, and cross-checks every finding with a built-in verifier. Every call is resolved to its required IAM actions and authorized against read-only policies (SecurityAudit, roles/viewer, Reader) by an action gate before any credential is attached, and request hosts are pinned at the network layer — read-only by construction. An agent is just a markdown file dropped into ~/.cynative/agents/, and every tool call is recorded to a fail-closed JSONL audit log. Through the embedded Bifrost SDK it supports nearly every major LLM provider including OpenAI, Anthropic, Bedrock, Vertex and local Ollama, so it can run entirely inside your environment.
You ask questions via cynative "..." or run single tasks with cynative -p "...", e.g. "which IAM roles can escalate to admin?". The agent reads your shell's existing cloud credentials, writes and runs JavaScript in a sandbox (fanning out paginated API calls concurrently with mapConcurrent), and queries live state across AWS, GCP, Azure, Kubernetes, GitHub and GitLab. Every operation is first resolved to its required IAM actions and authorized against read-only policies — SecurityAudit for AWS, roles/viewer for GCP, Reader for Azure, and the cluster's live view RBAC role fetched at runtime for Kubernetes — with AWS credentials re-vended via STS AssumeRole scoped to SecurityAudit. Outputs like findings. can be piped back through cynative -p for triage; agents are selected with --agent, either user markdown files or built-ins such as aws-public-data-stores. The audit log at ~/.cynative/audit.log records each agent's name, source and file digest, and secrets in tool output are redacted before reaching the model.
- A security engineer investigating which AWS IAM roles can escalate to admin, tracing each high-risk permission back to the PR that granted it.
- A DevSecOps team auditing CI-to-cloud privilege escalation paths, such as the blast radius of GitHub/GitLab credentials in the cloud.
- A product security team running scheduled, unattended scans (with --auto-approve) for publicly exposed S3 buckets, RDS snapshots and EBS snapshots.
- A cloud architect checking live cloud resources absent from IaC (drift) in an interactive session, drilling into details.
- A sovereignty- or compliance-bound team running Cynative on an instance inside the audited cloud with Bedrock or Vertex inference so nothing leaves the environment.
- A vulnerability manager piping scanner output (findings.) through cynative -p to triage findings by exploitability.
What are this agent's strengths and limitations?
- Read-only by construction: the action gate resolves each call's required IAM actions and authorizes against SecurityAudit/roles/viewer/Reader policies before a credential attaches, failing closed on writes — stricter than opt-in MCP read filters.
- AWS credentials are re-vended via STS AssumeRole scoped to SecurityAudit, so AWS IAM enforces the boundary too, not just client-side filtering.
- Sandboxed code execution fans out concurrent API calls for bulk research — fewer tokens, faster — with only console.log summaries returned to the model.
- Every finding is cross-checked by a verifier against live evidence, and the JSONL audit log records agent name, source and file digest so findings trace back to the exact prompt.
- Provider-agnostic via Bifrost (including local Ollama), one static binary that can run inside the cloud it audits — sovereign deployment.
- You must supply and manage target cloud/platform credentials yourself; the README explicitly requires least-privileged read-only credentials, so misconfiguration carries real risk.
- The audit log redacts tool results but stores approval-prompt arguments verbatim, so it can hold sensitive values — permissions and retention need active management.
- Writing agents requires understanding cloud APIs and IAM concepts; agent capability ceilings depend on the underlying model and connector coverage — not a turnkey compliance product.
- Finding verification (verify_findings) makes extra model calls, so unattended large runs need explicit token budgets or costs are unbounded (max_total_tokens defaults to 0/unbounded).
- In read-only mode GitHub secret-scanning endpoints stay blocked and GitLab's GraphQL API is denied, limiting some secret-focused workflows.
How do you install or deploy this agent?
macOS/Linux (recommended): brew install cynative/tap/cynative. Or the install script (verifies SHA-256, fails closed): 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. Alternatively download signed/notarized .pkg installers or static binaries from the GitHub releases page and verify against checksums.txt or the Sigstore bundle. Then configure an LLM provider, e.g. export CYNATIVE_LLM_PROVIDER=anthropic, export CYNATIVE_LLM_MODEL=claude-opus-5, export ANTHROPIC_API_KEY=.... Run cynative doctor to validate config and connector readiness.
How do you use this agent?
Cynative uses the credentials already in your shell and keeps no separate credential store — provide least-privileged, read-only credentials. Key invocations: cynative -p "which IAM roles can escalate to admin?" for one-shot runs; cynative "question" to start interactive after the task; cynative --agent aws-public-data-stores to run a built-in agent. Custom agents: mkdir -p ~/.cynative/agents, then write a markdown file with a description header, and run cynative -p --agent <name>. Each tool call waits for a keystroke: y runs once, a approves that tool for the session, any other key denies; use --auto-approve without a TTY. Bound unattended runs with CYNATIVE_MAX_TOTAL_TOKENS, CYNATIVE_MAX_ITERATIONS, etc. Operational footers go to stderr, so redirecting stdout captures a clean answer; exit code 0 means a report was produced, 2 means the run finished without an answer.