runeward

El arnés de gobernanza de código abierto para agentes de IA.

Coloca políticas exigibles, aprobaciones humanas, ejecución aislada, presupuestos y evidencia firmada alrededor de cualquier agente de IA. Runeward funciona con un agente o framework multiagente existente en lugar de requerir un nuevo modelo o pila de orquestación.

Pruébalo con un solo comando

Requisitos previos: un motor Docker/Podman en ejecución y el binario runeward.

runeward quickstart

El comando crea .runeward/quickstart.toml, verifica la política, el runtime, la imagen y la ruta de estado, ejecuta un comando permitido, demuestra que un comando destructivo se deniega antes de su ejecución y verifica el registro de auditoría firmado. Nunca sobrescribe una política existente a menos que se pase --force.

doctor y la preparación del panel también resuelven las fuentes de secretos requeridas. Un Charter que hace referencia a un valor env:// no establecido no se presenta como listo para lanzar.

runeward doctor quickstart                     # explica los problemas de configuración de forma segura
runeward --config-dir .runeward serve          # panel + API REST gobernada
runeward evidence export quickstart -o run.json
runeward evidence verify run.json              # verificación independiente de política/auditoría

Qué añade Runeward

Cada acción gobernada sigue una única ruta:

solicitud del agente → política → aprobación humana cuando se requiere → límites → sandbox → evento de auditoría firmado

Nomenclatura

La documentación y la interfaz usan primero términos familiares. Las rutas de API y los campos de archivo existentes conservan los nombres temáticos originales por compatibilidad.

Consulta la convención completa de nomenclatura y redacción.

Instalación

Elige el paquete que se ajuste a cómo usas Runeward:

Para el uso local normal, instala la CLI con Homebrew. Para una integración de agentes, instala también el SDK de su lenguaje. Los paquetes de pip y npm se conectan a una API de Runeward en ejecución; no sustituyen a la CLI/runtime.

Homebrew — CLI

Los sandboxes locales requieren un motor Docker, OrbStack o Podman en ejecución.

brew install Runewardd/tap/runeward
runeward version
runeward quickstart

pip — SDK de Python

Requiere Python 3.9 o superior. El cliente base no tiene dependencias de runtime de terceros.

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

npm — SDK de TypeScript

Requiere Node.js 18 o superior.

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

Consulta Adapters para las opciones de instalación de LangChain, CrewAI, LlamaIndex, OpenAI Agents, Strands, Vercel AI SDK y LangChain.js.

Otras opciones de instalación de la CLI

El instalador firmado para macOS/Linux requiere cosign para poder fallar de forma segura mientras verifica el manifiesto de sumas de comprobación. Los binarios de Windows están disponibles en Releases.

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

Para compilar la rama main actual, usa Go 1.26.6:

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

Úsalo con un agente

Expón herramientas gobernadas a un IDE o agente compatible con MCP:

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

O coloca una CLI de agente dentro de un sandbox y ejecuta uno o varios workers gobernados:

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

Se incluyen adaptadores para LangChain, CrewAI, LlamaIndex, OpenAI Agents, Strands, Vercel AI SDK y LangChain.js. Consulta Adapters y grupos de agentes.

El panel también tiene un TTY de Live chat de solo lectura para cada Citadel. Los arneses de agentes publican turnos de user, assistant, tool y system con runeward_publish_conversation (o los equivalentes de REST, Python y TypeScript), y los compañeros de equipo autorizados pueden seguir la conversación redactada sin acceso de entrada al terminal. Runeward no puede inferir texto de chat privado de la interfaz que el cliente del agente no publique; conecta la llamada de publicación al callback de turno del arnés. El publicador debe conectarse al mismo plano de control de runeward serve que el panel (a través de /mcp, REST o un SDK).

Arneses de agentes y subagentes

Runeward es la frontera de aplicación alrededor de un agente, no el componente que decide cómo razona el agente. Enruta las llamadas a herramientas de un agente padre y de cada subagente delegado a través de Runeward para darles fronteras explícitas de política, aprobación, aislamiento, presupuesto y evidencia.

Los conceptos existentes conservan su significado: un Cohort es un grupo de workers pares que comparten un tablero de tareas; no se está renombrando a "subagentes". El orquestador sigue decidiendo cuándo delegar, mientras que Runeward registra el linaje de padre/ejecución/proveedor e impide que un Citadel hijo amplíe el inquilino o el Charter de su padre. Cada agente participante puede recibir su propio Citadel y Chronicle. Consulta Agent harnessing.

Flujo de trabajo de políticas

Las políticas admiten reglas glob integradas, CEL, OPA/Rego y paquetes OCI firmados. Pruébalas en CI, parte de un andamiaje revisado o deriva propuestas exactas a partir de evidencia de producción verificada:

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 nunca edita una política automáticamente. Primero verifica la evidencia, omite las acciones redactadas, produce coincidencias exactas y requiere que una persona las revise y amplíe.

Postura de seguridad

• El servidor se enlaza a loopback por defecto y requiere autenticación antes de un enlace que no sea loopback.
• El HTTP que no es loopback también requiere TLS a menos que --allow-insecure-http reconozca explícitamente que un proxy inverso de confianza termina TLS.
• El RBAC multi-principal limita los sandboxes, grupos de agentes, instantáneas de recuperación y vistas del panel a su inquilino, a la vez que atribuye cada operación a su actor. Los tokens estáticos y los JWT de OIDC usan el mismo modelo de autorización, y el MCP HTTP embebido comparte las comprobaciones de propiedad de REST.
• La automatización del navegador es experimental y está deshabilitada por defecto. Habilítala solo en un despliegue de confianza con RUNEWARD_ENABLE_EXPERIMENTAL_BROWSER=1 después de revisar el modelo de seguridad. Los Charters con capacidad de navegador declaran capabilities = ["browser"]; el panel entonces expone acciones gobernadas de texto renderizado y capturas de pantalla, y sus resultados de política/egreso.
• Un IDE de navegador opcional (code-server en celda + proxy inverso con tickets) es igualmente experimental: RUNEWARD_ENABLE_EXPERIMENTAL_IDE=1, Charter [ide], objetivos de Dockerfile.ide ide / ide-agents, ejemplos ide-demo / / / . Limitaciones: no hay política por pulsación de tecla; no hay GUIs de Cursor/Claude Desktop/Codex en celda; no hay GitHub Copilot de primera clase en code-server. Consulta y el .

Documentación

• Quickstart
• Policies / Charters
• REST API
• Browser IDE (proxy code-server experimental)
• Modelo de seguridad
• Pruebas de extremo a extremo
• Sitio publicado: runewardd.github.io/runeward

Las contribuciones son bienvenidas; consulta CONTRIBUTING.md. Con licencia Apache 2.0.