NOMOS Browser

El navegador de tu agente, contigo en la sala.

Infraestructura de navegación gobernada para agentes de IA. El navegador se convierte en un recurso de la plataforma, no un juguete acoplado a un modelo — y el dueño ve, autoriza e interrumpe lo que el agente hace.

0.3.0-rc.2 · MIT · Node ≥ 22.6 · Chromium via Playwright · sin paso de build

El problema

Dar a un agente el poder de usar un navegador es darle el poder de comprar, enviar, borrar y filtrar en nombre de alguien. Esto suele resolverse de dos maneras malas:

• confianza ciega — el agente actúa y el dueño se entera después;

• parálisis — el agente pregunta todo, y el dueño hace clic en "sí" automáticamente hasta que la aprobación se convierte en reflejo.

El NOMOS Browser separa lo que el dueño ya autorizó de lo que necesita consentimiento ahora, y hace la diferencia visible, auditable y reversible.

Related MCP server: Cloudflare Playwright MCP

Cómo queda

NOMOS · Claude · Gemini · Qwen · Ollama · agente próprio
                        │
      MCP  ·  REST v1  ·  WebSocket  ·  SDK  ·  CLI  ·  Live Agent Console
                        │
              NOMOS BROWSER RUNTIME
        política → autonomia → aprovação → auditoria
                        │
                 Playwright · CDP
                        │
                     Chromium

El estado de la navegación pertenece al Runtime, no al modelo. El agente se desconecta, muere o es reemplazado por otro de otro proveedor: la sesión sigue viva, con las mismas pestañas, cookies y tarea.

Recursos

Demostración

El Live Agent Console es servido por el propio runtime, en el mismo origen, con CSP connect-src 'self' — no hay CORS permisivo que explotar.

node packages/api/src/daemon.ts
# abra a URL com o token que o daemon imprime

Guiones reproducibles con resultado esperado están en docs/demos.md.

Instalación

npm ci --include=dev
npx playwright install chromium

--include=dev no es decoración: con NODE_ENV=production o npm config omit=dev, el npm ci omite las devDependencies y el typecheck falla después con "This is not the tsc command you are looking for". Detalles en docs/INSTALLATION.md.

No hay paso de build para el runtime: Node ejecuta TypeScript nativamente. La interfaz tiene un paso propio (node packages/ui/build.ts) porque lee los tokens de marca de la bóveda en cada generación.

Quick start

# 1. subir o runtime
node packages/api/src/daemon.ts &

# 2. estado
node packages/cli/src/main.ts health

# 3. abrir uma página (a sessão nasce com a política padrão)
node packages/cli/src/main.ts open https://example.com

# 4. ver o que ficou gravado
node packages/cli/src/main.ts sessions
node packages/cli/src/main.ts replay <SESSION_ID>

La CLI nunca concede capability sensible: la sesión creada por ella nace con download, upload, send, purchase, payment y delete denegados.

Ejemplos

# capturar a tela de uma sessão
node packages/cli/src/main.ts screenshot <SESSION_ID> --out /tmp/tela.png

# entregar um objetivo ao agente
node packages/cli/src/main.ts task --session <SESSION_ID> "encontre o preço do plano anual"

# acompanhar os eventos ao vivo
node packages/cli/src/main.ts events --session <SESSION_ID>

# verificar a integridade do replay gravado
node packages/cli/src/main.ts replay verify <SESSION_ID>

ASK y AUTO

La jerarquía, y el orden es la garantía:

POLÍTICA DO DONO → MODO DE AUTONOMIA → CAPABILITY DO NOMOS → GATES DE APROVAÇÃO → AÇÃO

ASK — preguntar

Las lecturas pasan directo. Toda acción que cambia la página se detiene y pregunta, con consecuencia y recurso escritos en portugués, para que la decisión sea consciente y no un clic reflejo.

Aprobar una browser.task no es un cheque en blanco: cada paso que el plan decida ejecutar vuelve a entrar en el portón.

AUTO — actuar sin preguntar

El agente ejecuta solo todo lo que ya autorizaste mediante tu política. Lo que no cambia:

• acciones con efecto financiero, envío externo o alta irreversibilidad siguen pidiendo aprobación — browser.upload pregunta en AUTO porque envía dato tuyo hacia afuera, y eso no se retira;

• ruta sin perfil de riesgo declarado cae en "siempre aprobar" (fail-closed);

• si el estado de autonomía no puede ser comprobado (runtime caído, reconexión), la interfaz nunca muestra AUTO: cae a desconocido y lo trata como ASK.

AUTO != BYPASS no es una promesa de documentación. El portón de autonomía corre después de capability y de control humano: cuando ejecuta, todo lo que la política niega ya devolvió 403. No existe rama en el código que transforme un deny en allow.

Más en docs/ask-mode.md y docs/auto-mode.md.

Seguridad

• Autenticación por token con alcances (OBSERVE, NAVIGATE, INPUT, DOWNLOAD, UPLOAD, SECRET, CONTROL, ADMIN). Toda ruta tiene alcance declarado; ninguna vive del default.

• Quien actúa no autoriza. El perfil de agente no alcanza a aprobar, delegar modo ni reanudar. Parar, sí: pause y emergency-stop nunca pueden ser más difíciles que actuar.

• Política fail-closed por capability, con A6_DESTRUCTIVE denegado.

• Anti-SSRF: navegar a host interno es acto explícito, nunca inferido.

