runeward

Le harnais de gouvernance open source pour les agents IA.

Placez une politique exécutoire, des approbations humaines, une exécution isolée, des budgets et des preuves signées autour de n'importe quel agent IA. Runeward fonctionne avec un agent ou un framework multi-agents existant plutôt que d'exiger un nouveau modèle ou une nouvelle pile d'orchestration.

Prouvez-le en une commande

Prérequis : un moteur Docker/Podman en cours d'exécution et le binaire runeward.

runeward quickstart

La commande crée .runeward/quickstart.toml, vérifie la politique, le runtime, l'image et le chemin d'état, exécute une commande autorisée, prouve qu'une commande destructrice est refusée avant exécution, et vérifie la piste d'audit signée. Elle n'écrase jamais une politique existante sauf si --force est passé.

doctor et l'état de préparation du tableau de bord résolvent également les sources de secrets requises. Une Charte qui référence une valeur env:// non définie n'est pas présentée comme prête au lancement.

runeward doctor quickstart                     # explique les problèmes de configuration en toute sécurité
runeward --config-dir .runeward serve          # tableau de bord + API REST gouvernée
runeward evidence export quickstart -o run.json
runeward evidence verify run.json              # vérification indépendante de la politique/de l'audit

Ce que Runeward ajoute

Chaque action gouvernée suit un seul chemin :

agent request → policy → human approval when required → limits → sandbox → signed audit event

Nommage

La documentation et l'interface utilisent d'abord des termes familiers. Les chemins d'API et les champs de fichiers existants conservent leurs noms thématiques d'origine pour la compatibilité.

Voir la convention complète de nommage et de rédaction.

Installation

Choisissez le paquet qui correspond à votre utilisation de Runeward :

Pour un usage local normal, installez la CLI avec Homebrew. Pour une intégration d'agent, installez également le SDK correspondant à son langage. Les paquets pip et npm se connectent à une API Runeward en cours d'exécution ; ils ne remplacent pas la CLI/le runtime.

Homebrew — CLI

Les bacs à sable locaux nécessitent un moteur Docker, OrbStack ou Podman en cours d'exécution.

brew install Runewardd/tap/runeward
runeward version
runeward quickstart

pip — SDK Python

Nécessite Python 3.9 ou plus récent. Le client de base n'a aucune dépendance d'exécution tierce.

python -m pip install runeward
python -c "import runeward; print(runeward.__version__)"

npm — SDK TypeScript

Nécessite Node.js 18 ou plus récent.

npm install @runeward/sdk
npm ls @runeward/sdk

Voir Adapters pour les options d'installation de LangChain, CrewAI, LlamaIndex, OpenAI Agents, Strands, Vercel AI SDK et LangChain.js.

Autres options d'installation de la CLI

L'installateur signé macOS/Linux nécessite cosign afin de pouvoir échouer en mode fermé lors de la vérification du manifeste de sommes de contrôle. Les binaires Windows sont disponibles dans les Releases.

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

Pour compiler la branche main actuelle, utilisez Go 1.26.6 :

git clone https://github.com/Runewardd/runeward
cd runeward
go build -o bin/runeward ./cmd/runeward
./bin/runeward version

Utilisez-le avec un agent

Exposez des outils gouvernés à un IDE ou un agent compatible MCP :

{
  "mcpServers": {
    "runeward": {
      "command": "runeward",
      "args": ["mcp", "--config-dir", ".runeward"]
    }
  }
}

Ou placez une CLI d'agent dans un bac à sable et exécutez un ou plusieurs workers gouvernés :

runeward cohort --agent claude --model sonnet build "Build a tested API"

Des adaptateurs sont inclus pour LangChain, CrewAI, LlamaIndex, OpenAI Agents, Strands, Vercel AI SDK et LangChain.js. Voir Adapters et groupes d'agents.

