El repositorio no es confiable: controles para agentes en la frontera workspace–runtime

Un agente de código recibe dos cosas al abrir un proyecto: material para comprender y material que puede intentar influenciar su comportamiento. Archivos, instrucciones locales, configuraciones, dependencias, enlaces y resultados de herramientas pertenecen al mismo workspace, pero no tienen la misma autoridad.

Este Evidence Brief parte de un lote de nueve advisories publicado por el proyecto CodeWhale el 16 de julio de 2026 e incorporado al GitHub Advisory Database el 4 de septiembre. El objetivo no es enseñar a explotar las fallas ni evaluar el producto por un único lote. Es derivar un contrato técnico para la frontera entre contenido no confiable, política del operador y efectos producidos por el runtime.

Estado: Evidence Brief aprobado para publicación el 07/09/2026 a las 09h BRT. Este texto no afirma que los controles propuestos estén implementados u operando en Trustyu Forge.

Alcance fáctico del caso

A página de advisories de CodeWhale contiene nueve registros publicados por el mantenedor el 16/07/2026 que tratan, entre otras fronteras, de configuración de proyecto, aprobación de ejecución, argumentos de herramientas, enlaces simbólicos, entorno del proceso y acceso de red. Los registros correspondientes aparecieron en GitHub Advisory Database en 04/09/2026.

El denominador correcto son nueve advisories en ese lote. No son nueve incidentes, nueve explotaciones activas o nueve organizaciones afectadas. La página del proyecto también lista cuatro registros anteriores, de mayo; el lote no representa todo el historial.

Las severidades divergen entre las superficies. En la base de datos global de GitHub, un registro está clasificado como crítico y ocho como altos. En el repositorio, el lote aparece como uno crítico, siete altos y uno moderado. La diferencia debe atribuirse a cada ficha; no altera el patrón arquitectónico compartido.

Para los paquetes actuales codewhale-tui y codewhale, las fichas globales registran como afectadas las versiones a partir de 0.8.41 y anteriores a 0.8.64, indicando 0.8.64 como primera versión corregida. Algunos advisories también registran el paquete anterior deepseek-tui, con rangos propios y corrección en 0.8.41. La acción operativa depende del paquete y de la versión efectivamente instalados.

No se ha localizado, hasta el corte, evidencia pública de explotación activa, cantidad de instalaciones afectadas, incidente confirmado o impacto financiero. El propio proyecto publicó los advisories y referencias de corrección. GitHub, NVD y la página del mantenedor reflejan el mismo conjunto de disclosures y no deben ser contados como corroboraciones independientes.

Modelo de confianza

El diseño mínimo separa cuatro dominios:

política do operador ───────────────┐
                                    ↓
repositório não confiável → mediador de capacidade → sandbox/runtime → efeitos
           │                        │                      │              │
           └──── evidência ─────────┴──── receipts ────────┴── auditoria ─┘

1. Política del operador: identidad, capacidades, egress, datos permitidos y acciones que requieren aprobación. Es autoridad superior al workspace.
2. Repositorio no confiable: El código, la configuración, la documentación, las instrucciones y las dependencias son entradas. Pueden solicitar menos autoridad; no pueden conceder más.
3. Mediador de capacidad: valida intención y consecuencia en el punto de acción, resuelve el objetivo real y aplica política de forma central.
4. Sandbox/runtime: contiene proceso, filesystem, red, recursos y tiempo. Fallo cerrado y produce evidencia independiente del texto del modelo.

El error de composición aparece cuando una capa trata entrada como autoridad. Un archivo del proyecto puede informar que pruebas usan determinado comando. No debería habilitar shell. Una ruta puede parecer interna al workspace. No debería decidir por sí mismo el destino real de lectura o escritura.

Invariante 1 — la configuración es monótona

Configuración monótona significa que una capa de menor confianza solo puede mantener o reducir la autoridad recibida.

capabilities_effective = intersect(
  organization_policy,
  user_policy,
  session_policy,
  repository_restrictions
)

repository_restrictions participa como restricción, nunca como concesión. Un proyecto puede declarar “sin red” o “solo lectura”. No puede cambiar shell=false por shell=true, sustituir una lista de instrucciones controlada por el usuario o añadir destinos de egress.

O commit asociado al lote aplica este principio a una frontera del CodeWhale: los overlays del proyecto pueden restringir el acceso a shell, pero no habilitarlo ni reemplazar las listas de instrucciones del usuario. El commit es evidencia de la corrección descrita; no prueba auditoría completa del runtime.

Pruebas negativas

