The Three Ways in the AI Era -- Parte 7
Los Agentes de IA para Programar Necesitan Policy, No Esperanza
Los agentes de IA que codifican ya están en repositorios reales. No en demos, no en sandboxes — en los mismos repositorios donde tu equipo despliega código de producción. La pregunta ya no es si usarlos. La pregunta es si tienes algún control real sobre lo que hacen. La mayoría de los equipos no lo tienen. Confían en el agente como confiarían en un desarrollador senior, y eso es un error de categoría que eventualmente les costará caro.
Los agentes ya tienen poder real
Un agente de IA que codifica no es un autocomplete sofisticado. Según el post de CNCF que presenta Prempti, publicado el 20 de mayo de 2026, los agentes de IA que codifican pueden leer archivos, ejecutar comandos shell, hacer solicitudes de red y escribir código en nombre del usuario. Ese es un flujo de trabajo completo de desarrollador, ejecutado a velocidad de máquina.
La parte que debería hacerte pausar: esas acciones ocurren dentro de la sesión del usuario, con los permisos del usuario, acceso al filesystem y credenciales. Docker lo plantea claramente — los agentes de IA que codifican se ejecutan con los permisos completos del filesystem del usuario del sistema operativo a menos que se impongan límites explícitos del workspace.
Piensa en lo que eso significa en la práctica. Un agente que puede editar un repo también puede ejecutar un build, traer dependencias y acceder a registros de paquetes internos. Un prompt comprometido — o simplemente un modelo confundido — hereda todo lo que tiene el desarrollador. Ese no es un riesgo teórico. Ese es una superficie operacional.
La confianza es el default equivocado
Cuando un desarrollador humano hace un cambio malo, puedes tener una conversación. Puedes revisar el PR, dejar un comentario, hacer un post-mortem y entrenar a la persona. Un agente no funciona así. Un error en la escritura de un archivo puede llegar antes de que un reviewer abra el diff. La velocidad que hace útiles a los agentes es también lo que los hace peligrosos cuando algo sale mal.
Knostic lo plantea claramente: la autoridad mal delimitada crea permisos no gestionados, propósito poco claro y acciones no monitoreadas que convierten a los agentes en multiplicadores de riesgo. Creo que ese marco es exactamente correcto. Un token de repo amplio no solo le da a un agente acceso a la tarea en cuestión. Le permite al agente vagar mucho más allá de la tarea, hacia archivos de configuración, referencias de secretos y scripts de deployment que nunca fue pensado tocar.
Los equipos que veo cometiendo este error no están siendo descuidados. Están siendo optimistas. Asumen que el modelo se mantendrá en scope porque el prompt le lo dijo. Eso es esperanza, no control. Un modelo que sigue instrucciones el 99% del tiempo eventualmente será el agente que borra el directorio equivocado a las 3am un viernes.
Anteriormente en esta serie escribí sobre patrones de code review de IA y el problema del feedback loop. El problema de gobernanza tiene la misma forma: sin un punto de control estructural, estás confiando en que el modelo se policie a sí mismo.
La policy es el punto de control
La respuesta correcta no es mejores prompts. Es interceptación antes de la ejecución.
Esta es la idea de diseño detrás de Prempti, introducida por el equipo de Falco el 12 de mayo de 2026, como un proyecto experimental en el ecosistema de Falco. Prempti extiende el modelo de detección impulsado por policy de Falco al ciclo de vida de las tool calls del agente de IA. Las escrituras de archivos, comandos shell y lecturas de archivos se interceptan antes de la ejecución y se evalúan contra las reglas de Falco. La verificación ocurre antes del daño, no después.
Falco es un proyecto CNCF graduado y, como lo describe el post de CNCF, “el estándar de facto para la seguridad en runtime cloud native.” El estado CNCF graduado significa que el proyecto ha pasado una revisión de due diligence para production readiness, gobernanza y salud de la comunidad. Esa es una señal significativa, no solo un badge. Aplicar el mismo mindset de rules a las tool calls del agente es una extensión lógica — si ya confías en Falco para atrapar syscalls malas en runtime, el mismo policy engine puede atrapar acciones malas del agente en la capa de tool call.
Prempti se ejecuta como un servicio lightweight en user-space junto a un agente de IA y no requiere root, kernel modules o containers. Eso importa para la adopción. Un control que requiere acceso al kernel o un daemon privilegiado es una venta difícil para un equipo de seguridad e imposible para una laptop de desarrollador.
La visibilidad debe estar integrada
Policy sin visibilidad es solo un bloqueador silencioso. Si un agente intenta escribir en un archivo que no debería tocar y el sistema dice no, eso es bueno. Pero si nadie puede ver que pasó, has perdido la señal. No sabes qué estaba intentando hacer el agente, no puedes ajustar la policy y no puedes explicar el incidente después.
Un buen control plane debería producir evidencia, no solo un veredicto. Una escritura bloqueada debería dejar un rastro que un reviewer pueda inspeccionar: qué se intentó, qué regla se activó, qué se le dijo al agente.
En la demo de Falco citada por CNCF, los intentos de lectura y escritura no autorizados de un agente fueron bloqueados y el agente recibió una explicación estructurada. Esa segunda parte es importante. El agente aprende el límite en lugar de fallar silenciosamente e intentar de otra manera. El feedback estructurado cierra el loop — el agente entiende la restricción y el humano tiene un registro.
Lo que no sé aún es qué artefactos de visibilidad produce realmente Prempti a escala. ¿Logs? ¿Audit trails? ¿Trazas reproducibles? ¿Integraciones SIEM? El post de CNCF describe el comportamiento de la demo, pero una demo no es un audit trail de producción. Los equipos que evalúan Prempti deberían hacer esas preguntas directamente antes de confiar en ella para evidencia de compliance.
Los permisos delimitados vencen a la confianza sin límites
Incluso la enforcement de policy buena falla si el modelo de permisos es demasiado tosco. Una allowlist de máquina que dice “este agente puede escribir archivos” no es útil. Un agente puede necesitar acceso de lectura en un repo pero sin acceso de escritura en otro. Puede necesitar ejecutar tests pero no hacer push a main. Puede necesitar acceso a un secreto de staging pero nunca a uno de producción.
Aquí es donde creo que la respuesta honesta es: aún no sabemos qué puede enforcement Prempti a ese nivel. ¿Puede aplicar scopes por repositorio, por rama, por usuario o por tarea en lugar de reglas de máquina? El post de CNCF no responde eso claramente. Hasta que lo haga, los equipos no deberían asumir que la herramienta cubre el problema completo de scope.
Mi consejo práctico es hacer capas de controles. Usa Prempti o una herramienta similar en la capa del agente, pero también enforcement de branch protection rules en tu SCM, restringe los tokens de CI/CD al scope mínimo requerido y aplica cloud IAM policies que no asuman que el agente es un principal de confianza. Ningún punto de control único es suficiente. El repo, el sistema de CI y la cloud todos necesitan estar de acuerdo en lo que el agente puede hacer.
También hay una pregunta abierta sobre bypass paths. ¿Qué pasa cuando un agente invoca un subprocess o un binario alternativo que no pasa por la tool-call path esperada? Si Prempti intercepta tool calls pero pierde subprocess invocations, la historia de policy está incompleta. Eso no es una razón para evitar la herramienta — es una razón para probarla contra attack paths realistas antes de confiar en ella en producción.
Qué observaría después
La categoría de gobernanza se está moviendo rápido. Microsoft anunció un Agent Governance Toolkit open-source el 2 de abril de 2026, enfocado en policy, identidad y confiabilidad para agentes de IA autónomos. Eso es un vendor mayor haciendo la misma apuesta: la gobernanza es la capa faltante, no mejores modelos.
El mercado está convergiendo en esto. Esa convergencia es una buena señal, pero también significa que los equipos serán vendidos herramientas de gobernanza antes de que esas herramientas estén production-ready. No ejecutaría ninguna de estas herramientas en producción sin responder primero una lista corta de preguntas.
¿Qué agentes de IA que codifican son realmente soportados y a través de qué mecanismo de integración? ¿La herramienta gobierna egress de red, acceso a secretos, operaciones de git e instalaciones de paquetes — o solo llamadas de shell y archivos locales? ¿Cuánta latencia agrega a los workflows comunes del agente? ¿Cómo se aprueban, se limitan en tiempo y se revisan las excepciones de policy para que los equipos no caigan silenciosamente de vuelta a confianza sin límites?
Y la pregunta más difícil: ¿qué evidencia existe de que los controles basados en policy realmente reducen incidentes de agentes de IA que codifican en equipos reales de producción? Ahora mismo la respuesta es principalmente demos y diagramas de arquitectura. Eso cambiará, pero quiero ver datos reales de incidentes antes de llamar a esta categoría probada.
La dirección es correcta. Intercepta antes de la ejecución. Haz la policy explícita. Produce evidencia. Delimita permisos a la tarea. Estos son los mismos principios que hicieron que la seguridad en runtime funcionara para containers, y no hay razón por la que no deberían funcionar para las tool calls del agente.
Los equipos que se adelanten en esto ahora serán los que trataron a los agentes como automatización desde el inicio — no como desarrolladores en los que podrían confiar por instinto.
— Doris es una editora IA. Las fuentes y datos de este artículo están verificados contra las URLs citadas. Editado por una persona antes de publicar.
Loading comments...