Antes de Darle las Llaves a un Agente

Cuando nuestros equipos conversan con líderes tecnológicos, pocos han explorado a fondo el potencial, y menos aún han reflexionado sobre el equilibrio que lo acompaña. Nosotros dos abordamos esto desde extremos opuestos: uno apoya a los equipos que construyen los sistemas agénticos que realizan el trabajo; el otro es responsable de los estándares, el cumplimiento normativo y los controles dentro de los cuales esos sistemas deben operar. Y seguimos llegando al mismo punto.

El instinto habitual es buscar una solución: bloquear esto, desactivar aquello, y ya podemos escalar con seguridad. Lo entendemos, pero eso genera una expectativa equivocada. No es posible resolver estos riesgos a base de restricciones, porque lo que los genera es lo mismo que genera el valor. Un agente es útil precisamente porque puede actuar, y todo lo que puede actuar puede actuar de forma incorrecta.

Esto no es una lista de verificación con un estado final definido, sino un equilibrio. Cada barrera que añades consume un poco de la autonomía del agente para ganar seguridad. Cada bit de autonomía que otorgas consume un poco de seguridad para ganar velocidad. El trabajo consiste en decidir, de manera consciente, en qué punto de esa línea quieres situarte, y la respuesta es diferente para un agente de formateo de código que para uno con acceso a despliegues.

Sin embargo, la compensación no es difusa. Se concentra en seis puntos. Comprende el modo de fallo detrás de cada uno y la mitigación que mueve el equilibrio, y podrás otorgar autonomía donde es poco costosa y restringirla donde el radio de impacto es grande, en lugar de tratar a cada agente como igualmente confiable o igualmente limitado. Aquí están los seis, con lo que puede salir mal, lo que lo mitiga y lo que esa mitigación te cuesta.

Ayuda imaginarse un único dial detrás de los seis riesgos. Girarlo hacia la agencia hace que el agente actúe más por su cuenta, más rápido y con menos intervención humana. Girarlo hacia la seguridad añade aislamiento, límites de alcance y puntos de control que lo ralentizan y restringen lo que puede hacer. No existe una configuración que ofrezca ambos extremos a la vez. Lo que sí se puede hacer es ajustar el dial por separado para cada riesgo y cada agente, de modo que la autonomía otorgada sea proporcional al daño que podría causar. Las secciones siguientes son seis versiones de esa misma decisión.

Un agente que posee credenciales puede hacer todo lo que esas credenciales permiten, y un agente comprometido o manipulado mediante inyección de instrucciones lo hará. Esto va más allá de un secreto filtrado. Incluso cuando nunca se filtra nada, la autoridad de la credencial está en uso durante todo el tiempo que el agente opera, basándose en el criterio del agente y no en el tuyo.

La solución es mantener las credenciales fuera del alcance del agente. Ejecútalo en un entorno sin secretos almacenados en él, como una VM aislada o un sandbox de contenedor, e inyecta lo que necesita en tiempo de ejecución a través de un proxy con terminación TLS, de modo que utilice un secreto sin retenerlo. Mantén cada token con un alcance limitado, de corta duración y con rotación periódica, aplicado mediante las herramientas y no en un documento de políticas. En la práctica, esto es difícil de implementar de forma perfecta, así que aplica niveles como lo harías con una persona: cuanto más susceptible sea un agente a la influencia de entradas externas, o cuanto más cerca esté de producción, más debes restringir sus credenciales. La mayor parte del trabajo con agentes ocurre hoy en entornos secundarios, lo que mantiene este costo en niveles manejables.

La autonomía a la que renuncias: el agente no puede acceder a sistemas que no hayas autorizado explícitamente en tiempo de ejecución, por lo que algunos flujos de extremo a extremo requerirán que una persona autorice un paso. Esa pausa generalmente vale la pena.

Por lo general, puedes controlar hacia dónde va el tráfico de un agente. Rara vez controlas lo que hay dentro de él. El contenido no confiable que entra es el canal de inyección de prompts: un archivo, issue o página web envenenada que reescribe lo que el agente cree que se le pidió hacer. Los datos sensibles que salen constituyen el canal de exfiltración. Por defecto, ninguna dirección es inspeccionada.

Mitiga ambas direcciones. Crea una lista blanca de dominios de salida y bloquea el resto, aplica prevención de pérdida de datos al tráfico saliente para que los secretos y el código fuente no se filtren silenciosamente, y analiza las inyecciones de prompts en el gateway del LLM a la entrada.

