El 7 de julio de 2026, Better Auth anunció que se suma a Vercel. La librería sigue siendo open source, el equipo pasa a Vercel, y el anuncio dice para qué: para invertir más en hacia dónde va la autenticación, "un futuro en el que los agentes actúan en nombre de los usuarios y necesitan un acceso seguro, acotado y revocable" [1].
Es una señal de mercado: la seguridad de agentes de IA ya figura entre las razones por las que un equipo de autenticación se suma a una plataforma. Casi toda la conversación que se arma alrededor (protocolos de agent auth, tokens delegados, scopes, revocación) comparte un supuesto de diseño que me parece equivocado.
El modelo dominante: restricción
El enfoque que se está consolidando trata la seguridad de agentes como un problema de contención. Por defecto, el agente es un sistema capaz y curioso con acceso amplio: ve el CRM, los tickets y la base de clientes, y puede llamar herramientas. Alrededor se levantan cercos: tokens con scope, permisos delegados, listas de herramientas permitidas, instrucciones en el prompt ("no reveles X", "no accedas a Y") y capas de moderación sobre la salida.
Es el modelo mental que heredamos de la seguridad de usuarios humanos, y ahí funciona bastante bien: una persona con credenciales limitadas no puede abrir lo que no tiene permiso para abrir.
Con agentes de lenguaje, ese modelo se rompe en un punto preciso: el contexto. Un empleado abre un archivo en el momento en que lo necesita; a un LLM la información se le inyecta en el contexto antes de que razone, y desde ahí forma parte de su mundo. Todo lo que está en el contexto puede aparecer en la salida: por error, porque alguien lo indujo, por prompt injection o porque al modelo le pareció relevante.
De ahí sale la única garantía dura que existe hoy sobre lo que sabe un agente:
Un agente no puede filtrar, usar mal ni razonar sobre información que nunca entró en su contexto.
Todo lo demás (instrucciones, guardrails, filtros de salida) es mitigación probabilística, útil y necesaria en los bordes. Ante una auditoría seria, "el agente tiene instrucciones de no mirar" no alcanza.
La inversión: el contexto se construye desde el permiso
Esa garantía pide invertir la arquitectura. En vez de un agente que ve todo y al que después se le ponen límites, el orden es otro.
Primero la política, después el agente. El modelo de permisos va antes que el agente: define qué información puede entrar en su contexto y qué herramientas puede invocar, para este usuario, en este rol y en esta operación, y el agente arranca dentro de ese perímetro.
Así no hace falta ocultarle nada al agente: lo que está fuera de la política no existe en su mundo. Llamémoslo seguridad por inexistencia, en contraste con la seguridad por restricción.
La idea no es sólo mía, ni la publiqué primero. Venkat Peri, que trabaja en infraestructura de IA agéntica para gestión patrimonial en Advisor360°, llegó a ella desde la autorización en Designing Authorization for Production AI Agents: The Decision Gateway Pattern, en enero de 2026: el agente arranca con un capability envelope que se calcula antes de que planifique, y "las herramientas no autorizadas directamente no existen en su mundo" [2]. En Beyond Lineage, Peri lleva el principio a los datos, con una advertencia que esta tesis necesita: sacar un dato del contexto en silencio no alcanza, porque el modelo no distingue un campo suprimido de uno que no estaba en la fuente, y "null es una invitación a rellenar" [3]. Lo que tiene que faltar es el contenido, y el hueco tiene que quedar a la vista: el agente tiene que saber que ahí hay algo que no puede ver, o lo va a inventar.
En Zarel, hoy, la inexistencia llega hasta acá. Las acciones que el contrato no le concede al rol no existen para el modelo: no están en el menú de acciones de cada turno (las herramientas de servidores MCP externos incluidas) ni en el catálogo de herramientas MCP de ese usuario, y los registros fuera de su alcance de lectura no se devuelven. Hay tres cosas que no llegan tan lejos. Las entidades que el rol no puede leer siguen en el prompt, marcadas sin acceso (el hueco a la vista que pide Peri). Si el modelo nombra igual una acción que no le mostraron, lo que la frena es un rechazo: una escritura no otorgada, la llamada a una herramienta externa no otorgada y una acción que el contrato no declara se rechazan en la barrera, que registra el veredicto; una lectura no otorgada se rechaza sin ese registro. Y un registro legible llega entero, porque los campos todavía no se recortan por rol al leer. Tampoco se guarda todavía con qué menú se armó cada turno.
La diferencia práctica entre los dos modelos aparece en tres lugares.
Dónde se hace cumplir. En el modelo de restricción, la barrera vive, al menos en parte, en el prompt y en filtros posteriores, capas que un atacante puede erosionar con lenguaje. En el de inexistencia, vive en la capa que recupera datos y resuelve herramientas: código determinista, anterior al modelo, al que la persuasión no llega.
Auditabilidad. Ante la pregunta "¿qué pudo haber visto el agente en esta conversación?", el modelo de restricción responde con probabilidades. El de inexistencia puede responder con un registro, siempre que guarde con qué se construyó cada contexto: esta versión de esta política, estas fuentes, estas herramientas. La superficie de riesgo del agente queda en su pipeline de construcción de contexto, más lo que las herramientas que ese pipeline le dio pueden hacer con los valores que elige el modelo, y todo eso se puede inspeccionar, versionar y reproducir.
Revocación. En el modelo de restricción, revocar es invalidar un token que el agente quizás ya usó para leer algo. En el de inexistencia, cambia la política, y el mundo del agente cambia con ella la próxima vez que se construye el contexto.
Más allá de la seguridad
La misma tesis tiene una segunda lectura, organizacional.
Cuando un asistente de soporte responde mal (promete un reembolso que no corresponde, revela datos de otro cliente, inventa una política de devoluciones), el diagnóstico habitual es "el modelo alucinó". Yo lo leo de otra manera: en muchos de esos casos, la organización nunca escribió la política que el agente necesitaba, y el agente improvisó porque no tenía nada formal que ejecutar.
La seguridad por inexistencia obliga a resolverlo, porque el perímetro del agente es un documento: la política de la organización, explícita y versionada, sobre qué puede saber y hacer cada rol en cada operación. Escribirla da trabajo, pero es un trabajo que la organización debía desde hace años y que hasta ahora vivía repartido entre cabezas, wikis desactualizadas y costumbre.
El mismo artefacto que hace seguro al agente lo hace correcto respecto de lo que la organización permite. Lo que no resuelve es la exactitud de lo que dice el modelo: un agente autorizado y conforme en cada paso todavía puede afirmar un dato que no está en su contexto.
Dónde sí hacen falta identidad y delegación
Nada de esto vuelve innecesario el trabajo que la industria está haciendo en identidad y delegación. En las fronteras entre sistemas (un agente tuyo que llama a una API de terceros, un agente ajeno que entra en tu sistema) hacen falta credenciales, scopes y revocación interoperables, y ahí los protocolos de agent auth que se están armando son la pieza correcta. Los dos enfoques se complementan: identidad y delegación entre sistemas, contexto construido desde la política dentro de cada uno.
Mi objeción es al orden de prioridades. Si adentro del sistema hay un agente que ve todo y tiene instrucciones de portarse bien, un protocolo de frontera no cambia lo que ese agente puede filtrar. La capa de adentro es una decisión de arquitectura que se toma antes de construir, y no se puede tercerizar ni agregar después.
La tesis, en forma refutable
La afirmación concreta, y refutable, es esta:
Ante el mismo volumen de intentos adversariales, un sistema agéntico cuyo contexto y herramientas se construyen desde una política explícita y versionada va a tener una tasa de incidentes (filtración, acción fuera de mandato, respuesta contraria a la política) estructuralmente menor que un sistema equivalente protegido por instrucciones y filtros, y esa tasa se va a poder auditar con exactitud.
Es una predicción medible, y todavía no la medí: para eso hacen falta agentes en producción frente a clientes. Estoy construyendo sobre ella. Si tenés agentes en producción frente a clientes y contraejemplos, o el mismo problema visto desde otro ángulo, me interesa conversarlo.
La versión de este argumento para las acciones está en Persuasión versus gobernanza.
Las citas están traducidas por el autor. Los originales, en inglés:
- Better Auth, Better Auth is joining Vercel: "a future where agents act on users’ behalf and need secure, scoped, and revocable access".
- Peri, Designing Authorization for Production AI Agents: The Decision Gateway Pattern: "Unauthorized tools simply don’t exist in its world."
- Peri, Beyond Lineage: A Field-Level Trust Contract for AI Data Consumers: "null is an invitation to fill".
Nicolás Moreno construye Zarel: operaciones de IA gobernadas, donde la IA propone y el contrato dispone.