La seguridad de los agentes de IA empieza con software pequeño

Matt Sephton publicó Fits on a Floppy en abril de 2026 con una restricción deliberadamente absurda: el software útil debería intentar caber en 1,44 MB, la capacidad de un disquete estándar de 3,5 pulgadas.¹

El límite de tamaño importa menos que la postura que hay detrás. Sephton defiende descargas rápidas, inicio instantáneo, bajo uso de memoria y CPU, código nativo, compatibilidad con sistemas antiguos y herramientas que hagan bien una sola cosa.¹ La lectura obvia es que el software pequeño respeta al usuario. La lectura de la era de los agentes va más allá: el software pequeño les da a los agentes de programación con IA menos lugares donde ocultar errores.

La seguridad de los agentes de IA empieza con software pequeño porque los sistemas pequeños e inspeccionables reducen el espacio que un agente puede malinterpretar, modificar, autorizar y dejar sin probar. Los entornos aislados y las solicitudes de permiso siguen siendo importantes. El software pequeño mueve el límite de seguridad hacia una etapa anterior, a la forma del artefacto mismo.

Resumen rápido

Los agentes de programación funcionan mejor cuando pueden leer los archivos relevantes, ejecutar las comprobaciones relevantes y explicar el diff relevante antes de que el contexto se degrade. La guía de Claude Code de Anthropic dice que el contexto se llena rápido y que el rendimiento se degrada a medida que se llena; la misma guía llama a la verificación la práctica más valiosa y describe las herramientas CLI como interfaces eficientes en uso de contexto.² La documentación de shell local de OpenAI advierte que los agentes que ejecutan comandos de shell necesitan entornos aislados o listas estrictas de permisos y bloqueos antes de la ejecución.³

El software pequeño no reemplaza esos controles. Hace que sean más fáciles de aplicar. Una herramienta pequeña tiene menos comandos que autorizar, menos archivos que inspeccionar, menos dependencias en las que confiar, menos pruebas que ejecutar y menos ramas donde pueda esconderse una suposición incorrecta. La vieja lección de Unix no quedó obsoleta: McIlroy rastreó la idea de “hacer una sola cosa” hasta las primeras restricciones de tamaño, y luego explicó por qué los flujos de texto se convirtieron en interfaces universales útiles tanto para programas como para personas.⁴ Los sistemas de agentes redescubren el mismo patrón porque los agentes necesitan superficies inspeccionables y componibles.

Ideas clave

Para quienes construyen agentes: - Prefiere herramientas pequeñas con entradas explícitas, salidas explícitas y artefactos en archivos simples antes de agregar API amplias o esquemas de herramientas grandes. - Trata las rutas de archivos, los diffs, los logs y las pruebas como superficies de seguridad. El agente puede inspeccionarlas, el revisor puede inspeccionarlas y la automatización puede usarlas como umbral de aprobación.

Para equipos de software: - El software pequeño reduce el costo de revisión. Un revisor puede entender una herramienta de 400 líneas y sus pruebas en una sola sesión; un framework desbordado obliga a confiar donde debería haber evidencia. - Mantén el alcance de los permisos cerca de la acción. Un comando pequeño puede ejecutarse en modo de solo lectura, escribir en una sola carpeta o bloquear el acceso a la red. Un comando general suele pedir más autoridad de la que la tarea necesita.

Para líderes de producto: - El software pequeño no es nostalgia. Es un patrón de gobernanza para un mundo donde las máquinas pueden producir demasiado código demasiado rápido. - El estándar debería pasar de “¿puede construirlo el agente?” a “¿puede el equipo verificarlo, asumir su propiedad y revertirlo?”.

Por qué el software pequeño volvió a ser relevante

La hinchazón del software solía verse como un problema de experiencia de usuario: descargas lentas, uso pesado de memoria, inicio demorado, baterías agotadas y dispositivos antiguos abandonados. Fits on a Floppy vuelve visible esa crítica mediante un estándar físico intencional. Una insignia de 1,44 MB convierte la moderación en una prueba que el usuario puede entender.¹