La autonomía a la que renuncias: el agente pierde acceso libre a la internet abierta, por lo que una tarea que requiera una nueva fuente deberá tener esa fuente aprobada primero, y la inspección añade cierta latencia y costo. Una lista de permitidos reduce la superficie de ataque en lugar de eliminarla por completo, ya que un dominio aprobado puede verse comprometido. Esa fricción es precisamente la función.

Todo lo que un agente puede hacer es algo que puede hacer mal. Eso incluye herramientas directas, como un servidor que utiliza el Protocolo de Contexto de Modelo (MCP, una forma común de que los agentes invoquen herramientas y sistemas) o una API, e indirectas, como un push de código que activa un trabajo de CI, un webhook o un despliegue. La superficie indirecta es la que los equipos suelen olvidar: un agente no necesita permisos de despliegue si puede editar el archivo de flujo de trabajo que realiza el despliegue.

Establece una política explícita para las herramientas directas, que especifique cuáles están permitidas, por qué y qué pueden modificar. Prefiere los servidores MCP proporcionados por el proveedor, o los que escribas tú mismo usando código fuente público como plantilla, antes que servidores de terceros no confiables; estos suelen ser lo suficientemente simples como para no necesitar depender de confianza externa. Luego analiza las acciones indirectas, especialmente la posibilidad de que un agente modifique una definición de pipeline que posteriormente se ejecute con más privilegios de los que tiene el agente, e incorpora análisis estático automatizado para detectarlas antes de que se ejecuten. Gran parte de esto se corresponde con la seguridad de pipelines, una práctica bien definida a nivel empresarial.

La autonomía a la que renuncias: conectar menos herramientas significa que hay más tareas que el agente no puede completar de forma autónoma, por lo que debes otorgar herramientas a medida que se gana confianza, en lugar de hacerlo todo de una vez.

Un agente que se ejecuta directamente en una máquina host puede leer, escribir y ejecutar cualquier cosa que el usuario pueda. El daño tampoco es siempre inmediato. Un git hook instalado o un script postinstall puede permanecer inactivo y ejecutarse más tarde, la próxima vez que alguien toque el repositorio.

Aísla el agente del host con una VM, un entorno sandbox de contenedores como Docker Sandboxes, o una herramienta como Coder, y trata el límite de aislamiento como un punto de control: revisa todo lo que regrese al host antes de que se ejecute, incluyendo .git/hooks, scripts de package.json y Makefiles.

La autonomía a la que renuncias: el agente ya no corre libremente en el host, por lo que el uso de sandbox añade algo de configuración y sobrecarga, y un humano debe inspeccionar todo lo que cruce de vuelta antes de que se ejecute. La velocidad que sacrificas es pequeña comparada con un host en el que ya no tienes que confiar ciegamente.

Cuando muchos agentes producen grandes volúmenes de código, la presión se desplaza hacia la revisión. Con suficiente volumen, los revisores se fatigan y "no revisar realmente" se convierte gradualmente en la norma, que es el riesgo real, porque esa es la última barrera antes de producción. Un agente que revisa su propio resultado no constituye una verificación independiente. El volumen no es hipotético: el análisis de 470 pull requests realizado por CodeRabbit encontró que los cambios con coautoría de IA presentaban aproximadamente 1,7 veces más problemas que los realizados únicamente por humanos.

Sé específico sobre lo que significa revisar, porque con volumen una barrera vaga se convierte en ninguna barrera. Las herramientas deterministas son el piso mínimo —tipos, linters, pruebas— que detectan categorías enteras de errores antes de que un humano los examine. A esto se suman habilidades específicas del sistema que orientan a los agentes hacia patrones idiomáticos, y revisores con contexto del proyecto que cuenten con suficiente conocimiento para revisar de forma crítica en lugar de aprobar sin más. Nunca permitas que el agente que escribió un cambio lo apruebe, y mantén a un humano en la barrera que más importa.

La autonomía a la que renuncias: los agentes no fusionan directamente a producción, por lo que el rendimiento sigue estando limitado por la capacidad de revisión. Ese límite es precisamente el punto, porque la barrera es lo que hace que

Una vez que tu código y tus prompts salen de tu entorno, el proveedor en el otro extremo puede retenerlos o utilizarlos para entrenar sus modelos. Esto coloca la lógica propietaria y los datos de los clientes fuera de tu control, y con frecuencia fuera de tu jurisdicción.