Le tableau de bord dispose également d'un TTY Live chat en lecture seule pour chaque Citadel. Les harnais d'agents publient les tours user, assistant, tool et system avec runeward_publish_conversation (ou les équivalents REST, Python et TypeScript), et les coéquipiers autorisés peuvent suivre la conversation expurgée sans accès en saisie au terminal. Runeward ne peut pas déduire le texte de chat privé d'une interface que le client d'agent ne publie pas ; câblez l'appel de publication dans le rappel de tour du harnais. Le publieur doit se connecter au même plan de contrôle runeward serve que le tableau de bord (via /mcp, REST ou un SDK).

Harnacher les agents et sous-agents

Runeward est la frontière d'application autour d'un agent, pas le composant qui décide comment l'agent raisonne. Faites passer les appels d'outils d'un agent parent et de chaque sous-agent délégué par Runeward pour leur donner des frontières explicites de politique, d'approbation, d'isolation, de budget et de preuves.

Les concepts existants conservent leur sens : une Cohort est un groupe de workers pairs partageant un tableau de tâches ; elle n'est pas renommée en « sous-agents ». L'orchestrateur décide toujours quand déléguer, tandis que Runeward enregistre la lignée parent/exécution/fournisseur et empêche un Citadel enfant d'élargir le locataire ou la Charte de son parent. Chaque agent participant peut recevoir son propre Citadel et sa propre Chronicle. Voir Harnachement d'agents.

Flux de travail des politiques

Les politiques prennent en charge les règles glob intégrées, CEL, OPA/Rego et les bundles OCI signés. Testez-les en CI, partez d'un squelette revu, ou dérivez des propositions exactes à partir de preuves de production vérifiées :

runeward policy scaffold package-approval
runeward policy test quickstart --case 'tool=shell,action=rm -rf /,expect=deny'
runeward policy learn run.json > proposed-policy.toml

policy learn ne modifie jamais automatiquement une politique. Il vérifie d'abord les preuves, ignore les actions expurgées, produit des correspondances exactes, et exige qu'un humain les examine et les élargisse.

Posture de sécurité

• Le serveur se lie à la boucle locale par défaut et exige une authentification avant toute liaison non locale.
• Le HTTP non local exige également TLS, sauf si --allow-insecure-http reconnaît explicitement qu'un proxy inverse de confiance termine le TLS.
• Le RBAC multi-principaux limite les bacs à sable, les groupes d'agents, les instantanés de récupération et les vues du tableau de bord à leur locataire tout en attribuant chaque opération à son acteur. Les jetons statiques et les JWT OIDC utilisent le même modèle d'autorisation, et le MCP HTTP intégré partage les contrôles de propriété REST.
• L'automatisation du navigateur est expérimentale et désactivée par défaut. Activez-la uniquement dans un déploiement de confiance avec RUNEWARD_ENABLE_EXPERIMENTAL_BROWSER=1 après avoir examiné le modèle de sécurité. Les Chartes compatibles navigateur déclarent capabilities = ["browser"] ; le tableau de bord expose alors les actions gouvernées de rendu texte et de capture d'écran et leurs résultats de politique/sortie réseau.
• Un IDE navigateur facultatif (code-server en cellule + proxy inverse à tickets) est également expérimental : RUNEWARD_ENABLE_EXPERIMENTAL_IDE=1, Charte [ide], cibles Dockerfile.ide ide / ide-agents, exemples ide-demo / / / . Limites : pas de politique par frappe ; pas d'interfaces Cursor/Claude Desktop/Codex en cellule ; pas de GitHub Copilot de premier ordre sur code-server. Voir et le .

Documentation

• Quickstart
• Politiques / Chartes
• API REST
• Browser IDE (proxy code-server expérimental)
• Modèle de sécurité
• Tests de bout en bout
• Site publié : runewardd.github.io/runeward

Les contributions sont les bienvenues ; voir CONTRIBUTING.md. Sous licence Apache 2.0.