Los agentes de programación con IA cambian la razón por la que la moderación importa. La máquina puede producir archivos más rápido de lo que una persona puede leerlos. Esa velocidad debilita la calidad cuando el sistema que la rodea acepta el volumen como señal de progreso. Una función de 2.000 líneas con cuatro dependencias nuevas puede verse impresionante en la transcripción y aun así ampliar la superficie de defectos más de lo que aumenta el valor del producto.

El software pequeño le da al agente un objetivo más difícil y al revisor uno mejor. La consigna puede pedir un ejecutable, un formato de datos, un archivo de prueba y una ruta de reversión. El resultado deja menos grados de libertad. Un modelo todavía puede equivocarse, pero el error tiene menos espacio para camuflarse.

Niklaus Wirth publicó un artículo llamado A Plea for Lean Software en 1995, mucho antes de que los agentes de programación entraran en el flujo de trabajo.⁵ El título sigue teniendo fuerza porque la falla de fondo persiste: los equipos gastan hardware, dependencias y capas de abstracción para evitar tomar decisiones de diseño difíciles. Los agentes reducen el costo de agregar código, así que negarse a agregar código se vuelve más valioso.

El contexto es un presupuesto de seguridad

La seguridad de los agentes suele plantearse como un problema de permisos: qué comandos puede ejecutar el agente, qué archivos puede editar, qué secretos puede ver, qué llamadas de red puede hacer. Esas preguntas importan. Pero no cubren la primera restricción que encuentra el agente mientras trabaja: el contexto.

La guía de buenas prácticas de Claude Code de Anthropic dice que la ventana de contexto contiene la conversación, los mensajes, los archivos leídos y la salida de comandos, y que una sola sesión de depuración puede consumir decenas de miles de tokens.² La guía también advierte que Claude puede empezar a olvidar instrucciones anteriores o cometer más errores a medida que se llena la ventana de contexto.²

Esa advertencia convierte el tamaño en una propiedad de seguridad. Una base de código pequeña permite que el agente lea la superficie relevante sin ahogar la sesión en archivos irrelevantes. Una herramienta pequeña permite que el agente mantenga a la vista la función, las pruebas, el modelo de permisos y los casos límite al mismo tiempo. Un diff pequeño permite que el revisor encuentre el cambio real en lugar de revisar una pila de movimiento generado.

El presupuesto de contexto tiene tres límites prácticos:

Los sistemas grandes también pueden ser seguros. Necesitan una descomposición más fuerte. Si una base de código no puede ser pequeña, la superficie expuesta al agente sí debería serlo: un paquete, un subsistema delimitado, un comando público, un objetivo de prueba, una carpeta con responsable claro.

Los archivos simples superan al estado oculto

La historia oral de McIlroy le da a la vieja lección un filo práctico. Describió “hacer una sola cosa” como un principio nacido de no tener espacio para hacer más de una, y luego dijo que los equipos conservaron el patrón incluso después de que la restricción original desapareció.⁴ También explicó por qué importaban los flujos de texto: los datos legibles por humanos hacían que depurar fuera menos tedioso, y hacer evolucionar campos de texto requería menos trabajo que cambiar estructuras binarias fijas.⁴

Los agentes necesitan el mismo tipo de superficies. Un archivo se puede listar, buscar, comparar, leer por rangos, confirmar en Git, revertir, analizar con linters y revisar. El estado oculto del IDE, las bases de datos locales opacas y las herramientas alojadas demasiado amplias pueden ser útiles, pero obligan al agente y al revisor a confiar en una superficie que no pueden inspeccionar con facilidad.

