cynative

Créez vos propres agents de sécurité

Framework open source pour agents de sécurité avec accès en direct et en lecture seule à votre infrastructure.

Démarrage rapide · Votre premier agent · Documentation

Interrogez votre infrastructure sur n'importe quoi. Cynative exécute des modèles de pointe sur votre code, votre cloud et votre runtime - raisonnant à travers GitHub, GitLab, AWS, GCP, Azure et Kubernetes comme un système unique - et revient avec des réponses vérifiées.```bash cynative "what in my cloud is publicly exposed that shouldn't be?"

Il écrit et exécute du code dans un sandbox éphémère, interrogeant vos API en parallèle, de sorte qu'une seule question se propage à travers toute votre pile. Chaque résultat est recoupé et retracé jusqu'à son origine.

Contrairement aux agents de codage et aux serveurs MCP, il est **en lecture seule par conception** : chaque appel est contrôlé et autorisé *avant* qu'une identité ne soit attachée - pointez-le vers la production en toute confiance.
<!-- END agent-about -->

<p align="center">
  <img src="https://assets.kitploit.com/production/public/readmes/9087/1b3db179a03479f5951d624c8adbb4890465aa86d038d3312dc9aec9801bcfb9.gif"
       alt="cynative auditant une escalade de privilèges CI vers cloud"
       width="900">
</p>

## Ce que vos agents obtiennent

- **Code-vers-runtime** : Raisonne à travers AWS, GCP, Azure, tout K8s, GitHub et GitLab
- **Sandbox** : Génère et exécute du code pour rechercher à grande échelle, sans accès réseau ni hôte propre
- **Action-gate** : Résout chaque appel en actions IAM requises et applique une politique en lecture seule avant qu'une identité ne soit attachée
- **Basé sur des preuves** : Recoupe pour vérifier chaque résultat
- **Souverain** : Un seul binaire, votre modèle, vos données restent les vôtres

## Démarrage rapide

Installez et configurez un LLM :

<!-- BEGIN quickstart-example -->```bash
brew install cynative/tap/cynative

export CYNATIVE_LLM_PROVIDER=anthropic
export CYNATIVE_LLM_MODEL=claude-opus-5
export ANTHROPIC_API_KEY=...

Il récupère les identifiants déjà présents dans votre shell. Posez-lui n'importe quelle question :```bash 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 "live cloud resources absent from IaC - drift" # starts an interactive session cat findings.json | cynative -p "triage these findings by exploitability"

## Votre premier agent

Un agent est un fichier markdown : une ligne de description, puis le prompt. Le nom du fichier est le nom de l'agent. Pour ajouter le vôtre, créez `~/.cynative/agents/` et écrivez-en un dedans. Cynative ne crée pas ce répertoire pour vous :```bash
mkdir -p ~/.cynative/agents

cat > ~/.cynative/agents/aws-public-data-stores.md <<'EOF'
---
description: Finds publicly accessible data stores in an AWS account.
---
Check S3, RDS snapshots, EBS snapshots and public AMIs for exposure.
Report each finding with the resource ARN and how it is reachable.
EOF

cynative -p --agent aws-public-data-stores

Voir docs/agents.md pour le format.

Exécution des agents```bash

cynative -p --agent aws-public-data-stores "AWS account ID 12814983572854 only" # with a task cynative -p --agent aws-public-data-stores # without cynative --agent aws-public-data-stores # seeds an interactive session

`--agent` se combine avec `-p`, `--auto-approve`, `--config` et l'entrée standard redirigée, de sorte que le même fichier s'exécute de manière interactive pendant que vous le développez et de manière non interactive une fois qu'il est stabilisé.

Les agents sont lus depuis `~/.cynative/agents/` et depuis l'ensemble intégré au binaire ; un fichier utilisateur l'emporte sur un agent intégré du même nom. `cynative agents list` affiche chaque agent avec sa source et signale les copies masquées, et `cynative agents show <name>` imprime le fichier exact qui serait exécuté.

## Un agent de codage avec des MCP ne peut-il pas faire cela ?

| | Agent de codage + MCP | Cynative |
|---|---|---|
| Débit | Une action par appel | Écrit du code sandboxé qui répartit les appels en parallèle - moins de jetons, des réponses plus rapides |
| Résultats | Sortie non vérifiée | Le vérificateur recoupe chaque résultat avec des preuves en direct |
| Lecture seule | Filtre de lecture opt-in | Activé par défaut, échec fermé - les actions IAM requises sont vérifiées par rapport à une politique d'audit de sécurité. `secretsmanager:GetSecretValue` est une action IAM *Read* : un filtre l'autorise, `SecurityAudit` la bloque |
| Identifiants | Ambients, inchangés | Session STS limitée en lecture seule - AWS applique également la frontière |
| Rayon d'impact | Votre shell, tout réseau | Le code de recherche s'exécute dans un sandbox sans accès à l'hôte, réseau limité à vos services mappés |
| Secrets | Envoyés au modèle tels quels | Masqués de la sortie de l'outil avant d'être envoyés au modèle |
| Chaîne d'approvisionnement | MCP et compétences tiers s'exécutant avec vos identifiants | Un binaire open source, connecteurs intégrés |
| Piste d'audit | Journaux de session éparpillés, au mieux | Journal JSONL à échec fermé de chaque appel d'outil - s'il ne peut pas enregistrer, il s'arrête |

Un binaire, votre point de terminaison de modèle, votre compte. Exécutez-le sur une instance dans le cloud qu'il audite, via l'inférence gérée de ce cloud, et rien ne quitte votre environnement : la sécurité de votre infrastructure, depuis votre infrastructure.

## Installation

**Homebrew** (macOS / Linux - recommandé) :```bash
brew install cynative/tap/cynative

