Agentes: instrucciones, permisos y dependencias
Dale a un agente de programación instrucciones permanentes, el acceso mínimo que le permita hacer el trabajo y una revisión de dependencias que no pueda esquivar con argumentos.
AL TERMINAR, PODRÁS
- Escribir y mantener un archivo de instrucciones del repositorio que lean los agentes
- Ajustar las herramientas, los permisos y el aislamiento de un agente a la tarea y a sus consecuencias
- Revisar una dependencia sugerida antes de instalarla, incluidos los nombres que un modelo inventó
Descripción del diagrama: AGENTS.md → Agente en un sandbox (lee); Agente en un sandbox → Repositorio + pruebas (ejecuta); Agente en un sandbox → Aprobación humana; Aprobación humana → Producción; Agente en un sandbox → Índice de paquetes (sugiere)
Instrucciones permanentes en el repositorio
Los agentes de programación leen archivos de instrucciones guardados en el repositorio.
AGENTS.md es un formato abierto para ellos, y algunas herramientas usan sus propios nombres de archivo para la misma idea. Contiene lo que un agente necesita y que un README escondería: cómo compilar y ejecutar las comprobaciones, las convenciones que hay que seguir, lo que no se debe tocar y las notas de seguridad. En un repositorio con varios de estos archivos, gana el más cercano al archivo que se edita, y una petición explícita en la conversación se impone a todos.
Mantén el archivo corto, cierto y al día: cámbialo en el mismo commit que el código que describe y borra las reglas que ya no valen, porque una instrucción vieja se sigue con la misma fidelidad que una correcta. Nunca pongas secretos en él. Sobre todo, recuerda qué es: contexto que el agente suele seguir, no un candado.
Una inyección de prompts o un plan equivocado pueden ignorarlo, así que todo límite que importe debe hacerse cumplir también en un lugar que el agente no pueda editar.
Dale al agente el acceso mínimo que le permita trabajar
Un agente con una terminal y acceso a la red puede hacer todo lo que puede hacer la cuenta con la que corre.
OWASP llama a este riesgo agencia excesiva (excessive agency) y le atribuye tres causas: demasiada funcionalidad, demasiados permisos y demasiada autonomía. Responde a cada una. Ofrece herramientas acotadas en lugar de abiertas: un comando que ejecuta las pruebas en lugar de una terminal general, descargas desde una lista corta de sitios en lugar de cualquier URL.
Dale los permisos mínimos: un token de solo lectura, una base de datos de prueba, ninguna credencial de producción. Exige que una persona apruebe las acciones difíciles de deshacer o que llegan a otras personas, como hacer push, desplegar, borrar o enviar mensajes. Haz cumplir la autorización en los sistemas a los que llama el agente, nunca confiando en que el modelo se porte bien.
Luego aísla la ejecución en un contenedor, una máquina virtual o una copia de trabajo aparte, con la red restringida, para que un error o una instrucción inyectada se queden adentro. Los logs y los límites de frecuencia no evitan el daño, pero lo acotan y muestran qué pasó.
Revisa cada dependencia que sugiera un agente
Los modelos a veces recomiendan paquetes que no existen.
Un estudio presentado en USENIX Security 2025 generó 576.000 muestras de código con 16 modelos: en promedio, no existían al menos el 5,2 % de los paquetes que sugirieron los modelos comerciales y el 21,7 % de los que sugirieron los modelos abiertos, 205.474 nombres inventados distintos en total. Muchos vuelven: el 43 % de los nombres inventados reapareció en las diez repeticiones de la misma petición. Esa repetición es justo lo que necesita un atacante, porque puede registrar con código malicioso un nombre que los modelos siguen inventando y simplemente esperar.
A esto a veces se le llama slopsquatting, pariente del typosquatting, en el que el nombre está a un error de tipeo de un paquete popular. Antes de instalar, confirma que el paquete existe en el índice oficial y que es el proyecto que buscabas, mejor siguiendo un enlace desde la documentación del propio proyecto. Mira su antigüedad, su historial de versiones y su repositorio.
Desconfía de un nombre a una letra de uno conocido. Fija las versiones en un archivo de bloqueo (lock file) con hashes, para que un cambio posterior no se cuele.
import json, urllib.error, urllib.request
def index_facts(name):
request = urllib.request.Request(
f"https://pypi.org/simple/{name}/",
headers={"Accept": "application/vnd.pypi.simple.v1+json"})
try:
with urllib.request.urlopen(request, timeout=10) as response:
data = json.load(response)
except urllib.error.HTTPError as error:
if error.code == 404:
return None # no such package: do not install a guess
raise
uploads = [f["upload-time"] for f in data["files"] if f.get("upload-time")]
return {"versions": len(data["versions"]), "first_upload": min(uploads, default=None)}ERROR FRECUENTE
Tratar el archivo de instrucciones como una frontera de seguridad. Es un consejo que el agente suele seguir; los límites que importan van en permisos, aislamiento y comprobaciones que el agente no puede cambiar.
INTÉNTALO TÚ
Escribe un AGENTS.md para Relay de 30 líneas como máximo. Luego enumera lo que necesita un agente que arregla una prueba que falla (archivos, comandos, red) y lo que no debe tener, y di cómo se hace cumplir cada límite fuera del archivo de instrucciones.
Decide en el laboratorio.
El checkpoint de dos preguntas, tus notas y tu progreso guardado están en el laboratorio. Gratis y sin cuenta.
Abrir en el laboratorio ↗CONÉCTALO CON RELAY
Agrega a Relay un AGENTS.md con sus comandos de compilación y de pruebas y sus notas de seguridad. Ejecuta tu agente en una copia de trabajo aparte, con una base de datos de prueba y sin credenciales de producción, exige aprobación para los push y revisa cada dependencia nueva en el índice antes de agregarla al archivo de bloqueo.