El harness del agente es tu frontera real de privilegios — y la mayoría de los equipos la dibuja en el lugar equivocado

¿De qué se trata?

El 26 de mayo de 2026, Dor Sarig, de Pillar Security, publicó Your Agent Harness Has More Privilege Than Your Agent. El argumento es breve y estructural: en un agente de codificación moderno — Claude Code, Cursor, Codex, Aider, Cline — el modelo es el motor, pero el harness es el coche. Es el harness el que sostiene las claves de API, media las llamadas a herramientas, controla los permisos de sistema de ficheros, escribe el log de sesión y decide incluso qué ve el modelo en cada turno. Si tu modelo de seguridad trata al agente (el LLM en el bucle) como la unidad de riesgo, has dibujado la frontera en el lugar equivocado.

Dos señales recientes e independientes hacen el caso concreto. La divulgación de Pillar del 14 de enero de 2026 sobre Cursor (CVE-2026-22708) mostró cómo los built-ins del shell, fuera de la allowlist del harness, permitían a un atacante envenenar variables de entorno y convertir un git branch aparentemente inocuo en ejecución de código arbitrario. Y el post-mortem del 23 de abril de Anthropic sobre los reportes de calidad de Claude Code atribuye dos meses de degradación percibida a tres cambios en el harness — no en el modelo —, incluido un bug de caché que descartaba silenciosamente el historial de razonamiento a mitad de sesión. El harness es donde reside el apalancamiento. También es donde residen los bugs.

Cómo funciona

Un harness es la estructura fija que convierte un LLM de un solo turno en algo capaz de actuar. Posee varios recursos que el agente — el modelo en el bucle — nunca manipula directamente:

Componente                       ¿Reside en el harness?  ¿Reside en el modelo?
-------------------------------  ----------------------  ----------------------
Claves de API / secretos         Sí                      No
Implementación de herramientas   Sí                      No (sólo descripciones)
Clasificador de permisos         Sí                      No
Acceso al sistema de ficheros    Sí                      Enrutado por herramientas
Log de eventos de sesión         Sí                      No
Compactación de contexto         Sí                      No
Ensamblaje del system prompt     Sí                      No
Hooks (pre / post tool)          Sí                      No
Spawn y policy de subagentes     Sí                      No

Sarig detalla las superficies de ataque que esto crea, apoyándose en las investigaciones de Pillar sobre Cursor y en patrones ya visibles en los principales harnesses de codificación.

Las descripciones de herramientas son superficie de inyección de prompts. El modelo se orienta por descripciones que el harness carga en cada turno. Una descripción envenenada — vía compromiso de cadena de suministro, un servidor MCP malicioso o una actualización del registro — redirige silenciosamente la elección de herramienta. Normalmente no hay ninguna entrada de log que diga “la descripción cambió el martes pasado”.

El ensamblaje del system prompt recorre el árbol de archivos. Los harnesses modernos escanean los directorios padre buscando archivos como CLAUDE.md, AGENTS.md, .cursor/rules e inyectan lo que encuentran. Un archivo malicioso colocado en cualquier punto del árbol acaba en el system prompt. Es por diseño — y es una ruta de ataque real en cuanto el agente opera contra un repositorio no confiable.

Los hooks son el punto de extensión más poderoso — y el más peligroso. Los hooks pre-tool pueden permitir, denegar o reescribir una llamada a herramienta. Un hook comprometido es un man-in-the-middle silencioso para cada llamada. Los hooks post-tool ven cada resultado. La adopción empresarial pasa cada vez más por los hooks, lo que significa que el compromiso empresarial puede pasar por ellos también.

La compactación de contexto es pérdida selectiva de memoria. Cuando la ventana de contexto se llena, el harness resume o descarta el contenido más antiguo. Lo que se descarta — incluida una instrucción maliciosa vista en el turno 12 — puede seguir influyendo al agente en el turno 47 sin estar disponible para que un auditor lo inspeccione. Las estrategias de compactación suelen ser heurísticas y rara vez se prueban contra entradas adversarias.

Los clasificadores de permisos parsean cadenas. Las allowlists de estilo bash se deciden típicamente parseando el comando en tiempo de despacho. rm salta a aprobación completa. ls se queda en sólo lectura. ¿Pero find . -delete? ¿Un alias? ¿export PAGER="open -a Calculator" seguido de un git branch allowlistado? Esa última secuencia es el corazón de la CVE-2026-22708: los built-ins del shell saltaban por completo la allowlist de Cursor, dejando que la inyección de prompt envenenara el entorno hasta que un comando aprobado se convertía en un exploit.

Los subagentes pueden escapar a la policy del padre. Los subagentes tienen sus propias listas de herramientas y sus propios permisos. Si el harness padre no aplica la policy de manera coherente al cruzar la frontera del spawn, un atacante que pueda influir en la creación de subagentes puede usar al hijo para hacer lo que el agente padre no tiene permiso de hacer.

El log de sesión es un almacén local de secretos. Los logs de eventos append-only son la historia de durabilidad de todos los harnesses modernos. Son también una transcripción completa de cada secreto que ha pasado por el contexto, depositada en el disco del desarrollador, generalmente sin cifrar.

Por qué importa

Conviene seguir dos desplazamientos.