Script d'installation (macOS / Linux - vérifie le SHA-256 du téléchargement par rapport au checksums.txt de la version, avec échec sécurisé) :```bash curl -fsSL https://raw.githubusercontent.com/cynative/cynative/main/install.sh | sh

**Windows** (Scoop) :```powershell
scoop bucket add cynative https://github.com/cynative/scoop-bucket
scoop install cynative

Mise à jour, désinstallation, détails Windows, épinglage de version et téléchargement manuel

Mise à jour / désinstallation

Méthode	Mise à jour	Désinstallation
Homebrew	`brew upgrade cynative`	`brew uninstall cynative`
Script d'installation	relancer la commande en une ligne	`curl -fsSL https://raw.githubusercontent.com/cynative/cynative/main/install.sh \| sh -s -- --uninstall`
Scoop	`scoop update cynative`	`scoop uninstall cynative`

Windows (script PowerShell) : irm https://raw.githubusercontent.com/cynative/cynative/main/install.ps1 | iex ; désinstallation avec & ([scriptblock]::Create((irm https://raw.githubusercontent.com/cynative/cynative/main/install.ps1))) -Uninstall.

Options du script d'installation : épingler une version avec CYNATIVE_VERSION=v1.0.0 ; modifier le répertoire cible avec CYNATIVE_INSTALL_DIR (par défaut ~/.local/bin, sans sudo). Le script vérifie l'attestation de la version GitHub lorsque gh est installé (avis par défaut) ; définissez CYNATIVE_REQUIRE_ATTESTATION=1 pour rendre une vérification échouée fatale. Pour une installation à haute intégrité, récupérez le script depuis un tag immuable plutôt que depuis main.

macOS (manuel) : téléchargez cynative_Darwin_arm64.pkg (Apple Silicon) ou cynative_Darwin_x86_64.pkg (Intel) depuis la page des versions et installez avec sudo installer -pkg <file> -target / (ou double-cliquez). Ceux-ci sont signés, notarisés et agrafés - aucune invite Gatekeeper au premier lancement. Les archives brutes cynative_Darwin_*.tar.gz restent disponibles pour les scripts/CI ; le premier lancement GUI d'un binaire tarball en quarantaine nécessite une connexion Internet pour la vérification de notarisation en ligne (l'utilisation en terminal/install.sh/Homebrew n'est pas affectée).

Linux / Windows (manuel) : téléchargez un binaire précompilé et checksums.txt depuis la page des versions, vérifiez le SHA-256, et placez le binaire sur votre PATH. Binaire statique unique, sans dépendances.

Vérifier une signature de version (facultatif). Les nouvelles versions fournissent checksums.txt.sigstore.json, un bundle Sigstore signant checksums.txt avec un certificat sans clé lié au workflow de publication de ce dépôt. Authentifiez le manifeste, puis vérifiez votre archive par rapport à celui-ci :```bash cosign verify-blob checksums.txt
--bundle checksums.txt.sigstore.json
--certificate-identity "https://github.com/cynative/cynative/.github/workflows/release.yaml@refs/heads/main"
--certificate-oidc-issuer "https://token.actions.githubusercontent.com"

grep cynative_Linux_x86_64.tar.gz checksums.txt | sha256sum -c - # Linux grep cynative_Darwin_arm64.tar.gz checksums.txt | shasum -a 256 -c - # macOS

```powershell
(Get-FileHash .\cynative_Windows_x86_64.zip -Algorithm SHA256).Hash.ToLower()
Select-String -Path checksums.txt -Pattern cynative_Windows_x86_64.zip