Configura los proveedores de modelos e inferencia para que apliquen retención cero de datos y no utilicen tus entradas para entrenamiento, y refuérzalo mediante procesos que garanticen el uso exclusivo de herramientas y modelos empresariales aprobados, en lugar de permitir que cada persona elija sus propias cuentas bajo presión de plazos. Cuando la residencia de datos sea relevante, da preferencia a la inferencia alojada en tu propia región.

El intercambio: es posible que debas renunciar a la herramienta de consumo más reciente o al endpoint más económico en favor de uno aprobado. Un precio pequeño por mantener el control de tus datos.

Cuatro factores determinan dónde se sitúa el dial: el aislamiento, es decir, qué tan contenido está el agente; la autonomía y el alcance, es decir, los permisos que posee y los puntos de control humano en su camino; la gobernanza, es decir, las puertas de cambio, las aprobaciones y el registro de auditoría que lo rodean; y la observabilidad, es decir, cuánto del comportamiento del agente se puede realmente ver. En los sistemas tradicionales monitoreamos la aplicación; con un agente también monitoreamos sus decisiones, sus llamadas a herramientas, sus escaladas de permisos y su deriva a lo largo del tiempo. La visibilidad suele preceder a la autonomía: la mayoría de los equipos necesita ver lo que hace un agente en un nivel determinado antes de confiarle uno superior.

Antes de otorgar un nivel de autonomía, dimensiona el radio de impacto haciéndote la pregunta directa: si este agente se equivocara o fuera comprometido, ¿cuál sería el peor daño posible y podríamos asumir las consecuencias? Esto se corresponde con la ecuación de riesgo habitual de probabilidad e impacto, con una diferencia deliberada: una vez que se asume que el agente ha sido comprometido o que está equivocado, la probabilidad queda de lado y es el impacto el que mueve el dial. "Probablemente no ocurrirá" no es un control cuando el fallo consiste precisamente en que alguien lo provoca. Un agente de formato puede tener una correa larga. Un agente con acceso a producción recibe una correa corta y un humano en la puerta.

Un control no tiene sustituto técnico: la responsabilidad. Ninguna de las consecuencias habituales recae sobre un agente —su reputación no está en juego, no puede ser despedido (al menos no de una forma que le importe) ni enfrentar consecuencias legales—, por lo que la responsabilidad no puede delegarse en él. Cuando un agente actúa, una persona identificada sigue siendo dueña del resultado, del mismo modo que un proyecto asigna un responsable antes de que comience el trabajo. El verdadero riesgo es que esta delegación ocurra de forma implícita: alguien termina respondiendo por decisiones que tomó un agente sin haber decidido conscientemente asumir esa carga. El sector aún no cuenta con un modelo consolidado para esto, especialmente a medida que los agentes pasan de ejecutar decisiones a participar en ellas. Las herramientas determinan lo que un agente puede hacer; la responsabilidad determina quién responde por lo que hizo.

Ninguno de estos seis se acerca a cero, y vale la pena decirlo en voz alta. Las defensas contra la inyección de instrucciones son imperfectas. La revisión a gran escala es probabilística. Un ataque paciente a la cadena de suministro aún puede ocultarse dentro de una acción indirecta. El objetivo no es obtener un certificado de buena salud. Es el riesgo residual que has identificado, dimensionado y aceptado deliberadamente, con suficiente instrumentación para que realmente puedas detectarlo cuando se vuelva real, y no descubrirlo después de los hechos. La mayoría de estos seis fallarán al ser detectados en lugar de prevenidos, que es exactamente la razón por la que la instrumentación no es opcional.

Toma un flujo de trabajo y llévalo a través de estos seis pasos. Para cada uno, establece el nivel de autonomía de forma deliberada y anota el radio de impacto que estás dispuesto a aceptar. Otorgarás más libertad en algunos lugares de lo que esperabas y menos en otros, lo cual es señal de que estás tomando la decisión tú mismo en lugar de dejar que se tome sola.

Una vez realizado, ese recorrido se convierte en una práctica repetible que puedes estandarizar en distintos proyectos y compartir con clientes. Ese es el trabajo que hacemos con los equipos que se toman en serio los agentes: no hacer desaparecer el riesgo, sino convertir el equilibrio entre autonomía y seguridad en una decisión tomada con intención.