TechLatest

Posted on Jul 23 • Originally published at Medium on Jul 22

What is Cynative? Complete Guide to AI Infrastructure Research and Cloud Security Auditing

#aisecurity #opensource #cynative #security

Modern infrastructure rarely exists in a single environment. A typical production workload may span GitHub repositories, CI/CD pipelines, cloud providers, Kubernetes clusters, identity providers, and infrastructure-as-code platforms. While this architecture improves scalability and flexibility, it also makes investigating security issues significantly more difficult.

Answering what appears to be a simple question — such as “Which IAM roles in my environment can escalate privileges?” — often requires collecting data from multiple systems, correlating the results manually, and validating whether the findings are actually exploitable. Traditional security tools usually inspect only one layer of the stack, leaving engineers to piece together the complete picture themselves.

Cynative was built to eliminate that fragmentation.

Cynative is an open-source AI infrastructure research agent that helps engineers investigate cloud infrastructure, source code, CI/CD pipelines, and runtime environments using natural language. Instead of limiting its analysis to a single repository or cloud service, it reasons across your entire infrastructure, connecting information from platforms such as AWS, Microsoft Azure, Google Cloud Platform (GCP), GitHub, GitLab, and Kubernetes to produce evidence-backed answers.

Unlike AI coding assistants that primarily generate or modify source code, Cynative is designed specifically for infrastructure research and security investigations. It focuses on understanding how different parts of your environment interact rather than writing application logic.

For example, instead of manually reviewing IAM policies, GitHub Actions workflows, Kubernetes RoleBindings, and cloud networking configurations, you can simply ask:

cynative "What in my cloud is publicly exposed that shouldn't be?"

Behind this single command, Cynative determines which systems need to be queried, generates research code, securely executes those queries in an isolated sandbox, validates every result against live infrastructure, and presents a consolidated answer with supporting evidence.

The goal is not simply to automate API calls. The goal is to help engineers understand complex infrastructure relationships that would otherwise require significant manual investigation.

Why Was Cynative Created?

Cloud-native environments have become increasingly interconnected. A deployment pipeline today might look something like this:

A developer pushes code to GitHub.
GitHub Actions starts a CI/CD workflow.
The workflow authenticates to AWS using OpenID Connect (OIDC).
An IAM role grants temporary credentials.
Containers are deployed to Amazon EKS.
Secrets are retrieved from AWS Secrets Manager.
Services become accessible through Kubernetes Ingress resources.

Each component is secure only if every link in the chain is configured correctly.

Traditional tools often analyze these systems independently. A GitHub security scanner knows about repositories, an IAM auditing tool understands cloud permissions, and a Kubernetes scanner evaluates cluster configurations. However, they generally do not reason across all of these layers as a connected system.

This creates blind spots.

A GitHub Actions workflow may appear harmless until it assumes an over-privileged IAM role. Likewise, an IAM role may seem acceptable until it is discovered that any pull request can trigger the workflow that uses it. Identifying these relationships requires correlating information from multiple platforms.

Cynative was designed to bridge these gaps by treating your infrastructure as one connected environment rather than a collection of isolated services.

How Cynative Thinks About Infrastructure

Instead of viewing infrastructure as individual APIs, Cynative builds a broader understanding of how resources are related.

For example, a security investigation may involve tracing a deployment path like this:

GitHub Repository
        │
        ▼
GitHub Actions Workflow
        │
        ▼
OIDC Trust Relationship
        │
        ▼
AWS IAM Role
        │
        ▼
Amazon EKS Cluster
        │
        ▼
Running Kubernetes Workloads

Rather than returning disconnected pieces of information, Cynative attempts to explain the complete chain of trust and identify where security risks emerge.

This approach allows engineers to investigate questions that traditionally require expertise across multiple cloud platforms and tooling ecosystems.

How Cynative Works

From the user’s perspective, Cynative behaves like a command-line research assistant. You ask a question in natural language, and it investigates your infrastructure before returning an answer.

Internally, however, the workflow is considerably more sophisticated.