Cela couvre les archives nommées dans checksums.txt. Les installateurs .pkg sont signés avec Developer ID, notarisés et estampillés à la place, et chaque artefact est en outre couvert par l'attestation de version GitHub (gh release verify <tag>). Deux limites à connaître : cosign récupère la racine de confiance de Sigstore sur le réseau sauf si vous passez --trusted-root, et comme les noms de fichiers ne portent pas de version, la signature prouve l'origine et l'intégrité mais pas de quelle version provient un ensemble de fichiers lâches — l'URL de version ou gh release verify est ce qui lie une version.

Fournisseurs LLM

Cynative communique avec les LLM via le SDK Bifrost intégré et prend en charge presque tous les fournisseurs d'IA prêts à l'emploi (OpenAI, Anthropic, Azure OpenAI, Amazon Bedrock, Google Vertex/Gemini, Cohere, Mistral, Groq, Ollama, vLLM et plus encore). Choisissez-en un dans docs/providers/README.md et suivez le guide de ce fournisseur.

Exemples rapides

```bash # Google Vertex export CYNATIVE_LLM_PROVIDER=vertex export CYNATIVE_LLM_MODEL=gemini-3.1-pro-preview export CYNATIVE_LLM_VERTEX_PROJECT_ID=my-gcp-project export CYNATIVE_LLM_VERTEX_REGION=global # CI / no gcloud: export GOOGLE_APPLICATION_CREDENTIALS=/path/to/sa.json

OpenAI

export CYNATIVE_LLM_PROVIDER=openai export CYNATIVE_LLM_MODEL=gpt-5.6-sol export OPENAI_API_KEY=sk-...

Amazon Bedrock - AWS credential chain

export CYNATIVE_LLM_PROVIDER=bedrock export CYNATIVE_LLM_MODEL=anthropic.claude-opus-5 export CYNATIVE_LLM_BEDROCK_REGION=us-east-1

Azure OpenAI - endpoint via env, no YAML needed

export CYNATIVE_LLM_PROVIDER=azure export CYNATIVE_LLM_MODEL=my-gpt-5.6-sol export AZURE_OPENAI_API_KEY=... export CYNATIVE_LLM_AZURE_ENDPOINT=https://my-resource.openai.azure.com

Local Ollama

export CYNATIVE_LLM_PROVIDER=ollama export CYNATIVE_LLM_MODEL=nemotron-cascade-2 export CYNATIVE_LLM_OLLAMA_URL=http://localhost:11434

</details>

<details>
<summary><strong>YAML avancé</strong></summary>

Pour l'équilibrage de charge multi-clés, le comportement de nouvelle tentative personnalisé, la configuration du proxy,
ou toute autre fonctionnalité de Bifrost, écrivez un fichier YAML :```yaml
llm:
  provider: openai
  model: gpt-5.5
  api_key: env.OPENAI_API_KEY
  network_config:                 # common fields shown; see schemas.NetworkConfig for the full set
    base_url: https://my-proxy.example.com/v1
    default_request_timeout_in_seconds: 60
    max_retries: 3
    extra_headers:
      x-tenant: prod

Voir docs/providers/ pour la référence de configuration de chaque fournisseur pris en charge.

Sessions et approbations

cynative ouvre une session interactive (édition complète de ligne et historique avec les touches fléchées) ; cynative "tâche" exécute la tâche puis reste en mode interactif ; -p / --print exécute une seule tâche de manière non interactive puis se termine - pour les scripts et les pipes (par ex. cat main.tf | cynative -p "review this Terraform for misconfigurations"). Le code de sortie porte le verdict pour les scripts : 0 lorsqu'un rapport a été produit, 2 lorsque l'exécution s'est terminée sans réponse (la notice en indique la raison - itération ou budget de jetons, réponse du modèle vide ou filtrée), 130 en cas d'interruption, 143 sur SIGTERM, et 1 pour toute autre défaillance.

Cynative appelle votre pile en utilisant les identifiants déjà présents dans votre shell - il ne conserve aucun stockage d'identifiants séparé. Fournissez toujours l'identifiant le moins privilégié, en lecture seule, nécessaire.

Approbations : chaque appel d'outil attend une seule frappe : y l'exécute une fois, a autorise tous les appels ultérieurs à cet outil pour la session (les scripts s'affichent toujours avant l'exécution), toute autre touche refuse. Sans terminal de contrôle, utilisez --auto-approve.