• un proyecto solicita capacidad ausente y el resultado efectivo sigue denegado;
• una configuración cambia lista controlada por lista local y la carga falla cerrado;
• la misma política es probada por CLI, interfaz y automatización sin ruta alternativa;
• el receipt registra la política solicitada, la política efectiva y el motivo de la diferencia.

Invariante 2 — la aprobación acompaña a la consecuencia

Una acción no debe ser aprobada solo por el nombre de la herramienta o por su primera llamada. Si una sesión existente puede recibir nueva entrada, si un proceso puede ejecutar código o si una herramienta equivalente produce el mismo efecto, todas estas rutas deben pasar por el mismo mediador.

El lote incluye registros sobre interacción con shell y evaluación de código sin la confirmación esperada: GHSA-g29h-pfmp-qp9r y GHSA-wrj3-vj8c-784f.

El contrato de aprobación debería vincular:

• identidad del solicitante y del aprobador;
• clase de efecto, no solo nombre de la herramienta;
• destino resuelto y alcance;
• argumentos normalizados;
• ventana de validez;
• digest de la política y de la solicitud;
• resultado ejecutado o bloqueado.

Una aprobación no debe ser válida para “cualquier comando futuro” en una sesión. La reutilización solo es segura cuando la política describe explícitamente la clase de efecto y el límite que permanece válido.

Invariante 3 — el confinamiento usa el objetivo real

El lote incluye advisories sobre argumentos de herramientas Git y resolución de links en el workspace: GHSA-c6mw-8xh8-gpq6, GHSA-7j5w-7r7x-9v27 y GHSA-w7wx-5q49-r59w.

Validar la cadena antes de ejecutar no es suficiente. El mediador debe trabajar con argumentos tipados, resolver el destino real bajo una raíz permitida y rechazar cambios entre la validación y el uso.

Un contrato defensivo incluye:

1. API tipada por operación, sin concatenar texto en comando genérico;
2. allowlist de flags y parámetros por herramienta;
3. descriptor de archivo o mecanismo equivalente ligado al objetivo ya resuelto;
4. rechazo de enlaces o montajes que escapen de la raíz autorizada;
5. distinción explícita entre lectura, escritura, creación, sustitución y ejecución;
6. registro del objetivo lógico y del objetivo efectivo, sin registrar contenido sensible.

Pruebas negativas

• los argumentos desconocidos o ambiguos son rechazados;
• un enlace que resuelve fuera de la raíz no puede ser leído ni enviado al modelo;
• el objetivo no puede ser cambiado entre la verificación y la operación;
• las operaciones solo lectura no poseen ruta de escritura colateral;
• los archivos fuera del alcance permanecen inaccesibles incluso cuando el proceso tiene acceso en el host.

Invariante 4 — el entorno comienza vacío

GHSA-h539-c7r8-3xq4 registra la exposición del entorno padre al contexto del modelo en una ruta de ejecución. La defensa más robusta es construir el entorno del proceso hijo a partir de una allowlist mínima.

child_env = {
  runtime_path,
  locale,
  task_scoped_token,
  explicit_non_secret_parameters
}

El token, cuando es indispensable, debe ser efímero, limitado por audiencia, operación, tenant y tiempo. Un secreto no se vuelve seguro porque fue eliminado del prompt; si el proceso o una herramienta puede imprimirlo, aún puede alcanzar el contexto.

Pruebas negativas

• variables no allowlisted no aparecen en el proceso hijo ni en los resultados de herramienta;
• los logs y receipts registran nombres de capacidades, no valores secretos;
• un token de tarea no autoriza recurso, tenant o operación fuera del scope;
• la ausencia de credencial produce un fallo explícito, sin fallback a la identidad del operador.

Invariante 5 — egress se aplica en la conexión

GHSA-6v2g-fpxh-pmmh describe una condición temporal relacionada con la validación DNS en protección contra SSRF. El estándar general es no depender únicamente de una verificación previa de la URL.

Una capa de egress debe:

• resolver nombres en componente controlado;
• bloquear destinos locales, privados, metadata y rangos no permitidos;
• revalidar redireccionamientos y el destino efectivo;
• limitar protocolos, puertos, volumen, tiempo y cantidad de respuestas;
• preferir la allowlist de servicios o un proxy dedicado en tareas de mayor riesgo;
• registrar decisión de política y destino sanitizado.

El objetivo no es enseñar una secuencia ofensiva. Es garantizar que la política sobreviva a las diferencias entre nombre solicitado, resolución y conexión realizada.

Invariante 6 — la instrucción no se convierte en autoridad

