La agenda del 6 de agosto de Black Hat USA 2026 incluyó varias sesiones sobre seguridad para agentes de inteligencia artificial. Los temas fueron concretos: guardrails, red teaming y uso de entornos aislados para proteger credenciales, datos e infraestructura.
Es una preocupación razonable. Los agentes de programación ya pueden leer repositorios, editar archivos y ejecutar comandos. Darles acceso a producción sin límites amplía demasiado el daño que puede causar una instrucción equivocada.
Un agente puede hacer cambios reales
Un chatbot entrega una respuesta. Un agente también puede actuar sobre el sistema. Puede instalar una dependencia, consultar un servicio o modificar una configuración.
Claude Code y OpenCode permiten revisar permisos antes de ejecutar acciones. Aun así, después de varias respuestas correctas es fácil empezar a aprobar todo de forma automática.
El riesgo no requiere una IA maliciosa. Una variable mal escrita puede apuntar al entorno equivocado. Un comando demasiado amplio puede borrar datos. Un archivo con secretos puede terminar dentro del contexto enviado a un proveedor.
Cómo limitar el acceso
Empezaría con un entorno aislado, credenciales temporales y datos de prueba. El agente sólo debería ver los archivos y servicios necesarios para completar la tarea.
Cuando haga falta llegar a producción, el permiso puede limitarse a una acción concreta y durante poco tiempo. También conviene registrar los comandos ejecutados y conservar una forma de revertir cada cambio.
La pantalla de aprobación debe explicar qué va a ocurrir. Saber que el agente quiere “usar una herramienta” no alcanza; necesitamos ver el comando, el destino y los archivos afectados.
La seguridad se define antes de usar el agente
Los límites funcionan mejor cuando forman parte del flujo de trabajo. El agente prepara el cambio, las pruebas revisan el comportamiento, una persona aprueba y el despliegue mantiene una opción de regreso.
Este proceso no impide aprovechar la IA. Evita que una tarea rápida termine con permisos que nadie recuerda haber concedido.
Qué cambiaría hoy
Revisaría qué agentes pueden leer variables de producción, desplegar o consultar datos de clientes. Si una sola sesión puede hacer las tres cosas, separaría esos permisos.
También usaría credenciales distintas por proyecto y por entorno. Si una clave se filtra, el alcance del problema será menor.
Black Hat puso estos temas sobre la mesa porque los agentes ya forman parte del trabajo diario. Su acceso debería crecer poco a poco y sólo cuando exista una razón clara.
¿Te pareció útil o estás en desacuerdo?
Comentarios
¿Qué opinas?
Todavía no hay comentarios aprobados.