Natural Language Question
            │
            ▼
Infrastructure Planning
            │
            ▼
Connector Selection
            │
            ▼
Permission Validation
            │
            ▼
Sandboxed Code Generation
            │
            ▼
Concurrent API Requests
            │
            ▼
Evidence Collection
            │
            ▼
Cross Verification
            │
            ▼
Verified Research Report

Instead of issuing one API request at a time, Cynative can generate JavaScript that performs concurrent requests across multiple services. This enables it to inspect large cloud environments more efficiently while reducing the number of interactions required with the underlying language model.

Every finding is then verified against live infrastructure before being presented, helping reduce false positives and improving confidence in the final report.

Core Capabilities of Cynative

At a high level, Cynative combines several capabilities into a single research workflow:

Natural language infrastructure research that allows engineers to ask questions instead of writing complex cloud queries.
Cross-platform reasoning across GitHub, GitLab, AWS, Azure, GCP, and Kubernetes.
Sandboxed code execution that safely performs large-scale investigations without direct access to the host system.
Parallel API orchestration for faster research across regions, repositories, clusters, and cloud accounts.
Evidence-backed verification that validates findings before presenting results.
Read-only security controls that prevent accidental infrastructure changes during investigations.
Comprehensive audit logging for traceability and compliance.

Together, these capabilities transform Cynative from a simple command-line utility into a dedicated infrastructure research platform.

Who Should Use Cynative?

Cynative is designed for teams responsible for building, operating, and securing cloud infrastructure. Depending on your role, it can support different types of investigations.

Cloud Security Engineers can identify publicly exposed resources, over-permissioned IAM roles, insecure trust relationships, and cloud configuration issues.

DevOps and Platform Engineers can investigate deployment pipelines, infrastructure drift, Kubernetes configurations, and cloud architecture without manually querying multiple services.

Site Reliability Engineers (SREs) can trace deployment paths, validate infrastructure consistency, and better understand how production systems are connected.

Security Operations (SecOps) teams can use Cynative during incident response to quickly determine the blast radius of exposed credentials, compromised identities, or misconfigured cloud resources.

Open Source Maintainers and Consultants can audit customer environments, review CI/CD pipelines, and perform infrastructure assessments while maintaining a read-only security posture.

Why Cynative Stands Out

Many AI-powered developer tools focus on generating code or interacting with a single repository. Cynative addresses a different problem: understanding infrastructure as an interconnected system.

Its architecture combines natural language reasoning, concurrent infrastructure analysis, read-only security enforcement, sandboxed execution, and evidence-backed verification into a single workflow. This enables engineers to investigate complex cloud environments without stitching together multiple scanners, scripts, or dashboards.

As organizations continue adopting multi-cloud architectures and increasingly complex deployment pipelines, tools that can reason across infrastructure — not just individual services — are becoming an important part of modern DevSecOps workflows.

Key Features of Cynative

Cynative combines AI-powered reasoning, cloud infrastructure awareness, and security-first design into a single command-line tool. Instead of acting as another cloud scanner or AI coding assistant, it researches your infrastructure by connecting information across multiple platforms and validating every finding before presenting the results.

Below are the capabilities that make Cynative different from traditional security tools and AI agents.

1. Research Your Entire Infrastructure Using Natural Language

One of Cynative’s defining features is its ability to answer infrastructure questions using natural language.

Instead of remembering dozens of cloud commands, API endpoints, or provider-specific tools, you simply describe the problem you want to investigate.

For example, you can ask questions like:

cynative "Which IAM roles can escalate to administrator?"

cynative "Find cloud resources that are publicly accessible."

cynative "Which GitHub Actions workflows deploy to production?"

cynative "Show infrastructure resources that are not managed by Terraform."

Instead of matching keywords to predefined checks, Cynative interprets the intent behind your request, determines which systems need to be queried, gathers the required data, and generates a response supported by live infrastructure evidence.

This conversational workflow makes infrastructure research significantly more approachable, particularly in environments where information is spread across multiple cloud providers and development platforms.

