Los agentes IA de trabajo han cambiado una frontera importante: ya no estamos hablando solo de sistemas que responden texto. Herramientas como Codex pueden leer un proyecto, proponer cambios, ejecutar comandos, revisar código, usar herramientas conectadas y trabajar dentro de un entorno real de desarrollo.
Eso es útil precisamente porque acerca la IA al lugar donde se toman decisiones y se ejecutan acciones. Pero también cambia el riesgo. Un agente con acceso a repositorios, terminal, navegador, CRM, email, automatizaciones o documentación interna no es un asistente abstracto. Es una capa operativa que puede actuar usando nuestra sesión, nuestros permisos y nuestra identidad profesional.
Si esa capa se configura mal, se compromete o recibe instrucciones maliciosas desde una fuente no confiable, el problema no es solo que “se equivoque”. El problema es que puede producir acciones reales atribuidas a una persona, un equipo o una empresa. En el peor caso, podría facilitar fraude, suplantación, fuga de datos, envíos masivos, manipulación de sistemas o campañas coordinadas que parezcan legítimas porque salen de cuentas y herramientas autorizadas.
Este artículo complementa la guía de privacidad y seguridad en agentes IA comerciales, las reglas de negocio en agentes IA y el análisis de qué no debería automatizar un agente IA comercial. El foco aquí es el entorno de trabajo: desarrollo, operaciones, marketing, ventas, documentación y cualquier proceso donde un agente pueda usar herramientas en nombre de una persona.
En resumen
Controlar agentes IA como Codex no significa frenar la productividad. Significa separar claramente qué puede leer, qué puede modificar, qué herramientas puede usar, cuándo necesita aprobación humana y qué queda registrado para auditoría. El riesgo real no está en que el modelo “quiera hacer daño”, sino en combinar identidad, permisos, datos, herramientas y escala sin límites suficientes.
La regla práctica es simple: si un agente puede actuar en tu nombre, debe operar con permisos mínimos, entorno acotado, red controlada, secretos fuera de alcance, revisión humana en acciones sensibles y trazabilidad completa.
Por qué un agente de trabajo no es un chat
Un chat responde. Un agente conectado actúa.
Esa diferencia cambia la arquitectura de seguridad. En un entorno profesional, un agente puede tener acceso a capas muy distintas:
- Repositorios de código.
- Terminal y scripts locales.
- Archivos de proyecto.
- Gestores de paquetes.
- Herramientas de revisión y pull requests.
- Navegador o aplicaciones internas.
- CRM, email, calendarios o documentación.
- Pipelines, despliegues o credenciales si el entorno los expone.
- Automatizaciones que repiten acciones a gran escala.
Cada una de esas capas amplía la superficie de riesgo. Un fallo aislado puede ser reversible. Un fallo con herramientas, permisos y capacidad de repetición puede convertirse en un incidente.
Por eso no conviene evaluar estos agentes como si fueran solo una interfaz conversacional. Hay que evaluarlos como usuarios operativos con una combinación de contexto, autonomía y herramientas.
El riesgo central: identidad delegada
Cuando una persona usa un agente IA dentro de su entorno, muchas acciones pueden quedar asociadas a esa persona: cambios de archivos, comandos ejecutados, mensajes enviados, tickets creados, ramas abiertas, comentarios en PR, tareas en CRM o acciones en herramientas conectadas.
Si alguien compromete esa sesión, abusa de una integración o consigue que el agente actúe sobre instrucciones no confiables, la primera trazabilidad puede apuntar al usuario legítimo. La organización puede ver “lo hizo esta cuenta”, aunque la persona haya sido víctima de una cadena de abuso.
Ese es el punto delicado: el agente puede convertirse en una interfaz de identidad delegada. No solo tiene inteligencia; tiene acceso.
| Superficie | Riesgo si no hay control | Control mínimo |
|---|---|---|
| Repositorio | Cambios no autorizados, introducción de errores o modificaciones difíciles de revisar. | Branches separadas, revisión humana, tests y permisos de escritura acotados. |
| Terminal | Ejecución de comandos con efectos no esperados. | Sandbox, allowlist de comandos, aprobación para acciones sensibles y logs. |
| Archivos locales | Lectura de secretos, contratos, datos personales o material interno. | Deny-read para .env, claves, credenciales y carpetas sensibles. |
| Red | Exfiltración de datos o llamadas a destinos no aprobados. | Red desactivada por defecto o allowlist de dominios estricta. |
| CRM o email | Envíos externos, cambios comerciales o campañas atribuidas a la empresa. | Herramientas granulares, borradores, límites de volumen y aprobación humana. |
| Automatizaciones | Repetición masiva de una acción incorrecta. | Cuotas, rate limits, circuit breakers y revisión de flujos. |
| Producción | Despliegues, cambios de configuración o acceso a datos reales. | Separación de entornos, permisos temporales y aprobación explícita. |
| Logs | Imposibilidad de saber qué ocurrió. | Registro de prompts, comandos, tool calls, usuario, hora y resultado. |
La pregunta correcta no es “¿confiamos en la IA?”. La pregunta correcta es “¿qué podría pasar si esta identidad y estos permisos se usan mal?”.
Campañas masivas: cuando la escala multiplica el daño
La automatización convierte una acción en un patrón repetible. Eso es valioso cuando el patrón es legítimo: revisar tickets, preparar briefings, actualizar documentación, crear tareas o generar borradores.
También es peligroso cuando el patrón se orienta mal. Una cuenta con acceso a email, CRM, redes sociales, repositorios, formularios o herramientas de ads puede producir mucho daño si un agente comprometido ejecuta acciones en masa. No hace falta imaginar un sistema especialmente sofisticado: basta con combinar permisos amplios, baja revisión, ausencia de límites de volumen y una identidad que ya tiene confianza interna.
El riesgo no está solo en “hackear el modelo”. Puede venir de lugares más normales:
- Una sesión abierta en un equipo no protegido.
- Un token o credencial expuesto al entorno del agente.
- Una herramienta conectada con permisos demasiado amplios.
- Un documento externo con instrucciones maliciosas.
- Un workflow que ejecuta lo que el agente devuelve sin validación.
- Una política de aprobación demasiado laxa.
- Un entorno donde no se revisan acciones repetitivas hasta que ya es tarde.
Por eso los agentes de trabajo necesitan controles de escala. Una acción interna de bajo riesgo puede ser automática. Una acción externa, repetida, irreversible o reputacionalmente sensible debe tener límites de volumen, aprobación, observabilidad y capacidad de parada.
El prompt no es suficiente
Un buen prompt ayuda a orientar al agente. Un archivo AGENTS.md ayuda a fijar expectativas del repositorio: comandos de verificación, normas de estilo, límites del proyecto, rutas de despliegue o decisiones que requieren cuidado.
Pero una instrucción no sustituye un control técnico.
Si el agente tiene acceso de escritura a todo el sistema, red abierta, secretos disponibles, herramientas genéricas y autorización para actuar sin aprobación, el prompt está cargando con responsabilidades que deberían pertenecer a la arquitectura.
Los límites importantes deben vivir en varias capas:
- Permisos del entorno: qué puede leer y escribir.
- Sandbox: dónde puede ejecutar comandos.
- Red: si puede conectarse fuera y a qué dominios.
- Herramientas: qué acciones concretas tiene disponibles.
- Aprobaciones: cuándo debe detenerse y pedir revisión.
- Secretos: qué credenciales quedan fuera de alcance.
- Trazabilidad: qué se registra para reconstruir decisiones.
- Política humana: quién revisa cambios, excepciones e incidentes.
Las instrucciones son una capa útil. Los permisos son el límite real.
Controles específicos para Codex y agentes de desarrollo
En el caso de Codex, la documentación oficial describe varias piezas relevantes para operar con más seguridad: sandboxing, políticas de aprobación, control de red, perfiles de permisos, AGENTS.md, configuración gestionada y registros para gobierno empresarial.
El patrón defensivo debería ser este:
| Capa | Cómo aplicarla |
|---|---|
AGENTS.md | Documentar reglas del repo, comandos válidos, alcance del proyecto, restricciones de despliegue y criterios de revisión. |
| Modo read-only | Usarlo para exploración, diagnóstico, planificación o revisión sin cambios. |
| Workspace acotado | Permitir escritura solo en el directorio de trabajo necesario, no en todo el sistema. |
| Deny-read | Bloquear .env, claves SSH, tokens, credenciales, exports de datos y carpetas personales. |
| Red controlada | Mantener red apagada o limitarla a dominios necesarios. |
| Aprobaciones | Exigir confirmación para red, comandos sensibles, escrituras fuera del workspace, despliegues o acciones destructivas. |
| Herramientas granulares | Preferir acciones específicas frente a herramientas genéricas de “hacer cualquier cosa”. |
| Ramas y PRs | Separar trabajo del agente en branches revisables con tests y diff claro. |
| Logs | Conservar actividad suficiente para auditoría, depuración e investigación. |
| Configuración gestionada | En equipos, aplicar perfiles permitidos y restricciones desde una política central. |
El objetivo no es convertir cada tarea en burocracia. El objetivo es que la autonomía dependa del riesgo.
Matriz de autonomía
No todas las acciones requieren el mismo nivel de control. Conviene separar cinco niveles.
| Nivel | Qué puede hacer el agente | Ejemplos | Control recomendado |
|---|---|---|---|
| 1. Observar | Leer información no sensible. | Revisar estructura del repo, documentación pública, archivos de código no secretos. | Read-only y logs básicos. |
| 2. Proponer | Sugerir cambios sin aplicarlos. | Plan de refactor, diagnóstico, checklist de seguridad. | Revisión humana antes de editar. |
| 3. Preparar | Crear borradores o cambios en rama aislada. | Patch, PR draft, email interno, resumen de reunión. | Tests, diff revisable y aprobación antes de publicar. |
| 4. Ejecutar bajo riesgo | Realizar acciones reversibles y acotadas. | Formatear código, actualizar docs, crear tarea interna. | Permisos mínimos, rollback sencillo y registro. |
| 5. Ejecutar alto impacto | Tocar producción, enviar campañas, modificar datos sensibles o actuar externamente. | Despliegues, emails masivos, cambios contractuales, borrado de datos. | Por defecto, no autónomo; requiere aprobación explícita y controles adicionales. |
Esta matriz evita una trampa común: tratar igual una corrección de documentación que un despliegue, una campaña o una acción sobre datos personales.
Qué debería quedar fuera de alcance
Un agente de trabajo no debería tener acceso permanente o automático a todo lo que una persona puede tocar.
Por defecto, conviene dejar fuera:
- Archivos
.envy secretos locales. - Claves SSH, tokens de API y credenciales de despliegue.
- Datos personales, financieros, legales o de salud que no sean necesarios.
- Backups y exports completos de bases de datos.
- Herramientas de envío masivo sin límites.
- Producción salvo en flujos muy controlados.
- Consolas de cloud con permisos amplios.
- Workflows que ejecutan acciones externas sin validación.
- Historiales o documentos privados que no estén vinculados a la tarea.
El agente debe recibir contexto suficiente para trabajar, no acceso indiscriminado al entorno completo.
Señales de que el entorno está mal gobernado
Hay señales prácticas que deberían disparar una revisión:
- El agente puede leer secretos sin necesitarlo.
- Se usa la misma cuenta para desarrollo, producción y automatización.
- No existe diferencia entre lectura, escritura y acciones externas.
- El agente puede acceder a red abierta sin trazabilidad.
- Las herramientas conectadas no tienen scopes específicos.
- Nadie revisa comandos, diffs o tool calls de alto impacto.
- No hay registro central de acciones.
- Las campañas o workflows no tienen límites de volumen.
- No existe un procedimiento claro para revocar permisos.
- La organización no sabe qué agentes están activos ni quién los usa.
Cuando aparecen varias de estas señales, el problema no es el modelo. Es gobierno operativo.
Cómo responder ante un incidente
Si se sospecha que un agente IA ha actuado mal o ha sido comprometido, la respuesta debe ser práctica y rápida.
- Revocar sesiones, tokens y credenciales vinculadas.
- Detener automatizaciones y tareas programadas relacionadas.
- Aislar el entorno donde operaba el agente.
- Revisar logs de comandos, tool calls, archivos tocados, mensajes enviados y destinos de red.
- Identificar cambios en repositorios, CRM, email, documentación y producción.
- Revertir acciones erróneas cuando sea posible.
- Rotar secretos que pudieron quedar expuestos.
- Revisar permisos antes de reactivar el flujo.
- Documentar causa, alcance, impacto y controles añadidos.
La respuesta no debería depender de recordar qué pasó en una conversación. Debe poder reconstruirse desde registros verificables.
Cómo lo plantearía Nicolás Torres
Para Nicolás Torres, el control de agentes IA empieza antes de conectarlos a herramientas. La pregunta inicial no es “qué puede automatizar el agente”, sino “qué identidad, datos y permisos va a heredar”.
El enfoque sería:
- Mapear el entorno: repositorios, herramientas, datos, credenciales, acciones externas y responsables.
- Clasificar riesgos: bajo, medio o alto según impacto, reversibilidad, sensibilidad y escala.
- Definir permisos mínimos: lectura, escritura, red y herramientas solo donde aportan valor.
- Separar identidades: usuarios humanos, cuentas de servicio y automatizaciones no deberían mezclarse sin criterio.
- Diseñar aprobaciones: toda acción externa, irreversible o sensible debe tener revisión humana.
- Registrar actividad: comandos, cambios, tool calls, decisiones, usuario y resultado.
- Probar escenarios de abuso: no para enseñar a atacar, sino para comprobar que los límites funcionan.
- Revisar periódicamente: permisos, logs, excepciones, campañas, integraciones y accesos activos.
Un agente IA bien gobernado puede aumentar productividad sin convertir el entorno de trabajo en una caja negra. La confianza no debería venir de asumir que el agente “se portará bien”. Debería venir de límites técnicos, revisión humana y trazabilidad suficiente para saber qué ocurrió, quién autorizó cada acción y cómo detener el flujo si algo se desvía.
La potencia de estos agentes es real. Precisamente por eso hay que tratarlos como una parte seria del sistema operativo de la empresa.
Preguntas frecuentes
- ¿Por qué hay que controlar agentes IA como Codex?
- Porque pueden trabajar sobre repositorios, archivos, terminales, herramientas externas y datos de la organización. Si tienen demasiados permisos, un error o compromiso puede convertirse en acciones reales hechas con nuestra identidad.
- ¿Qué riesgo aparece si un agente IA es comprometido?
- Puede facilitar cambios no autorizados, fuga de datos, envíos externos, manipulación de sistemas, campañas masivas o acciones que parezcan ejecutadas por una persona o empresa legítima.
- ¿Basta con escribir buenas instrucciones en el prompt?
- No. Las instrucciones ayudan, pero los límites críticos deben estar en permisos, sandboxing, aprobación humana, herramientas acotadas, logs, revisión y políticas de acceso.
- ¿Qué permisos debería tener un agente IA de trabajo?
- Solo los necesarios para la tarea concreta: lectura o escritura limitada al workspace, red desactivada o allowlist, secretos fuera de alcance, herramientas específicas y aprobación para acciones sensibles.
- ¿Cómo se detecta uso indebido de un agente IA?
- Con registros de actividad, trazabilidad de comandos y herramientas, revisión de cambios, alertas sobre acciones inusuales, separación de identidades y capacidad de revocar accesos rápidamente.