Arrêt en cours de tâche : pendant qu'une tâche s'exécute, appuyez une fois sur Échap ou Ctrl-C pour l'arrêter proprement (l'agent termine tout appel déjà en cours, puis s'arrête et affiche ⏸ Stopped). Lorsque l'agent rencontre des erreurs ou des refus d'outils répétés, il s'arrête automatiquement, résume ce qui le bloque et demande les informations manquantes.

Complétion Bash : voir cynative completion <shell> --help pour les instructions d'installation complètes de chaque shell.

Cynative affiche un court pied de page opérationnel (durée, utilisation de jetons) sur stderr - la redirection de stdout (cynative -p "..." > out.txt) permet de conserver la réponse capturée propre. --version affiche la version, le commit, la date de build, la version de Go et la plateforme.

cynative doctor valide la configuration et l'état de préparation des connecteurs sans démarrer de session de recherche. Passez --live-llm pour également sonder le modèle configuré avec un aller-retour sans outil.

Contrôles des ressources et des coûts pour les exécutions sans surveillance

Contrôles des ressources et des coûts : pour les exécutions sans surveillance, planifiées ou à long horizon - intégrées à cron, CI ou tout déclencheur - bornez explicitement le travail. Les principaux réglages (clés de configuration / variables d'environnement) :

Clé de configuration / variable d'env	Défaut	Effet
`max_total_tokens` `CYNATIVE_MAX_TOTAL_TOKENS`	0 (illimité)	Plafond de jetons par session, partagé entre la boucle principale, les sous-agents de tâche, le vérificateur toujours actif et les suivis interactifs.
`max_iterations` `CYNATIVE_MAX_ITERATIONS`	32	Nombre maximal d'itérations d'appels d'outils de la boucle principale par tour.
`max_subagent_iterations` `CYNATIVE_MAX_SUBAGENT_ITERATIONS`	10	Nombre maximal d'itérations dans un sous-agent de tâche.
`max_consecutive_failures` `CYNATIVE_MAX_CONSECUTIVE_FAILURES`	5	Appels d'outils consécutifs sans progression avant un arrêt avec résumé (0 désactive).
`sandbox_max_concurrency` `CYNATIVE_SANDBOX_MAX_CONCURRENCY`	16	Nombre maximal d'appels d'outils simultanés dans le sandbox.

La vérification des constatations (outil verify_findings) génère des appels de modèle supplémentaires - prévoyez-les dans le budget de toute exécution qui produit des constatations.

Connecteurs

En plus des identifiants présents dans votre shell, Cynative impose la lecture seule à trois niveaux :

Réseau - chaque hôte de requête est épinglé à son service et à sa région mappés et l'adresse IP résolue est vérifiée avant la connexion - votre agent peut atteindre votre infrastructure et rien d'autre.
Porte d'action - chaque opération est résolue en ses actions IAM requises, dérivées des définitions d'API des fournisseurs eux-mêmes, puis autorisée par une politique en lecture seule avant que tout identifiant ne soit attaché : SecurityAudit (AWS), roles/viewer (GCP), Reader (Azure). La couverture suit les API cloud à mesure qu'elles évoluent, et la porte se ferme par défaut sur tout ce qu'elle classe comme une écriture. Pour Kubernetes, la politique est le rôle RBAC view actif du cluster lui-même, récupéré à l'exécution et appliqué par requête. GitHub et GitLab sont en lecture seule par défaut ; un paramètre connectors.{github,gitlab}.permissions peut autoriser l'écriture sur des catégories spécifiques lorsqu'un workflow en a besoin, appliqué par requête avant que le jeton ne soit attaché. Même en mode lecture seule, les points de terminaison de détection de secrets de GitHub restent bloqués et l'API GraphQL de GitLab est refusée.
Identifiant (AWS) - pour les identités à rôle assumé, les identifiants sont ré-émis via STS AssumeRole, limités à une politique gérée (SecurityAudit par défaut), afin qu'AWS IAM applique également la frontière. Les identités d'utilisateur IAM et de racine s'exécutent avec leurs identifiants de base, contrôlés par la porte d'action ci-dessus.

Cynative se connecte à AWS, GCP, Azure, EKS/GKE/AKS, Kubernetes auto-géré, GitHub et GitLab. Voir docs/connectors/README.md pour la découverte des identifiants, le durcissement, les limitations et les exemples spécifiques aux connecteurs.

Exécution de code et orchestration d'outils

Pour les travaux en masse - « vérifier chaque bucket S3 public », « lister les clusters EKS dans chaque région » - Cynative peut écrire et exécuter du JavaScript dans un sandbox au lieu d'émettre un appel d'outil à la fois. Les outils de l'agent (par ex. http_request) sont exposés comme des fonctions JavaScript async, afin qu'il boucle, filtre et enchaîne les appels dans le code - et exécute les appels indépendants en parallèle avec l'assistant intégré mapConcurrent(items, fn, limit) (ou await Promise.all([...]) pour de petits ensembles fixes). Seul ce que le script console.log renvoie au modèle, ce qui maintient la recherche rapide et économe en jetons.```js // Discover regions, then list EKS clusters in every region concurrently, // following pagination - only the summary returns to the model. const r = await http_request({ method: "GET", url: "https://ec2.us-east-1.amazonaws.com/?Action=DescribeRegions&Version=2016-11-15", auth_provider: "aws", aws_auth: { service: "ec2", region: "us-east-1" }, }); const regions = [...r.body.matchAll(/([^<]+)</regionName>/g)].map((m) => m[1]);

console.log(JSON.stringify(all.filter((x) => x.clusters.length > 0), null, 2));

- **Async et concurrent** : les fonctions de l'outil renvoient des Promesses - utilisez `await` sur elles, répartissez la charge sur de nombreuses ressources avec `mapConcurrent(items, fn, limit)` (borné, préservant l'ordre), ou utilisez `await Promise.all([...])` pour de petits ensembles fixes.
- **Réponses structurées** : `http_request` se résout en `{ status, statusText, headers, body }` ; `body` est la chaîne brute - utilisez `JSON.parse(resp.body)` pour les API JSON ou lisez-la directement pour le XML.
- **Sandboxé** : un script ne peut appeler que les outils que Cynative expose - il n'a aucun accès réseau ou hôte propre.
- **Vous voyez tout le script** : chaque appel `code_execution` est affiché en entier pour approbation avant son exécution (ignorez avec `--auto-approve` ; diffusez chaque appel interne avec `-v`).
- **Avec état au sein d'une session** : les valeurs enregistrées sur `globalThis` persistent entre les appels lors d'une session interactive, tant que l'appel s'exécute jusqu'à son terme (un appel qui expire ou reste suspendu les réinitialise) ; les `let`/`const`/`var`/`function` de niveau supérieur sont limités à un seul appel.
- **Borné** : les scripts s'exécutent sous un délai d'expiration (120 s par défaut) et une taille de sortie plafonnée.