2. Cross-Platform Infrastructure Reasoning

Modern applications rarely exist within a single platform. A production deployment often involves source code repositories, CI/CD systems, cloud identity, Kubernetes clusters, and runtime services.

Traditional security tools usually analyze only one of these components at a time.

Cynative takes a broader approach by reasoning across your infrastructure as one connected system.

For example, a deployment chain might involve:

GitHub Repository
        │
        ▼
GitHub Actions
        │
        ▼
OIDC Authentication
        │
        ▼
AWS IAM Role
        │
        ▼
Amazon EKS
        │
        ▼
Running Containers

Rather than producing separate reports for each service, Cynative follows these relationships to explain how changes in one system can affect another.

This ability to correlate infrastructure components is particularly valuable during security investigations, incident response, and cloud architecture reviews.

3. Support for Multiple Cloud Platforms

Cynative is designed for organizations operating across hybrid and multi-cloud environments.

Instead of being tied to a single provider, it supports infrastructure research across major cloud ecosystems, including:

| Platform | Supported |
| --------------------------- | --------- |
| Amazon Web Services (AWS) | ✅ |
| Microsoft Azure | ✅ |
| Google Cloud Platform (GCP) | ✅ |
| Kubernetes | ✅ |
| Amazon EKS | ✅ |
| Azure AKS | ✅ |
| Google GKE | ✅ |
| GitHub | ✅ |
| GitLab | ✅ |

This unified approach allows engineers to investigate infrastructure without switching between different vendor-specific tools.

4. Secure Read-Only Architecture

Many AI agents are capable of modifying infrastructure once they receive credentials.

While this enables automation, it also introduces operational risk, especially in production environments.

Cynative follows a fundamentally different philosophy.

It is designed to research infrastructure without changing it.

Before any request reaches a cloud provider or development platform, Cynative validates whether the requested operation complies with its read-only security policy.

If an operation requires write permissions, it is blocked before credentials are attached.

This design significantly reduces the risk of accidental infrastructure changes during investigations while allowing teams to safely analyze production environments.

5. Evidence-Backed Verification

One of the biggest concerns with AI-generated answers is reliability.

Language models can occasionally produce incomplete or inaccurate responses if they rely solely on reasoning.

Cynative addresses this challenge by verifying findings against live infrastructure before presenting them to the user.

Instead of saying:

“This IAM role appears to have administrator privileges.”

Cynative attempts to validate that statement using actual cloud APIs and supporting evidence.

The result is a research workflow where conclusions are backed by infrastructure data rather than assumptions.

This verification process improves confidence in security assessments and helps reduce false positives.

6. Parallel Infrastructure Research

Large cloud environments often contain thousands of resources distributed across multiple accounts and regions.

Querying each resource sequentially can take a considerable amount of time.

Cynative improves performance by generating research code capable of executing API requests concurrently.

For example, instead of inspecting every AWS region one after another, it can query multiple regions simultaneously, collect the results, and merge them into a single report.

Conceptually, the workflow looks like this:

Traditional Approach

Region A
   │
Region B
   │
Region C
   │
Region D
   │
Complete

Cynative

Region A ─┐
Region B ─┤
Region C ─┼──► Combined Results
Region D ─┘

This concurrent execution model enables Cynative to research large infrastructures more efficiently while reducing unnecessary interaction with the underlying language model.

7. Sandboxed Code Execution

Some infrastructure investigations require hundreds of API calls.

Rather than issuing every request individually, Cynative can generate JavaScript that performs the required research inside an isolated execution environment.

The generated code can:

Query cloud APIs
Process responses
Filter resources
Handle pagination
Aggregate findings
Execute concurrent operations

The sandbox itself is intentionally restricted.

It does not provide unrestricted access to the local filesystem, arbitrary internet resources, or third-party packages. Instead, it exposes only approved infrastructure tools required to perform the requested research.

This approach combines flexibility with stronger security boundaries.

8. Built-in Audit Logging

Security investigations often require traceability.

