Running Agents: Interactive, Seeded, and Print Modes

Cynative is a single-binary CLI that runs frontier LLMs over your cloud infrastructure for read-only security research. You can drive it interactively, seed it with a task, or run it non-interactively in scripts and CI pipelines — all from the same binary with the same flags.

Three ways to use Cynative

Mode	Command	When to use
Interactive session	`cynative`	Exploratory research; full line editing and history with arrow keys.
Seeded session	`cynative "task"`	Starts the task, then stays interactive so you can follow up.
Non-interactive print	`cynative -p "task"`	Scripts, CI, and pipes; runs the task, prints the answer, and exits.

# Open a bare interactive session
cynative

# Seed a session with a task, then stay interactive
cynative "live cloud resources absent from IaC - drift"

# Run a single task non-interactively and exit
cynative -p "which IAM roles can escalate to admin?"

The -p / --print flag is the key to scriptable use. When it is set, Cynative runs exactly one task and exits with a code that carries the verdict (see Exit codes below).

Running built-in agents

Cynative ships with 45 reviewed agents embedded in the binary — one for each common security question across AWS, Azure, GCP, GitHub, and Kubernetes. Pass --agent <name> to run one.

# Non-interactive: run an agent and exit
cynative -p --agent aws-network-exposure

# Interactive: seed a session with the agent's prompt
cynative --agent aws-public-datastores

# Pass an additional task alongside the agent
cynative -p --agent aws-public-datastores "AWS account 128149835728 only"

To browse the full catalog:

cynative agents list            # every agent, with its description
cynative agents show <name>     # the exact prompt that would run

A sample of what’s available:

Platform	Example agents
AWS (20)	`aws-privilege-escalation`, `aws-public-storage`, `aws-unpatched-workloads`, `aws-supply-chain`
Azure (11)	`azure-keyvault-exposure`, `azure-storage-exposure`, `azure-privilege-escalation`
GCP (5)	`gcp-public-bindings`, `gcp-static-credentials`, `gcp-inference-exposure`
GitHub (4)	`github-workflow-trust`, `github-unpatched-dependencies`, `github-branch-protection`
Kubernetes (5)	`k8s-pod-privilege`, `k8s-self-managed-apiserver-access`

You can also write your own agent in a single markdown file. Copy an existing one as a starting point:

mkdir -p ~/.cynative/agents
cynative agents show aws-public-datastores > ~/.cynative/agents/my-aws-public-datastores.md
# Edit the file, then run it:
cynative -p --agent my-aws-public-datastores

A file in ~/.cynative/agents/ wins over a built-in of the same name, so give your copy a distinct name to keep both.

Free-form questions

You don’t need a named agent. Ask any natural-language security question directly:

cynative -p "what in my cloud is publicly exposed that shouldn't be?"
cynative -p "which IAM roles can escalate to admin?"
cynative -p "high-risk cloud permissions, trace each to the PR where it was granted"
cynative -p "cloud credentials leaked in source code and their current blast radius"

Cynative reasons across AWS, GCP, Azure, Kubernetes, GitHub, and GitLab as one system, writing and running concurrent API scripts in a sandbox to gather evidence before answering.

Piping input

Use standard Unix pipes to feed Cynative data from files or other commands. In print mode (-p), Cynative reads stdin when it is not a terminal:

cat findings.json | cynative -p "triage these findings by exploitability"
cat main.tf       | cynative -p "review this Terraform for misconfigurations"

Cynative prints a short operational footer (timing, token usage) to stderr. Redirecting stdout captures only the clean answer:

cynative -p "what is publicly exposed?" > report.txt

Combining flags

All flags compose freely, so the same agent file works interactively during development and non-interactively once it’s stable:

# Full CI invocation: named agent, non-interactive, auto-approved, custom config
cynative -p --agent aws-privilege-escalation --auto-approve --config /etc/cynative/config.yaml

# Pipe stdin into a named agent in print mode
cat context.json | cynative -p --agent aws-supply-chain --auto-approve

# Verbose output — streams each inner tool-call result to stderr
cynative -p --agent k8s-pod-privilege -v

Flag	Short	Effect
`--print`	`-p`	Non-interactive; run one task and exit
`--agent <name>`		Use a named agent file as the prompt
`--auto-approve`		Skip per-call approval prompts (required when there is no controlling terminal)
`--config <path>`		Override the default config file (`~/.cynative/config.yaml`)
`--verbose`	`-v`	Stream each inner tool-call result to stderr

Exit codes

The exit code carries the verdict for scripted callers, so you can branch on outcome without parsing stdout.

Code	Meaning
`0`	A report was produced successfully.
`2`	The run completed but produced no answer (iteration or token budget reached, empty or filtered model response). The rendered notice names the specific reason.
`130`	Graceful operator interrupt (Esc / Ctrl-C, equivalent to 128 + SIGINT).
`143`	SIGTERM (128 + SIGTERM).
`1`	Any other failure (configuration error, connector error, etc.).

Example usage in a shell script:

cynative -p --agent aws-privilege-escalation --auto-approve
case $? in
  0)   echo "Report ready" ;;
  2)   echo "No answer — check token budget or iteration limits" ;;
  130) echo "Interrupted" ;;
  *)   echo "Error" ;;
esac

Resource and cost controls

For unattended, scheduled, or long-horizon runs — wired into cron, CI, or any trigger — bound the work explicitly. These knobs are set in ~/.cynative/config.yaml or via environment variable:

Config key	Env var	Default	Effect
`max_total_tokens`	`CYNATIVE_MAX_TOTAL_TOKENS`	`0` (unbounded)	Per-session token ceiling, shared across the main loop, task sub-agents, the always-on verifier, and interactive follow-ups.
`max_iterations`	`CYNATIVE_MAX_ITERATIONS`	`32`	Maximum main-loop tool-calling iterations per turn.
`max_subagent_iterations`	`CYNATIVE_MAX_SUBAGENT_ITERATIONS`	`10`	Maximum iterations inside a task sub-agent.
`max_consecutive_failures`	`CYNATIVE_MAX_CONSECUTIVE_FAILURES`	`5`	Consecutive no-progress tool calls before a halt-and-summarize. Set to `0` to disable.
`sandbox_max_concurrency`	`CYNATIVE_SANDBOX_MAX_CONCURRENCY`	`16`	Maximum concurrent in-sandbox tool calls.

Finding verification (verify_findings tool) makes extra model calls — budget for them on any run that produces findings.

Get Started

Using Cynative

Agents

Connectors

LLM Providers

Configuration

Project

Running Agents: Interactive, Seeded, and Print Modes

Three ways to use Cynative

Running built-in agents

Free-form questions

Piping input

Combining flags

Exit codes

Resource and cost controls

​Three ways to use Cynative

​Running built-in agents

​Free-form questions

​Piping input

​Combining flags

​Exit codes

​Resource and cost controls

Three ways to use Cynative

Running built-in agents

Free-form questions

Piping input

Combining flags

Exit codes

Resource and cost controls