Under your control
Open source · Apache-2.0

45 built-in agents.

Each one is a reviewed methodology.

Run it, print it, copy it, edit it. The file the binary runs is the file you see.

45 agents · 5 platforms
$ cynative agents list $ cynative agents show <name> $ cynative --agent <name>

Privilege escalation · 5

  • AWSaws-privilege-escalationMap the paths from each AWS IAM principal to administrative control, naming the calls that walk each one.
  • Azureazure-privilege-escalationMap the Azure principals that can grant themselves further access, and report the scope each one holds it at.
  • AWSaws-metadata-theftDetermine which EC2 instances expose their instance profile through the metadata service, and what each of those roles reaches.
  • Kubernetesk8s-pod-privilegeDetermine which pods reach their node, what that node holds and which pod specifications carry literal secret values.
  • GitHubgithub-org-accessDetermine who holds write access across a GitHub organization and how an outside identity could obtain it.

Network exposure · 5

  • AWSaws-network-exposureDetermine which AWS network paths from the internet complete end to end, and what the identity attached to each exposed resource reaches.
  • Azureazure-network-exposureResolve the effective inbound NSG rules per interface and report the ones reaching a running machine, with that machine's managed identity.
  • GCPgcp-network-exposureExpand GCP firewall rules to the instances they actually select, and report what each reachable instance's service account holds.
  • AWSaws-perimeter-bypassFind AWS Network Firewall and WAF deployments that pass traffic without inspecting it, and the subnets whose routes bypass them.
  • Azureazure-appservice-exposureDetermine how code and requests reach Azure App Service and Function apps, and what each app's managed identity holds.

Data and storage exposure · 7

  • AWSaws-public-storageResolve effective public and cross-account access to S3 buckets, Multi-Region Access Points, ECR repositories and Glacier vaults.
  • AWSaws-public-datastoresDetermine which AWS managed data services answer from public DNS and what authentication stands in front of each.
  • Azureazure-public-datastoresDetermine which Azure SQL, MySQL, PostgreSQL, Cosmos DB and Databricks deployments admit outside connections and what authenticates them.
  • Azureazure-storage-exposureResolve effective access to each Azure storage account across anonymous blob access, shared keys, the network rule set and Entra roles.
  • GCPgcp-public-bindingsFind GCP resources granting allUsers or allAuthenticatedUsers, and establish what each public binding permits.
  • AWSaws-policy-exposureClassify every non-storage AWS resource policy as anonymous, external-account or internal, and resolve the outside accounts each one names.
  • AWSaws-snapshot-exposureDetermine which AWS snapshots, AMIs and SSM documents are shared outside the account, whether the share is usable and what the source held.

Credentials and secrets · 5

  • AWSaws-credential-exposureAssess AWS root credentials, IAM user MFA state and long-lived access keys against what each one reaches.
  • AWSaws-hardcoded-secretsFind credentials sitting in AWS resource configuration and bound what each one reaches using the account's own APIs.
  • GCPgcp-static-credentialsFind GCP service accounts holding broad roles with exportable keys, the impersonation chains between them and API keys with no restriction.
  • Azureazure-keyvault-exposureDetermine the shortest path to each Azure Key Vault's contents, whether the read would be recorded and whether the vault can be purged.
  • Kubernetesk8s-self-managed-cluster-secretsDetermine what can read a self-managed Kubernetes cluster's etcd directly, and whether an encryption provider is configured for the secrets in it.

Supply chain and CI · 5

  • GitHubgithub-workflow-trustFind GitHub Actions workflows that run untrusted code with credentials, and resolve what those credentials reach.
  • AWSaws-supply-chainFind the CodeBuild, CodeArtifact, Lambda layer and CDK paths that admit code or a build trigger from outside an AWS account, and resolve what each build role reaches.
  • Azureazure-supply-chainDetermine who can push to each Azure container registry, which workloads pull from it and what the running images carry.
  • GitHubgithub-branch-protectionDetermine which GitHub repositories permit a merge without effective review, and which of those deploy or publish.
  • GitHubgithub-unpatched-dependenciesFind dependencies with a known advisory still shipping from this organization's repositories, and which of them a fix already exists for.