Un artículo de arXiv de enero de 2026 conecta la abstracción de archivos de Unix con los sistemas de IA agéntica. El artículo sostiene que las abstracciones tipo archivo y las especificaciones basadas en código condensan recursos diversos en interfaces consistentes y componibles, y que pueden ayudar a que los sistemas de agentes sean más mantenibles, auditables y sólidos en operación.⁶ El análisis de memoria de agentes de Oracle hace una distinción relacionada: las interfaces de sistema de archivos funcionan bien porque los modelos ya entienden superficies propias del desarrollo, como repositorios, carpetas, Markdown, logs e interacciones CLI, mientras que el almacenamiento duradero puede seguir perteneciendo a una base de datos.⁷

La distinción importa. “Usa archivos” no significa “guarda todo en texto suelto para siempre”. El patrón más seguro separa la interfaz del agente del sustrato de almacenamiento:

El agente debería ver la interfaz útil más pequeña. El producto puede conservar debajo una capa de almacenamiento más fuerte.

Menos herramientas significan menos permisos

El artículo de autorización de MCP dejó explícita la lección: validar un token de portador no prueba que un usuario pueda llamar a todas las herramientas detrás del servidor.⁸ El software pequeño aplica la misma idea antes, en el diseño. Una herramienta más pequeña pide una autoridad más limitada.

La documentación de shell local de OpenAI expresa el peligro con claridad: ejecutar comandos de shell arbitrarios puede ser riesgoso, y quienes construyen estos sistemas deberían usar entornos aislados o agregar listas estrictas de permisos y bloqueos antes de enviar comandos al shell del sistema.³ La guía de Claude Code de Anthropic da un ejemplo práctico a escala: al distribuir trabajo entre archivos, usa restricciones de herramientas permitidas para que las ejecuciones desatendidas no puedan hacer más de lo que requiere la tarea.²

Un comando pequeño es más fácil de restringir:

Las herramientas amplias tienden a acumular permisos amplios. Un comando general de “publicar” puede tocar contenido, traducciones, filas de base de datos, purga de caché, logs de despliegue y analítica. A veces el comando de lanzamiento tiene sentido. El patrón más seguro construye el lanzamiento a partir de comandos más pequeños con umbrales explícitos entre ellos, y automatiza la secuencia solo después de que cada paso tenga evidencia.

El objetivo no es hacer el trabajo más lento. El objetivo es volver visible la autoridad.

Las pruebas deberían ajustarse a la herramienta

La primera sección de buenas prácticas de Anthropic les dice a los usuarios que le den a Claude una forma de verificar su trabajo: pruebas, capturas de pantalla, salidas esperadas y comprobaciones de comandos.² El software pequeño vuelve concreto ese consejo. Una herramienta pequeña puede llevar un contrato de verificación pequeño.

Para software construido por agentes, el contrato debería caber en una pantalla:

Entradas:
- una ruta de origen
- una ruta de salida
- una opción opcional

Efectos permitidos:
- leer la ruta de origen
- escribir la ruta de salida
- sin red salvo que esté presente --verify-sources

Evidencia:
- pruebas unitarias para el análisis
- prueba con fixture para la salida
- salida de dry-run para el archivo exacto
- git diff limitado a rutas con responsable claro

El contrato importa porque los agentes pueden satisfacer pedidos vagos con demasiada facilidad. “Mejora el pipeline” invita a mover arquitectura sin necesidad. “Agrega una opción de dry-run a este comando y demuestra que la salida no escribe archivos” crea una ruta de evidencia.

Las pruebas también se vuelven más rápidas cuando las herramientas se mantienen pequeñas. Las pruebas rápidas cambian el comportamiento del agente. El agente las ejecuta con más frecuencia, ve fallas mientras el código relevante todavía está en contexto y corrige causas raíz antes de que la transcripción se desvíe. Las pruebas lentas empujan al modelo a adivinar o a narrar lo que habría ejecutado.

Pequeño no significa incompleto

El software pequeño puede fallar de maneras predecibles:

La insignia del disquete mide tamaño. La seguridad de los agentes necesita otra medida: ¿puede un revisor entender el comportamiento, el alcance de permisos y la ruta de evidencia antes de aprobar el cambio?