El primero, dónde aterrizan los bugs. El post-mortem de Anthropic es inusualmente transparente al respecto: los reportes de usuario “Claude empeoró” no fueron regresiones del modelo; fueron un cambio de nivel de esfuerzo por defecto, un bug de desalojo de caché que se acumulaba a lo largo de los turnos y una instrucción de verbosidad en el system prompt. Ninguna de las tres cosas tocó la API ni la capa de inferencia. Las tres vivían en el harness. La reacción de Simon Willison merece citarse: “el tipo de bugs que afectan a los harnesses es profundamente complejo, incluso dejando a un lado la naturaleza no determinista de los modelos en sí”. Para los builders, ahí está la lección. La clase de bugs contra la que hay que defenderse ahora incluye el estado del harness.

El segundo, dónde aterrizan los ataques. La CVE-2026-22708 es el caso de manual. El modelo no hizo nada novedoso; era la allowlist del harness la que servía de ancla de confianza, y era sorteable mediante built-ins del shell que el parser no clasificaba. El fix en Cursor 2.3 cerró ese bypass concreto, pero el análisis de Pillar es explícito: es un problema de clase. Un harness que se protege con allowlists en lugar de aislamiento de ejecución seguirá perdiendo frente a entradas creativas mientras se pueda convencer al agente de teclearlas. Las divulgaciones adyacentes — envenenamiento de contexto agente-a-agente, archivos AGENTS.md maliciosos, drift de descripciones de herramientas MCP — comparten todas la misma forma.

Defensas

Trata al harness como la frontera de privilegios que realmente es. Concretamente:

1. Inventaría el harness, no sólo el modelo. Para cada agente de codificación en producción, anota qué claves, archivos, sockets y herramientas puede alcanzar el harness. Ese conjunto — no las capacidades nominales del modelo — es tu radio de impacto. La mayoría de modelos de amenazas se detiene en “engañaron al LLM”; el tuyo debe continuar con “y entonces el harness hizo X”.

2. Trata los built-ins del shell y la expansión de parámetros como sensibles. La lección de la CVE-2026-22708 se generaliza: toda allowlist que clasifica “comando externo vs built-in” pierde privilegios en cuanto los built-ins pueden modificar el entorno del que esos comandos externos dependen. Audita tu propio clasificador de permisos para la misma clase de bypass.

3. Pasa de las allowlists al aislamiento de ejecución. La recomendación de Pillar, retomada por las nuevas guías de Cursor tras el fix, es que las allowlists son, en el mejor de los casos, best-effort. La respuesta robusta es la ejecución en sandbox — contenedores, VMs, árboles de procesos restringidos — para que “el agente ejecutó un comando” nunca signifique “el agente tenía acceso ambiental al directorio personal del desarrollador”.

4. Audita el ensamblaje dinámico del system prompt. Si tu harness recorre directorios padres buscando archivos como CLAUDE.md, AGENTS.md, .cursor/rules o .windsurfrules, trata cada uno de esos archivos como entrada no confiable en cuanto el agente opera en un workspace bajo influencia del atacante. Loguea lo que se inyectó. Haz visible la inyección al usuario antes del primer turno.

5. Audita descripciones de herramientas y registros MCP. Las descripciones son superficies de inyección de prompts. Fija las versiones. Compara descripciones en cada actualización. Rechaza mutaciones silenciosas del registro. La higiene de cadena de suministro que aplicas a tus dependencias aplica aquí.

6. Añade un paso de verificación independiente. Los agentes reportan éxito con regularidad cuando han fracasado — y el mismo modo de fallo cubre comportamientos dirigidos por un atacante. Un paso de verificación que lee la traza independientemente del agente (y que está él mismo fuera del control del agente) es la defensa más barata contra la divergencia entre “el agente dice haber hecho X” y “el log de herramientas del harness dice que hizo Y”.

7. Trata el log de sesión como un secreto. Cifrado en reposo. Redacción de patrones de secreto conocidos al escribir. Política de retención definida. Todo lo que viva en ~/.claude, ~/.cursor, ~/.codex o equivalentes en una estación compartida debe figurar en tu lista de archivos sensibles.

8. Recalibra la respuesta a incidentes. Cuando algo sale mal con un agente de codificación, la primera pregunta es ahora “qué versión del harness, con qué hooks, contra qué workspace” — no “qué modelo”. Construye los campos correspondientes en tu esquema de incidentes.

Estado

Elemento	Referencia	Fecha	Notas
”Your Agent Harness Has More Privilege Than Your Agent”	Pillar Security (Dor Sarig)	2026-05-26	Artículo conceptual — el harness es la frontera de privilegios
”The Agent Security Paradox” / CVE-2026-22708	Pillar Security (Dan Lisichkin)	2026-01-14	Bypass de allowlist en Cursor mediante built-ins del shell
Advisory Cursor GHSA-82wg-qcm4-fp2w	GitHub	2026-01-14	Corregido en Cursor 2.3; versiones afectadas ≤ 2.2
CVE-2026-22708 (NVD)	NIST	2026-01-14	Severidad High; CWE-15 / CWE-20 / CWE-74 / CWE-77 / CWE-78 / CWE-94 / CWE-269
Post-mortem de Claude Code	Anthropic Engineering	2026-04-23	Tres bugs en la capa harness identificados; todos corregidos al 20 de abril (v2.1.116)
Comentario de Simon Willison	simonwillison.net	2026-04-24	Lectura independiente del post-mortem

Lo que conviene retener no es que algún harness en particular esté roto. Es que el harness — Claude Code, Cursor, Codex, Aider, Cline y los demás — se ha convertido silenciosamente en el componente más privilegiado del stack del agente, y el trabajo de seguridad debe seguir esa realidad. Las preguntas interesantes ya no son “¿es seguro el modelo?” ni “¿son seguros los prompts?”. Son: ¿a qué tiene acceso el harness, quién lo controla y cómo sabes lo que realmente hizo?