runeward

Der Open-Source-Governance-Harness für KI-Agenten.

Legen Sie durchsetzbare Richtlinien, menschliche Genehmigungen, isolierte Ausführung, Budgets und signierte Nachweise um jeden KI-Agenten. Runeward funktioniert mit einem bestehenden Agenten- oder Multi-Agenten-Framework, ohne dass ein neues Modell oder ein neuer Orchestrierungs-Stack erforderlich ist.

In einem Befehl nachweisen

Voraussetzungen: eine laufende Docker/Podman-Engine und die runeward-Binärdatei.

runeward quickstart

Der Befehl erstellt .runeward/quickstart.toml, prüft die Richtlinie, Laufzeit, das Image und den Statuspfad, führt einen erlaubten Befehl aus, weist nach, dass ein destruktiver Befehl vor der Ausführung verweigert wird, und verifiziert den signierten Audit-Trail. Eine bestehende Richtlinie wird niemals überschrieben, es sei denn, --force wird übergeben.

doctor und die Bereitschaft des Dashboards lösen ebenfalls erforderliche Secret-Quellen auf. Eine Charter, die auf einen nicht gesetzten env://-Wert verweist, wird nicht als startbereit dargestellt.

runeward doctor quickstart                     # Setup-Probleme sicher erklären
runeward --config-dir .runeward serve          # Dashboard + gesteuerte REST-API
runeward evidence export quickstart -o run.json
runeward evidence verify run.json              # unabhängige Richtlinien-/Audit-Verifizierung

Was Runeward hinzufügt

Jede gesteuerte Aktion folgt einem Pfad:

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

Benennung

Dokumentation und UI verwenden zuerst vertraute Begriffe. Bestehende API-Pfade und Dateifelder behalten die ursprünglichen thematischen Namen aus Kompatibilitätsgründen.

Siehe die vollständige Benennungs- und Schreibkonvention.

Installation

Wählen Sie das Paket, das zu Ihrer Nutzung von Runeward passt:

Für die normale lokale Nutzung installieren Sie die CLI mit Homebrew. Für eine Agenten-Integration installieren Sie zusätzlich das SDK für die jeweilige Sprache. Die pip- und npm-Pakete verbinden sich mit einer laufenden Runeward-API; sie ersetzen nicht die CLI/Laufzeit.

Homebrew — CLI

Lokale Sandboxes erfordern eine laufende Docker-, OrbStack- oder Podman-Engine.

brew install Runewardd/tap/runeward
runeward version
runeward quickstart

pip — Python SDK

Erfordert Python 3.9 oder neuer. Der Basis-Client hat keine Laufzeitabhängigkeiten von Drittanbietern.

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

npm — TypeScript SDK

Erfordert Node.js 18 oder neuer.

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

Siehe Adapter für Installationsoptionen zu LangChain, CrewAI, LlamaIndex, OpenAI Agents, Strands, Vercel AI SDK und LangChain.js.

Weitere CLI-Installationsoptionen

Der signierte macOS/Linux-Installer erfordert cosign, damit er fail-closed arbeiten kann, während er das Checksum-Manifest verifiziert. Windows-Binärdateien sind unter Releases verfügbar.

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

Um den aktuellen main-Branch zu bauen, verwenden Sie Go 1.26.6:

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

Verwendung mit einem Agenten

Stellen Sie gesteuerte Tools für eine MCP-fähige IDE oder einen Agenten bereit:

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

Oder platzieren Sie eine Agenten-CLI in einer Sandbox und führen Sie einen oder viele gesteuerte Worker aus:

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

Adapter sind für LangChain, CrewAI, LlamaIndex, OpenAI Agents, Strands, Vercel AI SDK und LangChain.js enthalten. Siehe Adapter und Agentengruppen.

Das Dashboard verfügt außerdem über ein schreibgeschütztes Live-Chat-TTY für jede Citadel. Agenten-Harnesses veröffentlichen user-, assistant-, tool- und system-Turns mit runeward_publish_conversation (oder den REST-, Python- und TypeScript-Äquivalenten), und autorisierte Teammitglieder können der redigierten Konversation folgen, ohne Terminal-Eingabezugriff zu haben. Runeward kann privaten UI-Chat-Text, den der Agenten-Client nicht veröffentlicht, nicht ableiten; verdrahten Sie den Publish-Aufruf in den Turn-Callback des Harness. Der Publisher muss sich mit derselben runeward serve-Control-Plane wie das Dashboard verbinden (über /mcp, REST oder ein SDK).