Detection and audit coverage · 4

  • AWSaws-detection-coverageFind the AWS regions and alarm paths where activity would generate no signal that reaches anyone.
  • Azureazure-detection-coverageFind the Azure subscriptions, regions and alert paths where activity would produce no signal that reaches anyone.
  • GCPgcp-audit-coverageDetermine which activity in a GCP organization would go unrecorded, from the audit configuration each project carries, its load balancer logging and its asset inventory.
  • AWSaws-behavior-anomaliesFind the CloudTrail escalation and enumeration sequences that depart from what the principal running them normally does, and explain what changed.

Inference exposure · 3

  • AWSaws-inference-exposureDetermine who can invoke Bedrock model endpoints in an AWS account, what a hijacked one reaches and whether abuse would appear in the call record.
  • Azureazure-inference-exposureDetermine which Azure OpenAI accounts and AI Search services are reachable from outside the subscription and what a caller reaching one obtains.
  • GCPgcp-inference-exposureDetermine which Vertex AI endpoints grant prediction outside the organization and which API keys reach the Generative Language API unrestricted.

Kubernetes control plane · 5

  • Kubernetesk8s-self-managed-apiserver-accessDetermine who can reach a self-managed Kubernetes cluster's API server, as which identity and what its admission chain accepts.
  • Kubernetesk8s-self-managed-kubelet-accessDetermine whether a kubelet in a self-managed Kubernetes cluster can be reached directly and what it requires before executing in a pod.
  • Kubernetesk8s-self-managed-controller-exposureCheck a self-managed Kubernetes cluster's controller manager and scheduler for exposed endpoints and for credentials shared across every controller.
  • Azureazure-aks-exposureDetermine who can reach each AKS API server and which Azure principals can retrieve its static cluster-admin credential.
  • AWSaws-container-isolationDetermine which running ECS tasks cross the boundary to the host that runs them, what the container instance behind each one reaches, and which EKS clusters carry no cluster security group.

Hardening and resilience · 6

  • AWSaws-unpatched-workloadsRank AWS workloads on unsupported versions by network reachability and by what the Inspector findings against them report.
  • AWSaws-data-encryptionDetermine which unencrypted AWS data can leave the service boundary, and where a KMS key policy is no narrower than the service permission behind it.
  • AWSaws-transport-encryptionReport AWS services carrying traffic without TLS against the CIDRs admitted to their ports, together with the certificates behind them.
  • AWSaws-destruction-resilienceDetermine what in an AWS account could be destroyed with no recoverable copy, starting with the keys already scheduled for deletion.
  • AWSaws-domain-takeoverFind AWS DNS records and resource references whose target no longer exists in the account, and registered domains without transfer lock.
  • Azureazure-vm-hardeningDetermine the paths to a session on each Azure virtual machine or to the contents of its disks, and what each path requires.
I

Write your own.

An agent is a markdown file: YAML frontmatter with one key, description, then the prompt body. The filename is the name.

Agent md file · example
---
description: Agent description.
---

Security deep research task.

Two sources, first match wins

Agents are read from ~/.cynative/agents/ and then from the set built into the binary. A user file shadows a built-in of the same name. Give your copy a distinct name to keep both.

Text, not privilege

Approvals, connector authorization and the read-only ceilings are enforced at every tool call regardless of what the agent says. The LLM can neither introduce nor select an agent, and with an agent selected, piped stdin is treated as untrusted input.

Start from a built-in
$ mkdir -p ~/.cynative/agents $ cynative agents show aws-public-datastores > ~/.cynative/agents/my-version.md

The agent file format ↗

II

Run it.

$ cynative --agent my-version
III

Or just ask your infrastructure anything.

  • cynative "what in my cloud is publicly exposed that shouldn't be?"
  • cynative "which IAM roles can escalate to admin?"
  • cynative "high-risk cloud permissions, trace each to the PR where it was granted"
  • cynative "cloud credentials leaked in source code and their current blast radius"
  • cat main.tf | cynative "review this Terraform for misconfigurations"
Cynative