> ## Documentation Index > Fetch the complete documentation index at: https://docs.cynative.com/llms.txt > Use this file to discover all available pages before exploring further. # Cynative: AI Security Research for Cloud Infrastructure > Cynative runs frontier AI models over AWS, GCP, Azure, Kubernetes, and GitHub to deliver read-only cloud security research with verified findings. Cynative is an open-source, single-binary CLI that runs frontier LLMs across your cloud infrastructure to answer real security questions. Point it at AWS, GCP, Azure, Kubernetes, GitHub, or GitLab and ask anything — it reasons through your live environment, writes and executes code in an ephemeral sandbox to fan out calls across your whole stack, cross-checks every finding against live evidence, and returns verified answers. All of this happens read-only by construction, with every action gated and authorized before a credential is attached. ```bash theme={null} cynative "what in my cloud is publicly exposed that shouldn't be?" ``` ## What Cynative Does Cynative works by combining four components: 1. **Model** — Your frontier LLM (Anthropic, OpenAI, Amazon Bedrock, Google Vertex, and more) drives the research loop, reasoning through questions, writing investigative code, and synthesizing findings. 2. **Sandbox** — The model generates and runs JavaScript in an ephemeral, isolated sandbox that has no direct network or host access of its own. Tool functions (e.g. `http_request`) are exposed as async JavaScript functions, allowing the model to loop, filter, and fan out API calls concurrently using `mapConcurrent` — returning only what it `console.log`s, keeping research fast and token-efficient. 3. **Action gate** — Every operation is resolved to its required IAM actions, derived from the cloud providers' own API definitions, and authorized against a read-only policy (`SecurityAudit` for AWS, `roles/viewer` for GCP, `Reader` for Azure) **before** any credential is attached. The gate fails closed on anything it classifies as a write. 4. **Connectors** — Built-in connectors for AWS, GCP, Azure, EKS/GKE/AKS, self-managed Kubernetes, GitHub, and GitLab pick up the credentials already in your shell. Network access is pinned per-connector — your agent reaches your infrastructure and nothing else. ## Key Capabilities Pre-reviewed, embedded agents for AWS (20), Azure (11), GCP (5), GitHub (4), and Kubernetes (5) — covering privilege escalation, public exposure, supply chain, detection coverage, and more. Every call is gated before a credential is attached. The action gate checks required IAM actions against a security-audit policy and fails closed — `SecurityAudit` blocks `secretsmanager:GetSecretValue` where a simple read filter would pass it. The model writes JavaScript that runs in an isolated sandbox. Independent API calls fan out concurrently with `mapConcurrent`, following pagination and aggregating results — far fewer tokens and faster answers than one-call-at-a-time approaches. Native connectors for AWS, GCP, Azure, EKS, GKE, AKS, self-managed Kubernetes, GitHub, and GitLab. Uses the credentials already in your shell — no separate credential store. Powered by the embedded [Bifrost](https://github.com/maximhq/bifrost) SDK. Supports OpenAI, Anthropic, Azure OpenAI, Amazon Bedrock, Google Vertex/Gemini, Cohere, Mistral, Groq, Ollama, vLLM, and more. Every tool call is recorded to a persistent JSONL audit log (`~/.cynative/audit.log`). If a call can't be recorded, the run aborts. Agent runs also record the agent name, source, and file digest — every finding traces back to its exact prompt. ## How It Differs from Coding Agents and MCP Servers Cynative is purpose-built for security research, not general automation. Here's how it compares to reaching for a coding agent with MCP servers: | | Coding agent + MCPs | Cynative | | - | - | - | | **Throughput** | One action per call | Writes sandboxed code that fans out calls concurrently — fewer tokens, faster answers | | **Findings** | Unverified output | Verifier cross-checks every finding against live evidence | | **Read-only** | Opt-in read filter | On by default, fails closed — required IAM actions checked against a security-audit policy. `secretsmanager:GetSecretValue` is an IAM *Read*: a filter allows it, `SecurityAudit` blocks it | | **Credentials** | Ambient, unchanged | STS session scoped to read-only — AWS enforces the boundary too | | **Blast radius** | Your shell, any network | Research code runs in a sandbox with no host access; network pinned to your mapped services | | **Secrets** | Sent to the model as-is | Redacted from tool output before it's sent to the model | | **Supply chain** | Third-party MCPs and skills running with your creds | One open-source binary, connectors built in | | **Audit trail** | Scattered session logs, best effort | Fail-closed JSONL log of every tool call — if it can't record, it aborts | ## What Your Agents Get Every agent — built-in or custom — runs with the same set of capabilities: * **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 Run Cynative on an instance inside the cloud it audits, through that cloud's managed inference, and the entire research loop stays within your environment. ## Ready to Get Started? Head to the [Quickstart](/quickstart) to install Cynative, configure your LLM provider, and run your first cloud security audit in minutes. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.