Agenten und Subagenten einbinden

Runeward ist die Durchsetzungsgrenze um einen Agenten, nicht die Komponente, die entscheidet, wie der Agent denkt. Leiten Sie die Tool-Aufrufe eines übergeordneten Agenten und jedes delegierten Subagenten durch Runeward, um ihnen explizite Richtlinien-, Genehmigungs-, Isolations-, Budget- und Nachweisgrenzen zu geben.

Bestehende Konzepte behalten ihre Bedeutung: Eine Cohort ist eine Gruppe gleichrangiger Worker, die ein Task-Board teilen; sie wird nicht in „Subagenten“ umbenannt. Der Orchestrator entscheidet weiterhin, wann delegiert wird, während Runeward die Parent/Run/Provider-Lineage aufzeichnet und verhindert, dass eine untergeordnete Citadel den Tenant oder die Charter ihres Parents erweitert. Jeder teilnehmende Agent kann seine eigene Citadel und Chronicle erhalten. Siehe Agent Harnessing.

Richtlinien-Workflow

Richtlinien unterstützen integrierte Glob-Regeln, CEL, OPA/Rego und signierte OCI-Bundles. Testen Sie sie in CI, starten Sie von einem geprüften Scaffold oder leiten Sie exakte Vorschläge aus verifizierten Produktionsnachweisen ab:

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 bearbeitet eine Richtlinie niemals automatisch. Es verifiziert zuerst die Nachweise, überspringt redigierte Aktionen, erzeugt exakte Übereinstimmungen und erfordert, dass ein Mensch sie prüft und erweitert.

Sicherheitslage

• Der Server bindet standardmäßig an Loopback und erfordert Authentifizierung vor einer Nicht-Loopback-Bindung.
• Nicht-Loopback-HTTP erfordert außerdem TLS, es sei denn, --allow-insecure-http bestätigt ausdrücklich, dass ein vertrauenswürdiger Reverse-Proxy TLS terminiert.
• Multi-Principal-RBAC beschränkt Sandboxes, Agentengruppen, Recovery-Snapshots und Dashboard-Ansichten auf ihren Tenant und ordnet jeden Vorgang seinem Actor zu. Statische Tokens und OIDC-JWTs verwenden dasselbe Autorisierungsmodell, und eingebettetes HTTP-MCP teilt die REST-Eigentumsprüfungen.
• Browser-Automatisierung ist experimentell und standardmäßig deaktiviert. Aktivieren Sie sie nur in einer vertrauenswürdigen Bereitstellung mit RUNEWARD_ENABLE_EXPERIMENTAL_BROWSER=1, nachdem Sie das Sicherheitsmodell geprüft haben. Browser-fähige Charters deklarieren capabilities = ["browser"]; das Dashboard stellt dann gesteuerte Aktionen für gerenderten Text und Screenshots sowie deren Richtlinien-/Egress-Ergebnisse bereit.
• Eine optionale Browser-IDE (code-server in-cell + ticketed Reverse-Proxy) ist ebenfalls experimentell: RUNEWARD_ENABLE_EXPERIMENTAL_IDE=1, Charter [ide], Dockerfile.ide-Targets ide / ide-agents, Beispiele ide-demo / / / . Einschränkungen: keine Richtlinie pro Tastendruck; keine Cursor/Claude Desktop/Codex-GUIs in-cell; kein erstklassiges GitHub Copilot auf code-server. Siehe und das .

Dokumentation

• Quickstart
• Richtlinien / Charters
• REST-API
• Browser-IDE (experimenteller code-server-Proxy)
• Sicherheitsmodell
• End-to-End-Testing
• Veröffentlichte Website: runewardd.github.io/runeward

Beiträge sind willkommen; siehe CONTRIBUTING.md. Lizenziert unter Apache 2.0.