To support auditing and compliance, Cynative records every approved tool invocation in a persistent JSON Lines (JSONL) audit log.

Each entry contains details about the executed operation, making it possible to review infrastructure research performed during previous sessions.

The logging system is designed with a fail-closed approach.

If Cynative cannot safely record a tool invocation, the operation is aborted instead of continuing without an audit trail.

This behavior helps organizations maintain accountability when investigating sensitive production environments.

9. Local Execution and Data Control

Unlike cloud-hosted AI platforms that require uploading infrastructure data to external services, Cynative runs locally within your own environment.

It uses the credentials already available in your shell and communicates directly with your cloud providers through built-in connectors.

This architecture offers several advantages:

Infrastructure credentials remain under your control.
Research executes within your own environment.
Organizations can choose their preferred LLM provider.
Local model providers such as Ollama and vLLM are supported for teams with strict data residency requirements.

For organizations operating under compliance frameworks or internal security policies, local execution provides greater control over infrastructure analysis workflows.

10. Support for More Than 20 AI Providers

Cynative integrates with the Bifrost SDK, allowing users to select from more than twenty supported language model providers.

Supported providers include:

Anthropic
OpenAI
Google Gemini
Azure OpenAI
Amazon Bedrock
Google Vertex AI
Cohere
Groq
Mistral AI
Ollama
vLLM
and many others.

This flexibility allows teams to choose models based on performance, pricing, privacy requirements, or deployment preferences without changing how they interact with Cynative.

Feature Summary

The table below summarizes Cynative’s primary capabilities.

| Feature | Description |
| ------------------------- | ---------------------------------------------------------------------------- |
| Natural Language Research | Ask infrastructure questions using plain English. |
| Multi-Cloud Support | Research AWS, Azure, GCP, Kubernetes, GitHub, and GitLab from one interface. |
| Read-Only Security Model | Blocks write operations before credentials are attached. |
| Evidence Verification | Validates findings against live infrastructure before reporting them. |
| Parallel API Execution | Performs concurrent infrastructure research for improved performance. |
| Sandboxed Execution | Runs generated research code inside an isolated environment. |
| Audit Logging | Records approved tool calls in a persistent JSONL audit log. |
| Local Execution | Runs within your environment using existing credentials. |
| Multiple LLM Providers | Supports more than 20 commercial and self-hosted AI providers. |

By combining these capabilities, Cynative goes beyond traditional infrastructure scanners or AI coding assistants. It provides a unified way to investigate cloud environments, correlate findings across platforms, and produce evidence-backed answers while maintaining a security-first, read-only design.

Installing Cynative

Cynative is distributed as a command-line interface (CLI) and supports macOS, Linux, and Windows. Once installed, it can connect to your preferred large language model (LLM) provider and securely interact with cloud platforms such as AWS, Azure, Google Cloud Platform (GCP), GitHub, GitLab, and Kubernetes using the credentials already available in your local environment.

Unlike many AI-powered developer tools that require cloud-hosted services or proprietary dashboards, Cynative runs locally. This gives you greater control over authentication, infrastructure access, and model selection while keeping your research workflow within your own environment.

Before installing Cynative, make sure your system meets the following requirements.

Prerequisites

You’ll need the following before getting started:

A supported operating system (macOS, Linux, or Windows)
Internet connectivity for installation and API access
An API key from a supported LLM provider (such as Anthropic, OpenAI, or Gemini)
Cloud credentials configured locally if you plan to research AWS, Azure, GCP, GitHub, GitLab, or Kubernetes environments

Note: Cynative does not maintain its own credential store. Instead, it uses the credentials already configured in your terminal session, allowing you to continue using your existing authentication workflows.

Install Cynative on macOS and Linux

The recommended installation method for macOS and Linux is Homebrew.

Run the following command:

brew install cynative/tap/cynative

Homebrew automatically downloads and installs the latest stable version of the Cynative CLI along with any required dependencies.

Once the installation completes, verify that Cynative is available by checking its version.

cynative --version

If the installation was successful, you’ll see output similar to:

