Cynative Security Research Agent

Product Introduction

1. Definition: Cynative Security Research Agent is an open-source, AI-powered command-line interface (CLI) tool purpose-built for multi-cloud, code, and runtime security research. It belongs to the category of intelligent security audit agents that combine large language models (LLMs) with sandboxed code execution to answer complex security questions in natural language.

2. Core Value Proposition: Designed to close the gap between asking a security question and getting a verified, evidence-backed answer, Cynative eliminates the need for manual scripting or point-and-click cloud consoles. It enables security engineers, DevOps teams, and cloud architects to ask plain-language queries—like “what’s publicly exposed that shouldn’t be?” or “which IAM roles can escalate to admin?”—and receive verifiable results traced back to live infrastructure, all while guaranteeing read-only access across AWS, GCP, Azure, Kubernetes, GitHub, and GitLab.

Main Features

1. Multi-Cloud & CI/CD Connectors (Action-Gate Enforcement)
   Cynative integrates natively with AWS, GCP, Azure, EKS/GKE/AKS, self-managed Kubernetes, GitHub, and GitLab. Every API call is resolved to its required IAM actions using the provider’s own API definitions, then authorized against a read-only policy (e.g., AWS SecurityAudit, GCP roles/viewer, Azure Reader, Kubernetes view RBAC) before any credential is attached. The gate is fail-closed: any operation classified as a write is blocked immediately. For GitHub/GitLab, write categories can be selectively allowed per request, but secret-scanning endpoints (GitHub) and GraphQL APIs (GitLab) remain blocked by default. Additionally, AWS assumed-role identities are re-vended via STS AssumeRole scoped to a managed read-only policy, enforcing the boundary at the IAM layer as well as the application layer.

2. Sandboxed JavaScript Execution with Concurrent Fan-Out
   Instead of issuing one tool call per action, Cynative generates and runs JavaScript code inside an ephemeral sandbox. All agent tools (e.g., http_request, kubectl, aws-cli) are exposed as async JavaScript functions, allowing the agent to loop, filter, paginate, and chain calls—and run independent calls concurrently using the built-in mapConcurrent(items, fn, limit) helper or await Promise.all([...]). The sandbox has no network, filesystem, or package access of its own; results are returned to the model only via console.log. This approach drastically reduces token consumption and latency for bulk queries, such as checking every public S3 bucket or listing EKS clusters across all regions.

3. Verifier Cross-Checking & Evidence-Backed Findings
   Every finding produced by the research agent is automatically cross-checked against live infrastructure data before being presented to the user. The verifier re-queries the relevant APIs to confirm that the discovered issue (e.g., an over-privileged IAM role, a public S3 bucket, a Terraform drift) still exists and is accurately described. Each verified finding is traced back to its origin—the specific API response, log entry, or code block—providing a fully attributable audit trail that meets compliance and incident response requirements.

4. Fail-Closed Audit Logging
   Every tool call is recorded to a persistent JSONL audit log stored at ~/.cynative/audit.log (on by default). The log is fail-closed: if a call cannot be recorded, the entire run aborts. Approval-prompt arguments are stored verbatim (may contain sensitive values) and the file is readable only by the user who ran Cynative. Log rotation, retention (default 30 days), compression, and path are configurable via environment variables or config.yaml. This satisfies strict internal governance and SOC audit requirements.

5. Resource & Cost Controls for Unattended Runs
   For cron, CI/CD, or scheduled scans, Cynative provides several knobs to bound research depth and cost: max_total_tokens (per-session LLM token ceiling), max_iterations (main loop tool-calling iterations), max_subagent_iterations, max_consecutive_failures, and sandbox_max_concurrency. These prevent runaway token usage and ensure predictable spend even when running unattended with large infrastructures.

Problems Solved

1. Pain Point: Security Blind Spots Across Fragmented Environments
   Security teams often struggle to correlate findings across multiple cloud providers, CI/CD pipelines, and runtime environments. A misconfigured IAM role in AWS might be leveraged from a GitHub Actions workflow via OIDC, but tracing that escalation path requires manual data gathering. Cynative solves this by reasoning across GitHub/GitLab, AWS/GCP/Azure, and Kubernetes as one system, answering questions like “high-risk cloud permissions, trace each to the PR where it was granted” in a single session.

2. Target Audience

   • DevOps Engineers who need to verify that infrastructure changes (Terraform, CI/CD) do not introduce security regressions.
   • Cloud Security Architects responsible for designing least-privilege access models.
   • SOC Analysts investigating potential credential leaks or privilege escalation paths.
   • Compliance Officers requiring evidence-backed reports for audits (e.g., SOC 2, ISO 27001, FedRAMP).
   • Open Source Maintainers who want to secure their repositories and cloud deployments without licensing costs.

