Un hook es, básicamente, un script que el agente de IA corre en un momento fijo. El más útil es el que se ejecuta antes de usar una herramienta.
El ejemplo más pequeño que funciona: un hook de PreToolUse en Claude Code que recibe lo que el agente está por hacer y, si el comando intenta leer .env, responde que no. El agente no lee el archivo y además se entera de por qué. Es muy sencillo, y es un control de verdad: no depende de que el modelo “se porte bien”, porque lo ejecuta el programa, no el modelo.
Con hooks se pueden hacer cosas muy valiosas. Bloquear comandos peligrosos, buscar secretos antes de que algo salga, pedir una revisión antes de un git push o dejar registro de cada archivo que el agente editó. Hoy los tienen Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI y Windsurf, cada uno con sus propios nombres de eventos.
El problema: viven en la laptop
Los hooks se configuran en un archivo. En Claude Code, por ejemplo, en settings.json, que puede estar en el proyecto o en la carpeta del usuario. Y ese archivo lo puede editar quien usa la máquina.
O sea, el mismo desarrollador al que el hook quiere controlar puede apagarlo. Puede borrar la línea, usar la opción que desactiva todos los hooks o, más simple todavía, abrir otro agente que no tenga ninguno. No hace falta mala intención: basta un hook que lo frena cuando está apurado.
Para un banco esto importa mucho. Un control que el controlado puede apagar no se puede presentar a un auditor como control.
Lo que ofrece cada fabricante
Los fabricantes lo saben, y casi todos ofrecen una forma de que la empresa imponga hooks. Revisé la documentación de cada uno en octubre de 2026:
| Agente | Gestión central de hooks | Qué la hace cumplir |
|---|---|---|
| Claude Code | managed-settings.json por MDM, o configuración desde la consola de claude.ai. allowManagedHooksOnly ignora los hooks del usuario y del proyecto |
El archivo protegido por el sistema operativo |
| Codex | requirements.toml por MDM o desde la consola de ChatGPT. allow_managed_hooks_only deja solo los hooks de la empresa |
El archivo en la máquina o el inicio de sesión con la cuenta de la empresa |
| Cursor | hooks.json de sistema por MDM, o hooks del equipo desde el panel (Enterprise) |
El archivo de sistema, si el usuario no es administrador |
| GitHub Copilot | Hooks de política en una carpeta del sistema, que no se apagan con disableAllHooks. Solo en Copilot CLI |
Archivos de root que el usuario no puede escribir |
| Gemini CLI | Archivo de configuración de sistema que manda sobre el del usuario | El archivo en la máquina |
| Windsurf | hooks.json de sistema, o hooks distribuidos desde el panel del equipo |
Archivos que no se cambian sin permisos de root |
Es un avance real. Con allowManagedHooksOnly, por ejemplo, Claude Code ignora los hooks del usuario y del proyecto y corre solo los que puso la empresa.
Por qué igual no alcanza
Lo más honesto lo dice el propio Anthropic. Sobre su configuración desde la consola, escribe que funciona como “un control del lado del cliente, no una frontera de seguridad”, y que en un equipo no gestionado “el usuario no necesita ser administrador para saltársela”. Google dice algo parecido de Gemini CLI: que sus controles no deben considerarse una frontera de seguridad infalible.
No es un descuido de esos productos; es que el control se aplica en una máquina que maneja otra persona. Para que de verdad resista, la empresa necesita varias cosas a la vez:
- Que cada laptop esté gestionada por MDM y que el desarrollador no sea administrador. En muchos equipos de desarrollo eso no pasa, porque necesitan instalar herramientas todo el día.
- Configurar cada agente por separado, con su formato y sus nombres. Seis agentes, seis políticas.
- Asegurarse de que nadie use otro agente, otra cuenta u otro proveedor del modelo. La documentación de Claude Code lo dice directamente: la configuración gestionada aplica solo a Claude Code, y quien llama a la API desde otra herramienta queda fuera.
- Revisar qué pasa cuando un hook falla. En varios de estos productos, si el script da error o se demora, la acción sigue.
Y aun con todo eso, el agente corre en la laptop, con el repositorio y muchas veces con las credenciales del desarrollador a su alcance.
Cómo lo resuelve Harkaq
La idea de Harkaq es sacar el control de la máquina del desarrollador.
Primero, el agente no corre en la laptop. Corre en una celda: un espacio aislado que controla la empresa, sin contraseñas ni llaves adentro. La configuración del agente, incluidos sus hooks y sus instrucciones, la pone Harkaq y queda en solo lectura. El desarrollador trabaja con libertad dentro de la celda, pero no es administrador de ella, igual que no es administrador del servidor de producción. No puede apagar lo que no está en su máquina.
Segundo, y para mí lo más importante: no dependemos de que el hook se ejecute. Todo lo que sale de la celda pasa por el gateway, la única puerta. El gateway revisa cada acción, busca secretos, pone las llaves sin que el agente las vea y lo registra. Si un hook no corrió, o si el agente es uno que ni siquiera tiene hooks, la regla se aplica igual, porque se aplica afuera.
Tercero, la regla es una sola para todos los agentes. Seguridad la define una vez en Harkaq y vale igual para Claude Code que para Codex. No hay que mantener seis formatos.
Y cuando el agente necesita algo fuera de la regla, lo pide, y decide otra persona. Es, si quieren, el hook más difícil de apagar que existe: uno que no vive en la máquina de quien pide permiso.
Los hooks siguen siendo útiles dentro de la celda. Le dan al agente una respuesta rápida y le explican por qué algo no se puede. Pero la garantía no puede depender de ellos.
Lo que aprendí revisando todo esto es simple: un control que vive en la máquina del controlado es un buen hábito, no un control. Para que una empresa pueda decir que sí a los agentes, el que ataja tiene que estar afuera.