runeward

L'harness di governance open-source per agenti AI.

Applica policy vincolanti, approvazioni umane, esecuzione isolata, budget ed evidenze firmate attorno a qualsiasi agente AI. Runeward funziona con un agente o un framework multi-agente esistente, senza richiedere un nuovo modello o uno stack di orchestrazione.

Dimostralo con un solo comando

Prerequisiti: un engine Docker/Podman in esecuzione e il binario runeward.

runeward quickstart

Il comando crea .runeward/quickstart.toml, verifica la policy, il runtime, l'immagine e il percorso di stato, esegue un comando consentito, dimostra che un comando distruttivo viene negato prima dell'esecuzione e verifica l'audit trail firmato. Non sovrascrive mai una policy esistente a meno che non venga passato --force.

Anche doctor e la readiness della dashboard risolvono le fonti dei secret richieste. Una Charter che fa riferimento a un valore env:// non impostato non viene presentata come pronta al lancio.

runeward doctor quickstart                     # spiega i problemi di configurazione in modo sicuro
runeward --config-dir .runeward serve          # dashboard + API REST governata
runeward evidence export quickstart -o run.json
runeward evidence verify run.json              # verifica indipendente di policy/audit

Cosa aggiunge Runeward

Ogni azione governata segue un unico percorso:

richiesta dell'agente → policy → approvazione umana quando richiesta → limiti → sandbox → evento di audit firmato

Denominazione

La documentazione e l'interfaccia utente usano prima i termini familiari. I percorsi API e i campi dei file esistenti mantengono i nomi tematici originali per compatibilità.

Vedi la convenzione completa di denominazione e scrittura.

Installazione

Scegli il pacchetto che corrisponde a come usi Runeward:

Per il normale uso locale, installa la CLI con Homebrew. Per un'integrazione con un agente, installa anche l'SDK per il suo linguaggio. I pacchetti pip e npm si connettono a un'API Runeward in esecuzione; non sostituiscono la CLI/runtime.

Homebrew — CLI

Le sandbox locali richiedono un engine Docker, OrbStack o Podman in esecuzione.

brew install Runewardd/tap/runeward
runeward version
runeward quickstart

pip — SDK Python

Richiede Python 3.9 o superiore. Il client di base non ha dipendenze runtime di terze parti.

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

npm — SDK TypeScript

Richiede Node.js 18 o superiore.

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

Vedi Adapters per le opzioni di installazione di LangChain, CrewAI, LlamaIndex, OpenAI Agents, Strands, Vercel AI SDK e LangChain.js.

Altre opzioni di installazione della CLI

L'installer firmato per macOS/Linux richiede cosign così da poter fallire in modo sicuro durante la verifica del manifest dei checksum. I binari Windows sono disponibili in Releases.

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

Per compilare il branch main corrente, usa Go 1.26.6:

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

Usalo con un agente

Esponi strumenti governati a un IDE o agente compatibile con MCP:

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

Oppure colloca una CLI di un agente dentro una sandbox ed esegui uno o più worker governati:

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

Sono inclusi adapter per LangChain, CrewAI, LlamaIndex, OpenAI Agents, Strands, Vercel AI SDK e LangChain.js. Vedi Adapters e gruppi di agenti.

La dashboard dispone anche di un TTY Live chat in sola lettura per ogni Citadel. Gli harness degli agenti pubblicano i turni user, assistant, tool e system con runeward_publish_conversation (o gli equivalenti REST, Python e TypeScript), e i colleghi autorizzati possono seguire la conversazione redatta senza accesso in input al terminale. Runeward non può inferire il testo privato della chat dell'interfaccia che il client dell'agente non pubblica; collega la chiamata di pubblicazione al callback del turno dell'harness. Il publisher deve connettersi allo stesso control plane runeward serve della dashboard (tramite /mcp, REST o un SDK).

Harness di agenti e subagenti

Runeward è il confine di enforcement attorno a un agente, non il componente che decide come ragiona l'agente. Instrada le chiamate agli strumenti di un agente padre e di ogni subagente delegato attraverso Runeward per dare loro confini espliciti di policy, approvazione, isolamento, budget ed evidenze.

I concetti esistenti mantengono il loro significato: un Cohort è un gruppo di worker peer che condividono una task board; non viene rinominato in "subagents". L'orchestratore decide comunque quando delegare, mentre Runeward registra il lineage parent/run/provider e impedisce a un Citadel figlio di ampliare il tenant o la Charter del suo genitore. Ogni agente partecipante può ricevere il proprio Citadel e la propria Chronicle. Vedi Agent harnessing.

Flusso di lavoro delle policy

Le policy supportano regole glob integrate, CEL, OPA/Rego e bundle OCI firmati. Testale in CI, parti da uno scaffold revisionato o deriva proposte esatte da evidenze di produzione verificate:

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 non modifica mai automaticamente una policy. Verifica prima le evidenze, salta le azioni redatte, produce corrispondenze esatte e richiede che una persona le revisioni e le ampli.

Postura di sicurezza

• Il server si associa al loopback per impostazione predefinita e richiede l'autenticazione prima di un bind non-loopback.
• Anche l'HTTP non-loopback richiede TLS, a meno che --allow-insecure-http riconosca esplicitamente che un reverse proxy fidato termina il TLS.
• L'RBAC multi-principal limita sandbox, gruppi di agenti, snapshot di recovery e viste della dashboard al loro tenant, attribuendo ogni operazione al suo attore. I token statici e i JWT OIDC usano lo stesso modello di autorizzazione, e l'HTTP MCP incorporato condivide i controlli di proprietà REST.
• L'automazione del browser è sperimentale e disabilitata per impostazione predefinita. Abilitala solo in un deployment fidato con RUNEWARD_ENABLE_EXPERIMENTAL_BROWSER=1 dopo aver esaminato il modello di sicurezza. Le Charter abilitate al browser dichiarano capabilities = ["browser"]; la dashboard espone quindi azioni governate di testo renderizzato e screenshot e i relativi risultati di policy/egress.
• Un IDE browser opzionale (code-server in-cell + reverse proxy con ticket) è analogamente sperimentale: RUNEWARD_ENABLE_EXPERIMENTAL_IDE=1, Charter [ide], target Dockerfile.ide ide / ide-agents, esempi ide-demo / / / . Limiti: nessuna policy per singolo tasto; nessuna GUI di Cursor/Claude Desktop/Codex in-cell; nessun GitHub Copilot di prima classe su code-server. Vedi e il .

Documentazione

• Quickstart
• Policies / Charters
• REST API
• Browser IDE (proxy code-server sperimentale)
• Modello di sicurezza
• Test end-to-end
• Sito pubblicato: runewardd.github.io/runeward

I contributi sono benvenuti; vedi CONTRIBUTING.md. Con licenza Apache 2.0.