GHSA-62f5-cp2p-vq95 y GHSA-gx45-xrj5-g6c4 tratan con la configuración del proyecto influyendo instrucciones o acceso a shell. El harness necesita preservar provenance y precedencia:

runtime debe marcar el origen de cada instrucción y rechazar colisiones que intenten promover contenido de menor confianza. El harness duradero mantiene historial, política de orquestación e aislamiento de ejecución como fronteras explícitas, sin transformar modelo o canal en frontera de seguridad. [HARNESS31-C2]

Evidence Packet mínimo por acción

{
  "task_id": "opaque-id",
  "policy_digest": "sha256:...",
  "repository_digest": "sha256:...",
  "requested_capability": "typed-capability",
  "effective_scope": "bounded-scope",
  "approval_ref": null,
  "runtime_identity": "ephemeral-principal",
  "result": "allowed|blocked|failed|inconclusive",
  "artifact_refs": ["immutable-receipt"]
}

El receipt no debe contener secretos, datos personales innecesarios o contenido integral del repositorio. Debe permitir que otra persona reconstruya qué política se aplicó a qué versión y qué efecto fue autorizado.

Gate antes de liberar un agente de código

1. ¿Se clasifica el origen del repositorio?
2. ¿La política efectiva es monótona y demostrable?
3. ¿Utilizan shell, filesystem, red e integraciones con una identidad efímera y mínima?
4. ¿Pasa toda acción con consecuencia equivalente por el mismo mediador?
5. ¿Los caminos y argumentos se resuelven y tipan antes del efecto?
6. ¿El entorno del proceso nace de allowlist?
7. ¿Se aplica el egress en el destino efectivo y en cada redireccionamiento?
8. ¿Las pruebas negativas ejercitan bypasses de configuración, aprobación, camino, entorno y red?
9. ¿Son fallos, bloqueos, inconclusiones y éxitos estados distintos?
10. ¿Un Evidence Packet enlaza política, entrada, acción, resultado y autoridad?

Pasar por esta gate demuestra solo el recorte probado. No prueba seguridad total, prontitud de producción o operación continua.

Limitaciones y riesgo de interpretación

• El conjunto describe un producto y versiones específicas; la arquitectura propuesta es una generalización profesional, no conclusión de los advisories.
• Las fuentes derivadas repiten el mismo disclosure y no miden prevalencia o explotación.
• Las severidades divergen entre superficies y pueden cambiar después de una nueva revisión.
• Actualizar a la versión corregida es una acción específica; adoptar todos los controles anteriores exige threat model y prueba en el entorno de la organización.
• Este brief evita pruebas de concepto, comandos, objetivos sensibles y rutas ofensivas.
• Ningún control aquí es declarado como ya implantado, ensaiado o operando en la Trustyu Forge.

Fuentes directas

1. CodeWhale — advisories del proyecto.
2. GHSA-6v2g-fpxh-pmmh / CVE-2026-75856.
3. GHSA-g29h-pfmp-qp9r / CVE-2026-75857.
4. GHSA-wrj3-vj8c-784f / CVE-2026-75858.
5. GHSA-62f5-cp2p-vq95 / CVE-2026-75859.
6. GHSA-gx45-xrj5-g6c4 / CVE-2026-75911.
7. GHSA-c6mw-8xh8-gpq6 / CVE-2026-75912.
8. GHSA-7j5w-7r7x-9v27 / CVE-2026-75913.
9. GHSA-w7wx-5q49-r59w / CVE-2026-75914.
10. GHSA-h539-c7r8-3xq4 / CVE-2026-75915.
11. Commit 4356335 — proyecto restringe overlays locales.
12. NVD — CVE-2026-75859. Registro derivado del disclosure, no confirmación independiente de explotación.

Nota editorial y de responsabilidad

Este texto combina hechos atribuidos a advisories públicos con análisis y propuesta técnica del autor. Los puntos de vista personales y profesionales no son hechos comprobados; los datos, denominadores, límites y conflictos se indican cuando están disponibles. No constituye una acusación de negligencia ni afirma que ha habido incidente, explotación o daño. El contenido es informativo y no sustituye la evaluación técnica, legal o de seguridad. Tech Human e Trustyu operan comercialmente en temas relacionados. La investigación, estructura y redacción contaron con asistencia de IA; la revisión fáctica, aprobación autoral y aprobación de publicación fueron confirmadas por Fernando Parreiras el 06/09/2026, sin revisión humana independiente adicional.

Corte de la investigación: 06/09/2026. Estado editorial: publicación especial autorizada para 07/09/2026 a las 09h BRT.