¿Agentes de IA autónomos y seguros? Mi setup en 2026
Publicado no IA Dots ·
Agentes de IAAI Signaldot-ai_agentsdot-artificial_intelligenceEspanholidioma-esyt-4QiETtzqw2c
Vídeo em Espanhol, publicado pelo canal pirobits.
Sobre este contenido: El resumen, los puntos principales y los temas que aparecen a continuación se generan automáticamente a partir de la transcripción del vídeo. Reflejan el contenido, las opiniones, afirmaciones y predicciones presentadas en el vídeo y no representan una posición, validación o verificación de hechos por parte de IA Dots.
Resumen del vídeo
El vídeo explica cómo configurar un entorno seguro y aislado (sandbox) en 2026 para programar con agentes de IA autónomos, protegiendo los datos personales y evitando ataques de inyección de prompts, además de avanzar hacia una factoría de software.
Puntos principales
- El creador utiliza principalmente aplicaciones de escritorio de Codex y Claude, además de la terminal, habiendo abandonado el uso de IDEs tradicionales como Visual Studio Code.
- Se destaca el riesgo de que los agentes de IA con acceso de lectura a todo el disco local puedan exponer información personal o credenciales debido a un ataque de prompt injection.
- Para mitigar riesgos, se recomienda utilizar entornos aislados (sandbox) ejecutando los agentes en máquinas virtuales locales con herramientas como Lima o mediante un homelab remoto con Proxmox.
- El uso de modos automáticos en los agentes permite ganar velocidad, pero requiere una capa adicional de seguridad para revisar los comandos ejecutados.
- Se propone aislar las credenciales y las claves de API fuera del entorno de desarrollo mediante pasarelas (gateways), tokens de acceso personal limitados y cuentas de bot separadas para los commits.
Temas
Inteligencia ArtificialSeguridad informáticaAgentes autónomosEntorno de desarrolloMáquinas virtualesControl de versionesFactoría de software
Transcripción del vídeo
Texto de los subtítulos disponibles; puede contener errores.
En el vídeo de hoy, quiero enseñarte cuál es mi sandbox para programar con IA de forma segura en 2026. Prácticamente, llevo un año sin subir vídeo y la evolución de la IA este último año ha sido una locura. Por eso, en el vídeo de hoy quiero contarte cómo puedes dar autonomía a tus agentes teniendo cuidado de tus datos y de un prompt injection. De forma rápida, quiero contarte cuál es mi stack, cómo podemos conseguir darle autonomía a los agentes sin que haya sorpresa, cómo podemos montar un sandbox en local o en remoto, la importancia de tener los secretos fuera del entorno de desarrollo y el camino hacia una software factory. Quiero destacar que este es mi setup hoy y aunque más o menos es estable, evoluciona cada día. Dentro de un mes podría estar obsoleto. Lo primero es contarte cuál es mi entorno de desarrollo actual y me siento más cómodo utilizando las aplicaciones de escritorio tanto de Codex como de Claude. Me parece que están muy pulidas y además te permiten ver los cambios y revisar el código. Prácticamente, yo no utilizo Visual Studio Code o ningún otro IDE. Si estoy trabajando en remoto en alguna máquina virtual, me gusta utilizar coder, que te permite tener los agentes independientemente de la conexión SSH. Otro detalle importante es el coding harness, que básicamente son las herramientas que envuelven al modelo para la hora de programar. Este último año he estado utilizando Codex y a día de hoy, eh, GPT 6.1 sol me gusta bastante. Aunque en las últimas semanas o meses he estado utilizando un poquito más los modelos de Anthropic, como Sonet u Opus junto con Claude Me siento más cómodo utilizando estos modelos y por ejemplo, esta presentación la he hecho con Claude y la verdad es que me ha encantado. También quiero destacar Open Code, que además de poder utilizar la suscripción de Codex, te permite utilizar modelos libres y también el Pi Agent, que es muy interesante porque te permite crear o reutilizar su SDK para crear cualquier tipo de agente, asistente, etcétera. Esto da para otro vídeo y en otro vídeo te puedo enseñar cómo creo mis propios agentes o mis propios asistentes, que no son para programar, sino para, por ejemplo, un agente conversacional. En resumen, destacar que ya no utilizo ningún IDE, antes utilizaba Visual Studio Code, ahora, como te digo, utilizo o la terminal o las aplicaciones de escritorio, y que me he centrado principalmente en diseñar el sistema, comprender bien cómo se desarrolla el software, que de esto podemos hablar en otro vídeo, dedicarlo a buenos patrones, buena arquitectura, y principalmente me apoyo en la IA para, por un lado, mejorar yo, y que, eh, como bien está pasando hoy en día, yo ya no programo. Y por eso tenemos que aceptar la imperfección del código, es decir, hay partes del código que son totalmente irrelevantes cómo estén. Eso sí, es muy importante tener buen criterio y desarrollarlo para saber qué partes del código son críticas, revisarlas al detalle, y también tener muy en cuenta la seguridad. Por ejemplo, no es lo mismo estar haciéndote una aplicación para contarte las calorías o para gestionar tu tu entrenamiento, que es algo que vas a utilizar solo tú, a una aplicación que vas a poner en producción y que está expuesta a todo tipo de vulnerabilidades, de agentes o de personas que estén intentando explotarla. Así que esto, muy importante. Además, quiero destacar una frase que leí por internet de alguien que decía que ahora, si en una hora es mucho más productiva, porque la gente hace lo que tú hacías antes en varias horas o días, no cuesta nada dedicar otra hora a revisar y entender bien este código. Pero como digo, lo importante es entender de sistema, de arquitectura, y apoyarte mucho en la IA. También quiero destacar, y el principal motivo de este vídeo, es que hoy los agentes tienen acceso a toda la información que tienes en local, es decir, prácticamente toda tu vida digital, porque normalmente en el ordenador tenemos credenciales, tenemos las sesiones del navegador, tenemos ficheros, y un prompt injection podría llevar al modelo a acceder a esto a todos estos ficheros. Y por defecto, todas estas herramientas tienen acceso de lectura prácticamente a la mayoría de ficheros en el disco. Al principio, hace ya un año prácticamente, los permisos eran manuales, es decir, nosotros íbamos aprobando cada cosa que hacía la gente. Esto es seguro, pero también es tedioso por dos motivos. Primero, porque no estamos aprovechando todo el potencial de velocidad que nos da la IA y aparte también requiere fatiga, porque al final tienes que revisar cada comando, llega un momento en el que no le prestas la misma atención. Por eso surgió el modo auto, que es mucho más rápido, pero no tiene 100% de garantía de que sea seguro, en el que hay otro subagente o algún modelo que se encarga de analizar la seguridad de los comandos que ejecuta. Esto me ha llevado a tener un sandbox en el que no hay credenciales dentro, en el que los ficheros son limitados y el agente tiene mucha más autonomía. Además, el modo auto te ayuda a tener una barrera extra de seguridad. En local lo que he hecho ha sido limitar los permisos a los agentes para que prácticamente no puedan hacer nada y así obligarme a desarrollar en remoto. Que básicamente hay dos formas. La primera y la más cómoda es crearte una máquina virtual dentro de tu Mac, tu Linux, Windows o el sistema que tú utilices. Yo utilizo Mac. En mi caso utilizo Lima, que te permite crear máquinas virtuales Linux dentro de Mac OS y es muy interesante, porque al final aquí puedes instalarte un agente, compartir una carpeta donde tienes tus proyectos y así prácticamente no hay credenciales ni acceso a tu sistema operativo. Si no te quieres complicar, también puedes usar Docker, aunque este comparte el kernel y no es tan seguro como una máquina virtual. Si no quieres utilizar la terminal, también puedes crearte una máquina virtual visual con UTM o cualquier otra herramienta. Todas estas herramientas que te voy mencionando son libres y gratuitas, por lo que las podéis descargar y utilizarla. Lo bueno de esto es que puedes utilizar Cloud Code o Codex o cualquier otro agente al que tú utilices dentro de la terminal desde el CLI, pero también puedes crearte una sesión como con Claude RC y utilizarlo de forma remota en la aplicación desktop o en tu móvil y seguir trabajando en remoto. También puedes acceder con SSH, aunque normalmente es un poco más raro hacerlo en local. La siguiente opción es trabajar en una máquina virtual en remoto. Puedes alquilarte un VPS en cualquier plataforma. En mi caso, tengo un homelab en casa, me compré un mini PC justo antes de la subida de precios de la RAM y tengo un tengo Proxmox y aquí tengo varias máquinas virtuales, una de ellas es DevLab donde tengo mis agentes y los proyectos. He conseguido eliminar prácticamente todas las credenciales menos dos, una es la sesión de Cloud de Codex o la que esté utilizando y otra es mi cuenta de GitHub. La semana que viene quiero enseñarte cómo montar un Gateway para que estas credenciales ya no estén dentro y se inyecten de forma dinámica, de forma que la gente ya no tenga acceso a ninguna credencial. ¿Qué es lo bueno de esto? Que podemos conseguir que la gente trabaje de forma autónoma prácticamente sin riesgo o minimizando los riesgos. Y en vez de hacer login con mi cuenta personal, he creado lo primero un personal access token donde limito el acceso a las acciones que pueda hacer, de forma que solo pueda ver y escribir en los repositorios o en las issues, ya que también yo las issues yo las gestiono en GitHub, me resulta más cómodo tenerlo todo junto. El siguiente paso es crear una cuenta de bot que GitHub te permite tener una por cada usuario o eh una GitHub app, de forma que los commits que haga el bot estén en una cuenta separada y puedas tener reglas que protejan tu rama main. Por ejemplo, si tienes integración continua y cuando mezclas algo en main se despliega producción, como en mi caso, yo trabajo en local y cuando hago un commit a main automáticamente pasa al entorno de producción de cualquiera de mis proyectos, lo ideal es tener aquí una pequeña barrera donde tú puedas revisar lo que hay. Y el último paso, que es lo del Gateway que he comentado, es tener estas credenciales fuera del entorno de desarrollo. Al final la clave es conseguir un equilibrio entre seguridad y comodidad, porque si te pasas eh con la parte de seguridad, se hace supertedioso trabajar y al final no mola. Otro punto a tratar interesante es que eh podemos no tener ninguna credencial en los punto em, por ejemplo, hay servicios que podemos moquearlos con algún servicio de prueba, por ejemplo, en SMTP podemos tener Mailpit que simula el servidor de correo y así un montón de ejemplos. En cambio, hay otros que no podemos simular, como podría ser eh la inferencia con Open AI, si queremos tener un agente y estar haciendo pruebas. Entonces, todas estas API keys la podemos inyectar de forma dinámica, por ejemplo, con un Engine X, que es lo que quiero que experimentar la semana que viene. Otra nota que he dejado aquí es que si utilizas agentes autónomos, es bueno limitar o el acceso a las credenciales o datos personales, que es lo que estamos viendo en este vídeo. Eh si tenemos un agente conversacional, eh podríamos limitar la salida de red de ese agente, es decir, que la gente no se pueda conectar a cualquier dominio, solo a algunos de confianza. En cualquier caso, según el sistema que estés diseñando, será importante limitar unos u otros. Esto es algo que podemos tratar en profundidad en otro vídeo. En este caso, me estoy centrando en la parte de credenciales. Y como puedes ver, todo esto al final nos lleva a tener un agente que es autónomo en una máquina virtual, por lo que podríamos acabar conectando todas las tareas que tenemos en nuestro gestor de tareas, de forma que el agente sea capaz de generar un spec que nosotros podemos revisar o no, según la complejidad o la madurez del proyecto. El agente lo ejecuta, es capaz de realizar todo tipo de pruebas y verificaciones de forma autónoma y finalmente crearte un pull request, que obviamente, como hemos visto, el agente no debe poder mezclarlo automáticamente a main, hay alguien que debe revisarlo. Todo esto puede ser un sistema que tengamos muy refinado y, por ejemplo, si son cambios muy sencillos, el proceso será de validación puede ser mucho más laxo que si, por ejemplo, es un cambio crítico que involucra seguridad. Ya te digo, aquí solamente quería dejar la idea de lo que es un software factory, que es todo lo todos los procesos que hay alrededor de un agente o de un harness, y que también podemos ver si te interesa en otro vídeo. Si quieres experimentar con esto, lo que te recomiendo es que te crees un skill que se llame factory, en el que definas todas estas fases y evoluciones tu agente para que eh te crees te genere un spec, lo divida en tareas, lance sus agentes para que lo implemente y finalmente lanza otros subagentes que puedes tener varios, por ejemplo, uno que te haga un code review, otro que haga una revisión de seguridad y por supuesto una verificación formal del proyecto. En cualquier caso, en los siguientes vídeos me gustaría enseñarte el gateway que ya está las credenciales, cómo tengo estructurado mi home lab donde utilizo Proxmox, Tailscale, GitHub para la gestión de tareas. Podemos conectar GitHub con el DevLab y tener esta software factory y por supuesto podemos hacer alguna sesión de desarrollo en vivo. Así que cualquier sugerencia déjalo en los comentarios, recuerda darle like, suscribirte y nos vemos en el siguiente vídeo. Un saludo.
Assistir ao vídeo original no YouTube
Assuntos: Agentes de IA. Publicado no YouTube em 2026-10-18.
Seleção automática por assunto e idioma. O vídeo pertence ao canal de origem.
Sobre Lima, Herdr y Tailscale
La descripción del video enumera tres herramientas usadas para trabajar con agentes de IA dentro de un entorno aislado (sandbox). Lima es un proyecto de código abierto que crea máquinas virtuales Linux con uso compartido automático de archivos y redirección de puertos, de forma parecida a WSL2, con enfoque en la ejecución de contenedores; su repositorio usa la licencia Apache 2.0 y el proyecto está en incubación en la CNCF (Cloud Native Computing Foundation).
Herdr se presenta en su sitio oficial como un entorno de ejecución para agentes de programación: cada agente funciona en su propio terminal, sigue trabajando cuando el usuario se aleja y puede retomarse desde otra máquina; está disponible para macOS, Linux y Windows con licencia Apache 2.0. Tailscale es un software de VPN en malla (mesh) de código abierto basado en WireGuard, desarrollado por Tailscale Inc. y distribuido con licencia BSD de 3 cláusulas, según Wikidata.
Ficha técnica
- Lima: Máquinas virtuales Linux con enfoque en contenedores; licencia Apache 2.0; proyecto en incubación en la CNCF
- Herdr: Entorno de ejecución para agentes de programación en terminal; macOS, Linux y Windows; licencia Apache 2.0
- Tailscale: VPN en malla basada en WireGuard; desarrollador Tailscale Inc.; licencia BSD de 3 cláusulas
- Sitio de Lima: lima-vm.io
- Sitio de Herdr: herdr.dev
- Sitio de Tailscale: tailscale.com
Lee también
- Agentes de IA: ¿Se puede confiar en ellos?
- Agentes de IA con Terminal 🚀 Cómo usar Gemma 4 y Qwen para Coding
- Agentes de IA fuera de control: ¿alarmismo o amenaza? | A fondo DW
Fuentes y referencias: repositorio de Lima en GitHub · sitio oficial de Lima · sitio oficial de Herdr · Wikidata – Tailscale (Q141088012) · descripción del video del canal pirobits en YouTube.