3. Use Cases

   • Auditing CI/CD Privilege Escalation: Ask “can my CI escalate to cloud admin?” and Cynative traces the OIDC roles assumed by GitHub Actions workflows, checking each role’s attached policies against the SecurityAudit baseline.
   • Detecting Cloud Credentials Leaked in Source Code: Run cynative -p "cloud credentials leaked in source code and their current blast radius"—the tool scans repositories for secrets, maps them to cloud resources, and assesses the actual permissions.
   • Identifying IaC Drift: Use cynative "live cloud resources absent from IaC - drift" to discover resources deployed outside Terraform, CloudFormation, or other infrastructure-as-code tools.
   • One-Off Incident Investigations: During a security incident, paste a query like “which IAM roles can escalate to admin?” to quickly map out the blast radius without logging into multiple consoles.

Unique Advantages

1. Differentiation from Coding Agents with MCP Servers
   While generic coding agents can be combined with Model Context Protocol (MCP) servers to access cloud APIs, they require explicit opt-in read filters, run on ambient credentials without scoping, offer no built-in verification, and trust third-party MCP implementations with your credentials. Cynative flips this model:

   • Throughput: One action per MCP call vs. sandboxed code that fans out calls concurrently, achieving faster answers at lower token cost.
   • Verification: Unverified MCP output vs. Cynative’s verifier that cross-checks every finding against live evidence.
   • Read-Only by Default: MCP agents rely on opt-in filters that can be bypassed; Cynative’s action-gate is always on, fails closed, and enforces read-only policies at both the application and IAM layers.
   • Credential Scoping: MCP agents use ambient credentials unchanged; Cynative re-vends STS tokens scoped to a read-only policy.
   • Supply Chain Risk: Third-party MCPs and skills running with your credentials vs. one open-source binary with built-in connectors.
   • Audit Trail: Scattered session logs vs. fail-closed JSONL audit log that aborts if recording fails.

2. Key Innovation: Action-Gate + Sandboxed Code Execution
   The most innovative aspect is the combination of a per-call IAM action resolver with a sandboxed JavaScript runtime. The action-gate proactively resolves every API operation to its required IAM actions using the provider’s own unmodified API definitions, then authorizes against a read-only policy before any credential attaches. This means even if the model is jailbroken or prompts contain malicious instructions, the underlying cloud resources remain protected. Meanwhile, the sandboxed JavaScript execution allows the agent to perform arbitrarily complex research tasks (e.g., paginating through all AWS regions, checking every S3 bucket’s public block settings concurrently) without issuing hundreds of sequential tool calls, dramatically improving speed and reducing LLM token costs.

Frequently Asked Questions (FAQ)

1. Is Cynative truly read-only? Can it ever modify my infrastructure?
   Yes, Cynative is read-only by construction. Every API call is resolved to its required IAM actions using the provider’s own API definitions. Those actions are authorized against a read-only policy (e.g., AWS SecurityAudit, GCP roles/viewer) before any credential is attached. The gate fails closed: if an action is classified as a write (or unknown), the call is denied. AWS assumed-role identities also get STS-scoped credentials enforcing the same boundary. The sandbox has no host network or filesystem access. Even if the LLM intends to modify infrastructure, the action-gate and sandbox prevent it.

2. What LLM providers does Cynative support?
   Cynative supports Anthropic, OpenAI, Azure OpenAI, Amazon Bedrock, Google Vertex/Gemini, Cohere, Mistral, Groq, Ollama, vLLM, and many more via the embedded Bifrost SDK. You configure the provider and model via environment variables (e.g., CYNATIVE_LLM_PROVIDER=anthropic, CYNATIVE_LLM_MODEL=claude-opus-5) or a YAML config file for advanced settings like multi-key load balancing, custom retry behavior, and proxy configuration.

3. How does Cynative handle credentials? Does it store them?
   Cynative never stores credentials. It uses the credentials already present in your shell environment (the same ones used by aws cli, gcloud, az, kubectl, etc.). For AWS, if you assume a role, Cynative re-vends temporary credentials via STS AssumeRole scoped to a read-only policy, so the boundary is enforced by AWS IAM as well. The tool respects your existing session tokens and environment variables (e.g., AWS_PROFILE, GOOGLE_APPLICATION_CREDENTIALS).

4. Can I use Cynative in CI/CD pipelines or automated scheduled scans?
   Yes. Use the --print (-p) flag for non-interactive runs, and --auto-approve to skip manual approval prompts (since there’s no controlling terminal). You can set resource limits (max_total_tokens, max_iterations, etc.) via environment variables to control cost and duration. The fail-closed audit log ensures every action is recorded, making it suitable for automated compliance scanning workflows.

5. How does Cynative compare to tools like ScoutSuite, Prowler, or CloudSploit?
   Traditional cloud security scanners (ScoutSuite, Prowler, CloudSploit) are static checklists that run predefined rules and produce a list of findings. Cynative is an interactive AI research agent that can answer arbitrary, nuanced security questions using natural language. It reasons across multi-cloud and CI/CD pipelines, can create custom queries on the fly (e.g., “trace this IAM permission back to the PR where it was granted”), and provides evidence-backed, verifiable answers. While rule-based scanners are still useful for standard compliance benchmarks, Cynative excels at exploratory security research, ad-hoc investigations, and understanding complex attack paths.