cynative version x.x.x
commit: abc123
build date: YYYY-MM-DD
go version: go1.xx
platform: darwin/arm64

The exact version information will vary depending on the release you’ve installed.

Install Using the Official Installation Script

If you don’t use Homebrew, Cynative also provides an official installation script for macOS and Linux.

Run:

curl -fsSL https://raw.githubusercontent.com/cynative/cynative/main/install.sh | sh

One advantage of the official installer is that it verifies the downloaded binary against the published SHA-256 checksums before completing the installation. If verification fails, the installation is aborted to help prevent tampered or corrupted downloads.

Install Cynative on Windows

Windows users can install Cynative using Scoop.

First, add the Cynative bucket:

scoop bucket add cynative https://github.com/cynative/scoop-bucket

Then install the CLI:

scoop install cynative

After installation, verify that the CLI is available.

cynative --version

Verify Your Installation

Before connecting any cloud providers or LLMs, it’s a good idea to verify that the installation completed successfully.

Run:

cynative doctor

The doctor command checks your local configuration and validates that Cynative is correctly installed. It can also identify missing dependencies or connector configuration issues before you begin using the tool.

Running this command after installation can save time when troubleshooting authentication or environment configuration problems.

Configure an LLM Provider

After installing Cynative, the next step is configuring a Large Language Model (LLM). The model is responsible for understanding your natural language prompts, planning infrastructure investigations, generating research code, and summarizing verified findings.

Unlike many AI-powered developer tools that are tied to a single provider, Cynative supports more than 23 commercial and self-hosted LLM providers through its embedded Bifrost SDK. This gives organizations the flexibility to choose a model based on performance, privacy requirements, deployment preferences, or cost.

Some of the supported providers include:

Anthropic
OpenAI
Google Gemini
Azure OpenAI
Amazon Bedrock
Google Vertex AI
Groq
Cohere
Mistral AI
Ollama
vLLM
Together AI
And many more

This flexibility means you can use cloud-hosted frontier models such as Claude or GPT-5, or run everything locally using Ollama or vLLM without sending prompts to external APIs.

Configure Anthropic

If you plan to use Anthropic Claude models, export the following environment variables.

export CYNATIVE_LLM_PROVIDER=anthropic
export CYNATIVE_LLM_MODEL=claude-fable-5
export ANTHROPIC_API_KEY=YOUR_API_KEY

You can also replace claude-fable-5 with any supported Claude model available through Anthropic.

Configure OpenAI

To use OpenAI models, configure the provider as shown below.

export CYNATIVE_LLM_PROVIDER=openai
export CYNATIVE_LLM_MODEL=gpt-5
export OPENAI_API_KEY=YOUR_API_KEY

Configure Ollama (Local Models)

If you prefer running everything locally, Cynative integrates directly with Ollama.

First, make sure Ollama is installed and running on your machine.

Verify your available models:

ollama list

Example output:

NAME SIZE
qwen2.5:7b 4.7 GB
gemma4:31b 19 GB

Next, configure Cynative to use your local Ollama instance.

export CYNATIVE_LLM_PROVIDER=ollama
export CYNATIVE_LLM_MODEL=qwen2.5:7b
export CYNATIVE_LLM_OLLAMA_URL=http://localhost:11434

Replace the model name with the one installed on your system.

Using Ollama allows infrastructure research to remain entirely within your local environment, making it an attractive option for organizations with strict security or compliance requirements.

Verify Your Configuration

After configuring your preferred provider, verify everything is working correctly.

Run:

cynative doctor

A successful configuration should display information about your configured provider and available connectors.

For example:

Connectors
✓ github
✓ aws

LLM
✓ Provider: ollama
✓ Model: qwen2.5:7b

If any connector or provider is misconfigured, the doctor command reports the issue along with guidance on how to resolve it before you begin your research session.

Start an Interactive Session

Launching Cynative without any arguments starts an interactive research session.

cynative

From here, you can ask infrastructure questions using natural language.

For example:

Which IAM roles can escalate to administrator?