## Journal d'audit

Chaque appel d'outil est enregistré dans un journal d'audit JSONL persistant (`~/.cynative/audit.log`, activé par défaut). Le journal est en mode échec-fermé : si un appel ne peut pas être enregistré, l'exécution est interrompue. Chaque entrée d'une exécution d'agent enregistre également le nom de l'agent, la source et l'empreinte du fichier, afin qu'un résultat puisse être retracé jusqu'à l'invite exacte qui l'a produit.

Les résultats des outils sont expurgés avant d'être écrits, mais les arguments de l'invite d'approbation sont stockés textuellement - le journal peut contenir des valeurs sensibles. Il n'est lisible que par l'utilisateur qui a exécuté Cynative. La rotation et la conservation sont configurables.

Configurez sous `audit:` dans `~/.cynative/config.yaml`, ou via les variables d'environnement :

| Clé | Env | Défaut |
|---|---|---|
| `audit.enabled` | `CYNATIVE_AUDIT_ENABLED` | `true` |
| `audit.path` | `CYNATIVE_AUDIT_PATH` | `~/.cynative/audit.log` |
| `audit.max_size_mb` | `CYNATIVE_AUDIT_MAX_SIZE_MB` | `100` |
| `audit.retention_days` | `CYNATIVE_AUDIT_RETENTION_DAYS` | `30` |
| `audit.compress` | `CYNATIVE_AUDIT_COMPRESS` | `false` |

## Questions et retours

[Discussions](https://github.com/cynative/cynative/discussions) est le meilleur endroit pour partager vos retours - ce sur quoi vous l'avez pointé, ce qui est revenu, et ce qui manque. Les étoiles aident les gens à trouver le projet.

## Contribuer

Les contributions sont les bienvenues - nouveaux agents, connecteurs, ensembles de données d'évaluation et améliorations dans l'ensemble. Voir [CONTRIBUTING.md](https://github.com/cynative/cynative/blob/main/CONTRIBUTING.md) pour la configuration de développement, la passerelle `make check` et les conventions de PR, et [SECURITY.md](https://github.com/cynative/cynative/blob/main/SECURITY.md) pour signaler des vulnérabilités.

## Licence

Licence Apache-2.0. Voir [LICENSE](https://github.com/cynative/cynative/blob/main/LICENSE) pour le texte complet.

Lire plus

cynative v1.8.0

Catégories