Cynative is an open-source AI agent framework designed specifically for cloud security, covering AWS, Azure, GCP, and Kubernetes. Its core positioning is to let users ask questions about infrastructure in natural language; the framework reasons over code, cloud, and runtime through frontier models, and returns verified answers with GitHub, GitLab, AWS, GCP, Azure, and Kubernetes as one integrated system. Its officially described uses include AI-driven cloud detection and response, as well as triage of Cloud Security Posture Management (CSPM) findings.
In terms of main capabilities, Cynative includes 45 built-in agents for AWS, GCP, Azure, GitHub, and Kubernetes, covering topics such as privilege escalation, public exposure, supply chain, and detection coverage; users can also write their own agents with a single markdown file. A single question fans out across the entire stack: Cynative writes and runs code in ephemeral sandboxes, queries APIs in parallel, and every finding is cross-verified and traced back to its source. The framework emphasizes "read-only by construction"—every call passes through a gate and authorization before credentials are mounted, so it can be pointed at production with confidence. It supports code-to-runtime reasoning, sandboxed execution (generated code itself has no network or host access), action gating (resolving each call into the required IAM action and applying a read-only policy before mounting credentials), evidence backing (cross-verifying every finding), and self-contained control (a single binary, with models and data remaining in the user's environment).
Installation and usage: the official recommendation is Homebrew (macOS/Linux), and the installation command is brew install cynative. An installation script is also provided:curl -fsSL https://raw.githubusercontent.com/cynative/cynative/main/install.sh | sh, which verifies the SHA-256 of the downloaded file using the release checksums.txt, and aborts if verification fails. Windows uses Scoop. Updates and uninstallation follow the official documentation. Before use, an LLM must be configured; Cynative communicates with models through the embedded Bifrost SDK, supporting multiple providers such as OpenAI, Anthropic, Azure OpenAI, Amazon Bedrock, Google Vertex/Gemini, Cohere, Mistral, Groq, Ollama, and vLLM. Running built-in agents or asking questions directly can both be done from the command line;--agent can be combined with -p、--auto-approve、--config and piped stdin, making it convenient to run interactively during development and non-interactively once stable.
Sessions and approvals:cynative opens an interactive session;cynative "task" keeps the session interactive after executing a task;-p/--print executes a single task non-interactively and exits, for scripts and pipelines, with the exit code carrying the determination result (0 means a report was produced, 2 means the run completed but had no answer, 130 means interrupted, 143 means SIGTERM, 1 means other failure). Each tool call waits for keypress approval: y allows once, a clears subsequent calls to that tool for this session, other keys reject; when there is no controlling terminal, use --auto-approve. During task execution, pressing Esc or Ctrl-C stops gracefully.
Security and limitations: Cynative uses existing credentials in the shell and does not maintain a separate credential store, so least-privilege credentials should be provided; the action gate is not a substitute for least privilege. It enforces read-only through three layers: the network layer (the request host is bound to the mapped service and region, and the resolved IP is verified during direct routing), the action gate (operations are resolved into the required IAM actions, authorized by a read-only policy, with default policies such as AWS's SecurityAudit, GCP's roles/viewer, and Azure's Reader, failing closed on write classification failures; Kubernetes uses the cluster's live-view RBAC roles to execute per request), and the credential layer (AWS assumed-role identities are reissued via STS AssumeRole, limited within the managed policy). GitHub and GitLab are read-only by default, and writes can be allowed in specific categories via connectors.{github,gitlab}.permissions; in read-only mode, GitHub secret scanning endpoints are still blocked, and the GitLab GraphQL API is denied.
Code execution and auditing: For batch work, Cynative can write and run code in a sandbox using JavaScript, exposing agent tools (such as http_request) as async functions, supporting mapConcurrent concurrency and Promise.all; only what the script logs via console.log is returned to the model. Scripts are subject to timeouts (default 120 seconds) and output size limits, and have no network or host access of their own. Every tool call is recorded in a persistent JSONL audit log (~/.cynative/audit.log, enabled by default), and fails closed if logging fails; entries for agent runs also record the agent name, source, and file digest. Tool results are redacted before being written, but approval prompt parameters are stored as-is, and logs may contain sensitive values, are readable only by the runner, and rotation and retention are configurable.
Other: Cynative connects to AWS, GCP, Azure, EKS/GKE/AKS, self-managed Kubernetes, GitHub, and GitLab, and supports standard HTTPS_PROXY/HTTP_PROXY/NO_PROXY enterprise proxies. Provides cynative doctor to verify configuration and connector readiness,cynative agents list/show to view agents. The project is licensed under Apache-2.0. Official documentation, discussion forums, and contribution guidelines all point to the corresponding files in the repository.