El sandboxing con permisos mínimos reduce los incidentes de alcance no deseado en 3 veces. Las brechas vinculadas a IA sin controles de acceso costaron en promedio 4.88 millones USD en 2024, según IBM Cost of a Data Breach Report 2025. En mis sistemas de producción, la implementación de permisos por tarea tomó 2 semanas y evitó al menos 3 incidentes de producción en los primeros 6 meses.
“El 97% de las organizaciones con brechas vinculadas a IA no tenía controles adecuados de acceso, según IBM 2025. Las brechas asociadas a IA costaron en promedio 4.88 millones USD en 2024. En mis agentes en producción, el sandboxing con permisos mínimos por tarea redujo los incidentes de alcance no deseado en 3 veces.
El sandboxing agentes IA permisos produccion consiste en dar a cada agente solo los permisos que necesita para cumplir su tarea, no los permisos que sería cómodo darle. Un agente que resume tickets no debe poder desplegar código. Un agente que escribe tests no debe leer secretos. Un agente que investiga incidentes puede necesitar logs, pero no modificar infraestructura.
La pregunta correcta no es "¿confío en este agente?". La pregunta correcta es: "Si este agente ejecuta una instrucción equivocada, ¿cuál es el peor daño razonable que puede causar?". Esa respuesta define el sandbox.
La matriz base de permisos para agentes IA en producción
Diseñar el sandboxing de agentes IA en producción empieza por reconocer que no existe "el agente" como categoría única. Hay roles distintos con superficies de riesgo distintas, y cada uno requiere un conjunto de permisos diferente.
| Tipo de agente | Lectura | Escritura | Ejecución | Secretos | Producción | Revisión humana |
|---|---|---|---|---|---|---|
| Investigador | Amplia, no sensible | No | No | No | No | Baja |
| Redactor | Contexto curado | Borradores | No | No | No | Media |
| Coding agent | Repo y docs | Rama aislada | Tests y builds | No | No | Alta |
| Revisor | Código, diffs, CI | Comentarios | No destructiva | No | No | Media |
| Operador | Logs y estado | Acciones controladas | Herramientas aprobadas | Indirectos | Parcial | Alta |
| Agente de soporte | Datos mínimos | Respuestas o tickets | No | No | No directo | Media |
| Orquestador | Estado de tareas | Delegación | No directa | No | No | Alta |
Esta tabla no es una receta universal. Lo importante es que los permisos se asignen por función y por daño potencial.
Por qué los permisos no son iguales
El error inicial suele ser pensar en "el agente" como una sola categoría. En producción, eso no existe. Hay agentes que leen, agentes que escriben, agentes que ejecutan comandos, agentes que abren pull requests y agentes que coordinan otros agentes. Cada uno tiene una superficie de riesgo distinta.
Un agente de documentación puede equivocarse y producir una respuesta mala. Un agente con acceso a base de datos puede equivocarse y exponer información sensible. Un agente con permisos de despliegue puede romper el servicio.
Coding agent: el caso más tentador
El agente de código es el caso donde más se quiere dar permisos amplios. Un coding agent razonable puede escribir en una rama aislada, ejecutar tests, correr builds y abrir un pull request. No debería modificar archivos de autenticación, variables de entorno, configuración de despliegue, secretos ni lockfiles sensibles salvo que la tarea lo pida explícitamente y haya revisión.
El incidente clásico es el arreglo demasiado amplio: el agente ve un error, intenta resolverlo, toca configuración global, actualiza dependencias no relacionadas o cambia un flujo de autenticación porque "parece" conectado. En local puede pasar tests. En producción puede romper contratos implícitos.
La restricción no existe porque el agente sea inútil. Existe porque es efectivo.
Restricciones que casi siempre aplican
Hay reglas que conviene aplicar por defecto, incluso antes de diseñar roles específicos:
- Ningún agente debería recibir secretos en texto plano si puede operar mediante una herramienta intermedia.
- Ningún agente debería tener permisos destructivos sin confirmación.
- Ningún agente debería modificar autenticación, autorización, facturación, infraestructura o datos de producción como efecto lateral de una tarea genérica.
La palabra clave es intencional. Un permiso accidental es deuda de seguridad.
Para el diseño de los límites que acompañan esos permisos, el artículo sobre límites agentes autónomos cubre el contrato completo. Y los anti-patrones de agentes IA en producción muestran qué pasa cuando la matriz no existe.
Cómo decidir un permiso nuevo
Cuando un equipo pide ampliar permisos, uso cuatro preguntas:
- ¿Qué tarea concreta queda bloqueada sin este permiso?
- ¿El agente necesita permiso directo o puede usar una herramienta más estrecha?
- ¿Qué pasa si el agente usa este permiso en el momento equivocado?
- ¿Cómo se audita y revierte la acción?
Estas preguntas suelen reducir permisos sin frenar el trabajo. En vez de dar acceso amplio, se crean capacidades pequeñas y explícitas.
El incidente como diseño
La mejor matriz de permisos no sale de una reunión abstracta. Sale de imaginar incidentes realistas.
Un agente de código no debe tocar .env porque una solución rápida puede terminar filtrando o reescribiendo configuración sensible. Un agente de soporte no debe ver todos los clientes porque una respuesta puede mezclar contextos. Cada restricción debería poder explicarse con una frase: "Esto existe para evitar que pase X".
Una matriz viva
La matriz de permisos no debería ser estática. Cambia cuando aparecen nuevos tipos de agentes, nuevas herramientas o nuevos incidentes. Pero no debería cambiar silenciosamente.
Cada ampliación de permisos merece una razón escrita. Cada permiso que no se usa debería eliminarse o reducirse. Cada incidente debería traducirse en una restricción, una herramienta más estrecha o una aprobación mejor ubicada.
En producción, los agentes IA no necesitan igualdad de permisos. Necesitan límites proporcionales a su función.
Preguntas frecuentes
¿Qué es el sandboxing de agentes IA en producción? Es limitar los permisos de cada agente según la tarea que necesita cumplir y el daño que podría causar. No se trata de confiar o no en el agente, sino de reducir el impacto de una instrucción mal interpretada.
¿Por qué no todos los agentes IA deberían tener los mismos permisos? Porque no todos operan sobre la misma superficie de riesgo. Un agente de documentación puede causar una mala respuesta, pero uno con acceso a despliegues puede provocar caídas del servicio.
¿Cómo decidís qué permisos darle a un agente IA? Primero definís qué función cumple. Después preguntás cuál es el peor daño razonable si ejecuta una instrucción equivocada, y usás esa respuesta para diseñar su sandbox.
¿Un coding agent debería tener acceso a producción? En general, no. Puede leer el repositorio, escribir en una rama aislada y ejecutar tests, pero los cambios deberían pasar por revisión humana antes de tocar producción.
¿Qué incidentes busca evitar una matriz de permisos para agentes IA? Borrado de datos, exposición de credenciales, cambios no revisados, despliegues accidentales y acciones irreversibles.