Find publicly accessible cloud resources.

Review my GitHub Actions workflows for security issues.

Show infrastructure resources that are not managed by Terraform.

Unlike traditional command-line tools, you don’t need to remember provider-specific commands or API endpoints. Instead, you describe what you want to investigate, and Cynative determines which connectors and APIs are required.

Execute a Single Query

If you only need an answer to one question, you can execute it directly from the command line.

cynative "List all repositories in my GitHub account"

cynative -p "List all repositories in my GitHub account"

The -p (print) option is especially useful for shell scripts, automation, and CI/CD pipelines because it prints the result and exits immediately.

Understanding Tool Approval Prompts

One of Cynative’s most important security features is its approval system.

Before making any authenticated API request, Cynative shows the exact request it intends to execute.

For example, when I asked it to list my GitHub repositories, it displayed the following tool call:

{
  "method": "GET",
  "url": "https://api.github.com/user/repos",
  "auth_provider": "github"
}

It then prompted me with:

Execute? [y]es once / [a]ll this session / [N]o

This approval mechanism gives you complete visibility into every authenticated action before it is executed.

You have three options:

y — Approve only the current request.
a — Approve all future requests made by the same tool during the current session.
N — Deny the request.

This extra confirmation step helps prevent unintended API calls while giving users full control over how Cynative interacts with their infrastructure.

Example Output

After approving the request, Cynative queried the GitHub API using my existing credentials and returned details about the repositories it could access, including repository names, owners, descriptions, primary languages, stars, forks, and recent activity.

This demonstrates how Cynative combines natural language understanding with authenticated API calls to transform a simple question into a structured, evidence-backed response.

Notes on Local Models

For this guide, I used Ollama with the Qwen2.5 7B model. While it works for local experimentation, smaller models may occasionally produce less focused reasoning or require additional iterations for more complex investigations.

If you’re working with larger cloud environments or conducting advanced security research, you’ll generally get better results with stronger reasoning models, whether self-hosted or cloud-based.

Conclusion

Modern cloud infrastructure is more interconnected than ever. A single deployment can involve GitHub repositories, CI/CD pipelines, cloud providers, Kubernetes clusters, identity systems, and infrastructure-as-code, making security investigations increasingly complex. Understanding how these components interact often requires switching between multiple tools, APIs, and dashboards before you can even begin analyzing the actual problem.

Cynative takes a different approach.

Instead of treating each platform as an isolated system, it researches your infrastructure as a connected ecosystem. By combining natural language understanding, cross-platform reasoning, sandboxed code execution, concurrent API orchestration, evidence-backed verification, and a security-first read-only architecture, Cynative helps engineers answer complex infrastructure questions from a single command-line interface.

Whether you’re auditing IAM permissions, reviewing GitHub Actions workflows, identifying publicly exposed resources, investigating Kubernetes RBAC configurations, or tracing OIDC trust relationships, Cynative provides a faster and more structured way to understand what’s happening across your environment.

Another notable advantage is its flexibility. You can choose from more than 20 supported LLM providers — including cloud-hosted models such as Claude and GPT or self-hosted options like Ollama and vLLM — allowing you to balance performance, privacy, and deployment requirements according to your organization’s needs.

While no AI tool replaces sound security practices or human expertise, Cynative can significantly reduce the time spent gathering information and correlating findings across multiple systems. For platform engineers, DevOps teams, cloud security professionals, and incident responders, it offers a practical way to investigate modern infrastructure using natural language while maintaining strong security boundaries.

As cloud environments continue to grow in scale and complexity, tools that can reason across code, cloud, identity, and runtime resources will become increasingly valuable. Cynative represents an interesting step in that direction by combining AI-assisted infrastructure research with verifiable evidence and a security-focused design.

If you’re looking for a way to simplify cloud investigations, improve infrastructure visibility, or strengthen your DevSecOps workflow, Cynative is worth exploring. Install it, connect it to your preferred LLM provider, and start asking questions about your infrastructure — you may discover insights that would have taken hours to uncover manually.