Esa pregunta permite que una herramienta supere 1,44 MB. Lo que rechaza es la parte que importa: el alcance accidental. Una app nativa segura y aburrida de 20 MB puede superar a un script de 200 KB que delega en un instalador no revisado. El software pequeño sirve a la seguridad solo cuando la moderación llega a la ruta de ejecución real.

Una lista de evaluación de pequeñez para trabajo con agentes

Antes de que un agente construya o modifique una herramienta, evalúa el trabajo en cinco dimensiones. La idea no es castigar los sistemas grandes. La idea es encontrar las superficies que necesitan descomposición antes de que el agente empiece a escribir.

Una celda roja no significa que el trabajo deba detenerse. Significa que el agente necesita una unidad de trabajo más pequeña. La seguridad mejora cuando la forma de la tarea facilita demostrar el comportamiento correcto.

El patrón práctico

Los sistemas construidos por agentes en los que más confío comparten una forma:

1. Un comando acotado hace una sola tarea.
2. Archivos simples llevan entradas, salidas, logs, planes y paquetes de revisión.
3. Los permisos se corresponden con los efectos reales del comando.
4. Las pruebas corren lo bastante rápido como para que el agente las use durante la sesión.
5. El diff se mantiene lo bastante pequeño como para que una persona lo revise.
6. La ruta de lanzamiento compone comandos pequeños en lugar de ocultar autoridad amplia detrás de un botón.

El manifiesto No-Build describió la misma preferencia desde el lado del stack web: menos capas de build, menos artefactos generados y menos distancia entre el código fuente y el entorno de ejecución.⁹ La versión centrada en seguridad de agentes dice lo mismo pensando en otro lector. Cada capa adicional le da a la máquina otro lugar para producir trabajo plausible que la persona no puede verificar rápido.

El software pequeño convierte la moderación en infraestructura. Un módulo más acotado mejora el ajuste al contexto. Un archivo más simple mejora la auditabilidad. Una prueba más rápida mejora la retroalimentación. Un conjunto de permisos más pequeño mejora el control del radio de impacto. Un diff más pequeño mejora el juicio humano.

FAQ: software pequeño y seguridad de agentes

¿El software pequeño vuelve seguros a los agentes de programación con IA?

No. El software pequeño reduce el área que los agentes pueden malinterpretar o dañar. Los equipos siguen necesitando entornos aislados, listas de permisos y bloqueos, pruebas, revisión de código, límites de credenciales y umbrales de lanzamiento. El software pequeño hace que esos controles sean más fáciles de aplicar y más difíciles de eludir por accidente.

¿Qué tan pequeña debería ser una herramienta expuesta a agentes?

El límite útil es la facilidad de revisión, no la cantidad de bytes. Una buena herramienta expuesta a agentes tiene una sola tarea, un contrato pequeño de entrada y salida, un perfil claro de permisos, pruebas rápidas y un diff que un revisor puede entender en una sola sesión.

¿La memoria de agentes debería usar archivos o una base de datos?

Usa archivos para la interfaz cuando el agente necesite inspeccionar, buscar, comparar y escribir artefactos. Usa una base de datos cuando el producto necesite concurrencia, indexación, control de acceso, durabilidad o estado entre usuarios. La arquitectura más segura separa la interfaz expuesta al agente del sustrato de almacenamiento.⁷

¿Dónde encaja MCP?

MCP encaja cuando el agente necesita un puente tipado hacia herramientas o datos externos. MCP no elimina la necesidad de comandos pequeños, permisos acotados y autorización a nivel de acción. El servidor todavía tiene que decidir si el sujeto específico puede ejecutar la acción específica.⁸

Cierre

La IA vuelve barato el código. El código barato aumenta el valor de la negativa.

El software pequeño le da a la negativa una forma que la máquina puede obedecer: un comando, una salida, un límite de permisos, una ruta de prueba, un diff. La forma no garantiza calidad. Sí hace más visible el trabajo débil.

El disquete ya no es la restricción. La inspeccionabilidad sí.

Referencias