• Procedencia anti-inyección en el camino de ejecución: observe y extract devuelven provenance.

• Lease de control obligatorio (allow_unleased: false).

• Secretos no aparecen en la interfaz, en la auditoría ni en el replay.

El modelo de amenaza T1–T10, con residuos declarados, está en docs/SECURITY.md.

Nada aquí afirma "100% seguro". Ninguna medida lo sustenta, y ninguna jamás lo sustentará.

Auditoría y replay

Rastro de 19 campos por acción, encadenado por hash, con redacción de secreto en el origen. Al cerrar, la sesión es sellada.

El replay es de solo lectura en tres capas independientes: no existe verbo de escritura en la ruta (405 + Allow: GET); leer el historial no resucita la sesión; y el modo es declarado por el runtime, no deducido por la pantalla.

También es honesto sobre su propia lectura: reporta líneas corruptas y fuentes ausentes en lugar de devolver una línea de tiempo más corta que se presenta como completa. Sesión que nunca existió es 404, no un replay vacío de 200.

Ver docs/audit-and-replay.md.

MCP

16 herramientas, sin acoplamiento a modelo:

browser_navigate · browser_observe · browser_find · browser_extract · browser_screenshot · browser_click · browser_type · browser_press · browser_scroll · browser_tabs · browser_tab_open · browser_tab_switch · browser_tab_close · browser_download · browser_upload · browser_task

En el ecosistema NOMOS, el navegador es una capability gobernada por la política del dueño, con catálogo firmado y confianza por huella del manifiesto normalizado. Ver docs/mcp.md y docs/NOMOS-INTEGRATION.md.

Configuración

51 claves, consultables por el propio runtime:

curl -s localhost:7777/api/v1/config/schema   # a FORMA (pública)
curl -s localhost:7777/api/v1/config          # os VALORES efetivos (ADMIN)

La separación es deliberada: "¿qué existe?" puede ser respondida a cualquier portador; "¿qué está vigente aquí?" no. Ver docs/CONFIGURATION.md.

Troubleshooting

Síntoma → causa → verificación → corrección en docs/TROUBLESHOOTING.md.

Desarrollo

npx tsc --noEmit                    # tipos
bash scripts/run-suite.sh           # suíte inteira, um arquivo por vez
bash scripts/run-suite.sh --fast    # pula browser/bench
bash scripts/regressao-completa.sh  # 15 etapas, um veredito
bash scripts/limpar-orfaos.sh       # higiene por prova de posse

Usa el ejecutor, no node --test tests/ directo. El runner de Node paraleliza por CPU; bajo presión de memoria el proceso muere en el medio y deja salida truncada sin línea de resumen, que parece éxito. El run-suite.sh corre un archivo a la vez, y un archivo muerto aparece como MORTO.

Pruebas

Medido en HEAD 6964cf0:

suíte TypeScript     789 passes · 0 falhas · 37/37 arquivos
E2E do Live Agent    106 casos  · 9 baterias
sala limpa           14/14 passos, a partir de clone do HEAD
regressão completa   15 etapas · 0 falha · 0 não-executada

El proyecto se niega a llamar PASS a lo que no fue observado. Dos ejemplos:

El control del navegador es real. Un clic sintetizado por JavaScript llega a la página con isTrusted=false; uno despachado por CDP llega con true. El spike prueba ambos — el segundo prueba el control, el primero prueba que el test no es vacío.

El contador de aprobaciones no es ciego. Bajo mutación del producto, UNEXPECTED_APPROVAL_PROMPTS pasa de 0 a 3 y a 5 según el defecto inyectado. Un contador que se quedara en cero bajo mutación no estaría midiendo nada.

Limitaciones conocidas

• p99 no es reportado en ningún camino de latencia: 30 muestras exigen 100 para sostener un p99. Ningún máximo observado es llamado p99.

• No hay ruta HTTP para emitir token con alcance — existe en la API interna.

• La rama pr.page.isClosed() es inalcanzable en operación normal; es defensa de carrera, no cobertura.

• La franja de estado de la interfaz actualiza por polling de 700 ms. Los eventos llegan en ~1 ms; la franja, no.

• Validado en macOS/Apple Silicon. Otras plataformas no fueron medidas.

La lista completa, con números, está en docs/LIMITATIONS.md, y lo que es PROVEN contra lo que es MEASURED o NOT PROVEN está en PRODUCT_TRUTH_MATRIX.md.

Roadmap

En ROADMAP.md. Lo que está ahí son deudas legítimas, no promesas de fecha.

Documentación

Empieza por aquí

Referencia

Marca

La marca NOMOS está congelada en la v1.0 y el resolvedor oficial responde rc=0. Los tokens se leen de la caja fuerte en cada build y no están versionados en este repositorio — copiar token de marca a archivo intermedio está prohibido por el contrato de gobernanza. Ver docs/BRAND.md.

Licencia

MIT. Ver LICENSE. Titular: Voltolini-SPACE.

La licencia cubre el código. No concede derecho sobre las marcas "NOMOS" y "NOMOS Browser" ni sobre los tokens de identidad visual, que se gobiernan por separado y no están versionados aquí. Detalles en NOTICE.md.

Hasta 2026-08-25 este repositorio declaraba "todos los derechos reservados" con un titular placeholder. Las dos cosas eran decisión del dueño, y fueron decididas.

Parte del ecosistema NOMOS · voltolini.space