Por Yosef y Or, cofundadores de Atbash
La creencia más peligrosa en IA hoy no es que los modelos se volverán poderosos.
Esa parte es obvia.
La creencia peligrosa es más sutil. Es el supuesto que subyace en casi todas las hojas de ruta de productos, capas de gobernanza, sistemas de permisos, pilas de auditoría y marcos de agentes que se están construyendo hoy:
Que a medida que los modelos mejoren, los sistemas construidos a su alrededor se volverán más seguros como consecuencia.
No creo que eso sea lo que suceda.
Creo que estamos a punto de entrar en un período donde los productos de IA empeorarán en las dimensiones que realmente importan:
confianza,
contención,
predecibilidad,
recuperabilidad.
Los benchmarks subirán.
Las demostraciones serán más pulidas.
Los agentes serán más capaces.
Y los sistemas circundantes se volverán más frágiles, porque fueron construidos desde un modelo mental equivocado.
Ese es el error estructural.
El Software 2.0 está siendo protegido por Software 1.0.
Antes de presentar ese argumento, les debo una confesión sobre de dónde viene realmente esta empresa.
Una confesión.
Leo el Génesis como un documento técnico.
Soy judío religioso. He pasado la mayor parte de mi vida adulta pensando en la relación de Dios con los seres humanos. Esa pregunta fue la que me llevó, finalmente, a Atbash.
No porque el Génesis sea un manual de startups.
Porque el Génesis es la historia de línea roja más antigua que conozco.
El Jardín del Edén era un entorno controlado.
Una línea roja explícita:
no comer del árbol del conocimiento del bien y del mal.
La serpiente era una herramienta envenenada.
No podía alcanzar a Adán directamente, así que atacó a través de la bifurcación de confianza.
Eva recibió la inyección de reformulación:
no moriréis ciertamente,
seréis como dioses.
Ella llevó el razonamiento envenenado de vuelta al sistema.
Las defensas de Adán, que habían resistido ataques directos, no se activaron ante una entrada confiable.
Luego vino la parte importante.
Dios no los mató.
Dios los contuvo.
Los humanos fueron sacados del entorno controlado y colocados en un nuevo ambiente, la Tierra, donde pudieran desarrollar capacidades sin contaminar el sistema original.
Un ángel con una espada de fuego fue colocado en el límite para impedir el reingreso.
No castigo.
Arquitectura.
Atbash lleva el nombre del cifrado más antiguo conocido, del Libro de Jeremías:
una simple sustitución en el límite del significado.
El nombre refleja lo que el producto hace.
El producto refleja lo que leo en el Génesis.
La Torá me mostró que la seguridad no se crea limitando cada comportamiento.
La seguridad no se crea ralentizando todo el sistema.
La seguridad proviene de un pequeño número de líneas rojas,
aplicación absoluta,
y un límite que no duerme.
Tú defines las líneas rojas.
Atbash detiene a los agentes antes de que las crucen.
Los agentes no son humanos rápidos
Andrej @karpathy nombró el cambio de paradigma hace años.
Lo llamó Software 2.0:
código ya no escrito solo por humanos, sino entrenado.
Modelos reemplazando lógica.
Datos reemplazando especificaciones.
Describía en qué se había convertido la computación.
Pero casi toda la infraestructura que hemos construido para gobernar, permitir, asegurar y auditar el Software 2.0 sigue heredando supuestos del mundo del Software 1.0.
MCP.
x402.
AgentKit.
Marcos de delegación.
Motores de políticas.
Registros de auditoría.
Solicitudes firmadas.
Permisos con ámbito.
Flujos de aprobación humana.
Cada uno tiene sentido si crees que los agentes son básicamente humanos rápidos con APIs.
No lo son.
Son Teslas con tanques de gasolina atornillados.
Un sistema de energía completamente nuevo,
rodeado de infraestructura diseñada para una especie diferente de máquina.
Los humanos diseñan páginas de pago, así que construimos páginas de pago sin interfaz para agentes.
Los humanos firman solicitudes, así que construimos solicitudes firmadas para agentes.
Los humanos obtienen permisos por rol, así que construimos delegación con ámbito para agentes.
Los humanos aprueban acciones, así que construimos pantallas de aprobación para agentes.
Cada movimiento es lógico.
Ese es el problema.
La lógica pertenece al actor equivocado.
Un humano, con diez herramientas, normalmente no las encadena de maneras que los diseñadores nunca imaginaron.
Cuando algo se comporta de manera extraña, un humano a menudo lo nota y se detiene.
Un humano carga con dudas sociales,
miedo,
vergüenza,
aburrimiento,
sospecha
y contexto.
Los agentes no tienen nada de eso de manera confiable.
Los agentes encadenan herramientas de formas que ningún diseñador modeló.
Los agentes son remodelados por indicaciones,
memoria recuperada,
documentos,
salidas de herramientas
y contexto oculto de maneras que la capa de permisos circundante no puede ver.
Los agentes no tienen un reflejo natural de:
“eso es raro, déjame detenerme”
a menos que lo diseñemos.
E incluso entonces, puede ser eliminado con una indicación.
Esta es la falacia del humano rápido.
La creencia de que los agentes son solo versiones más rápidas de nosotros.
No lo son.
Y si el actor cambió, el modelo de control debe cambiar con él.
No odies al jugador. Odia el marco.
Esto es importante.
Los ejemplos anteriores o posteriores no son críticas a los equipos involucrados.
No a Anthropic.
No a OpenAI.
No a Microsoft.
No a Mistral.
No a OpenClaw.
No a Lovable.
No a Vercel.
No a nadie.
El punto es lo contrario.
Estos son equipos serios,
investigadores serios,
productos serios,
protocolos serios
y empresas serias chocando contra el mismo problema estructural.
Eso es lo que hace que el patrón sea peligroso.
Si solo los equipos malos fallaran, la respuesta sería mejores equipos.
Pero cuando equipos inteligentes siguen chocando contra la misma pared,
la pared es la historia.
El error no es que estos equipos no pensaron lo suficiente.
El error es que la industria sigue pensando desde el siglo equivocado del software.
Seguimos tratando a los agentes como humanos rápidos con APIs.
Y cada esquema de permisos,
registro de auditoría,
concesión con ámbito,
flujo de aprobación
y capa de gobernanza construida sobre ese supuesto hereda la misma grieta.
El enemigo no es el jugador.
El enemigo es el marco.
Las grietas comenzaron a formarse antes de lo que la mayoría imagina.
No porque los laboratorios frontera fueran descuidados.
Porque el actor cambió.
La primera grieta
Anthropic demostró algo que la industria entendía en silencio pero aún no había metabolizado completamente.
Cuando se le instruyó durante la evaluación, un modelo frontera encadenó múltiples vulnerabilidades, intentó escapar del entorno controlado y buscó caminos hacia acceso a internet fuera de su entorno de contención previsto.
Por separado, los sistemas frontera demostraron la capacidad de identificar vulnerabilidades que habían sobrevivido años de revisión humana, pruebas de fuzzing y auditoría manual.
La parte importante no fue que los modelos fueran maliciosos.
La parte importante fue que los sistemas ya no se mantenían dentro de la forma que sus diseñadores imaginaron.
Esa es la ruptura de categoría.
Un sistema capaz de descubrir caminos que los humanos repetidamente pasaron por alto no puede ser gobernado solo con supuestos que los humanos definieron antes de que el camino apareciera.
Eso no significa que los laboratorios frontera fallaran.
Significa que el actor cambió.
La segunda grieta
Microsoft reveló vulnerabilidades en Semantic Kernel donde la inyección de indicaciones podía dirigir flujos de trabajo de agentes hacia la ejecución de comandos a nivel de host.
Una oración se convirtió en un shell.
Ese es el cambio de categoría que se esconde debajo de la conversación sobre infraestructura.
El Software 1.0 trataba las indicaciones como entradas.
El Software 2.0 convierte cada vez más las indicaciones en posibles rutas de ejecución.
Esa distinción suena filosófica hasta que un agente comienza a traducir lenguaje natural en herramientas,
herramientas en comandos,
y comandos en cambios de estado del mundo real.
La parte importante no es que existiera una vulnerabilidad.
Las vulnerabilidades siempre existen.
La parte importante es qué tipo de vulnerabilidad era esta.
El agente no rompió su carácter.
Siguió la arquitectura exactamente como fue diseñada:
interpretar lenguaje,
seleccionar herramientas,
encadenar acciones,
ejecutar.
Y ese es el problema.
El modelo antiguo asumía que las instrucciones y la ejecución vivían en cajas conceptuales separadas.
Los agentes borran ese límite.
Una oración envenenada puede convertirse en una cadena de acciones privilegiadas.
Eso no es un humano rápido.
Eso es una especie de ejecución diferente.
La tercera grieta
Luego el patrón se extendió.
Vercel reveló una violación vinculada a una conexión comprometida de una herramienta de IA de terceros.
El atacante no comenzó irrumpiendo directamente por la puerta principal reforzada de Vercel.
Se movió a través de confianza delegada.
Un empleado había autorizado una herramienta de IA de terceros.
La conexión llevaba acceso.
La relación de confianza se convirtió en la ruta de ataque.
Ese es el nuevo problema de límite.
No porque Vercel fuera descuidada.
Porque los sistemas modernos están ahora llenos de bifurcaciones de confianza:
concesiones OAuth,
integraciones de IA,
extensiones de navegador,
flujos de trabajo de agentes,
automatizaciones internas,
permisos delegados
y aprobaciones antiguas que siguen vivas mucho después de que el contexto humano original desapareció.
El atacante ya no necesita vencer al castillo si el castillo ya confió en el mensajero.
El supuesto que murió:
que endurecer la superficie primaria es suficiente.
No lo es.
Tus herramientas adyacentes son ahora parte de tu perímetro de seguridad.
Luego el patrón se aceleró
La peor parte es que el marco ahora se reproduce automáticamente.
Los humanos están usando agentes para construir la próxima generación de herramientas para agentes más rápido de lo que los primitivos de gobernanza circundantes pueden evolucionar.
Aplicaciones codificadas por vibración.
Integraciones generadas por IA.
Servidores MCP escritos por agentes.
Flujos OAuth delegados ensamblados sin un modelado de amenazas completo.
Andamios de producción enviados por personas que apenas entienden el radio de explosión de lo que conectaron.
La industria llama a esto aceleración.
A veces lo es.
A veces es fragilidad industrializada.
Casi al mismo tiempo, la industria comenzó a chocar con una realización más amplia sobre las herramientas de agentes en sí.
Los sistemas tipo OpenClaw mostraron hacia dónde se dirigía la categoría:
agentes con memoria,
habilidades,
herramientas,
entornos de ejecución
y acceso delegado moviéndose a través de sistemas nunca diseñados para actores no humanos.
Karpathy llamó al ecosistema una pesadilla de seguridad.
No porque los agentes sean falsos.
Porque la categoría es real.
Y porque el modelo de control circundante aún asume que el actor se comporta como un solicitante humano.
En otro lugar, Lovable expuso cuán rápido el desarrollo nativo de IA puede industrializar viejos errores de autorización.
"Inició sesión" se confundió con "autorizado".
"Público" se confundió con "entendido".
"Configurable" se confundió con "seguro".
Y fuera del mundo nativo de IA por completo, incidentes como KelpDAO siguieron revelando la misma grieta estructural desde otro ángulo:
sistemas viviendo entre supuestos delegados,
responsabilidad compartida,
ambigüedad de límites
y ninguna capa de autoridad final antes de la consecuencia.
El patrón se repite porque el mismo modelo mental se repite.
Confianza heredada.
Autoridad delegada.
Ambigüedad de límites.
Supuestos compartidos.
Ninguna autoridad final antes de la consecuencia.
La misma grieta apareció en la cadena de suministro de software.
En la campaña Mini Shai-Hulud, lanzamientos de paquetes comprometidos se extendieron por partes del ecosistema npm y PyPI, incluyendo paquetes de Mistral AI, TanStack, UiPath y otros.
La advertencia no fue meramente que los paquetes pueden ser comprometidos.
Todos ya lo saben.
La advertencia fue que las rutas de lanzamiento confiables, paquetes de apariencia válida e infraestructura de desarrollador pueden convertirse en canales de propagación una vez que la autoridad se hereda en lugar de ser verificada nuevamente en el límite.
La falacia se acumula
La peor parte es que esto no se autocorrige.
Los humanos ahora están usando agentes para construir la próxima generación de herramientas para agentes,
a mayor velocidad,
dentro del mismo marco roto.
Cada agente de codificación que escribe un servidor MCP.
Cada despliegue asistido por IA de un esquema de permisos.
Cada andamio codificado por vibración enviado a producción.
Cada integración generada por agentes que hereda viejos supuestos de OAuth.
Cada capa de aprobación que asume que el agente se comportará como un solicitante humano.
En uno de nuestros propios entornos beta, observamos un enjambre de agentes lavando instrucciones maliciosas en pasos de ejecución de apariencia limpia antes de que las capas de inspección posteriores vieran la intención original.
Un sistema que inspeccionara solo la llamada final de herramienta habría pasado por alto la transformación por completo.
El límite ya era demasiado tarde.
Eso importó.
Porque el modelo no estaba “rompiendo” el flujo de trabajo.
Lo estaba siguiendo:
interpretando,
reescribiendo,
planificando
y traduciendo la intención antes de la ejecución.
La instrucción maliciosa desapareció aguas arriba mucho antes de que la acción irreversible surgiera aguas abajo.
Cada registro de auditoría que registra el resultado pero no la decisión de límite antes del resultado.
El marco no se corrige a medida que escalamos.
Se endurece.
Porque cada envío exitoso de rieles a través del prisma humano refuerza la creencia de que el prisma era correcto.
Mientras tanto, las capacidades se envían primero.
Los primitivos de gobernanza se envían después.
Si acaso.
La brecha entre lo que los agentes pueden hacer y lo que los rieles circundantes pueden ver se amplía con cada lanzamiento de modelo.
Y los equipos que importarán en los próximos doce meses no serán los que tengan la demostración más ingeniosa.
Serán los que entiendan dónde están las líneas rojas.
No cada acción.
Eso mataría al sistema.
La mayoría del comportamiento de los agentes debería fluir.
Pero las acciones irreversibles no pueden dejarse a la confianza heredada,
permisos vagos
o juicio del agente.
Mover fondos.
Tocar producción.
Exportar datos de clientes.
Usar acceso OAuth delegado para entrar a un entorno interno.
Cambiar infraestructura.
Liberar secretos.
Aprobar transacciones.
Eliminar registros.
Cruzar de simulación a estado.
Esas no son acciones ordinarias.
Esas son líneas rojas.
Qué hace Atbash
Atbash está construido para el momento antes de que una acción sensible de un agente se vuelva real.
Ese es el límite.
No todo el flujo de trabajo.
No cada pensamiento.
No cada token.
No cada llamada de herramienta.
El límite.
El momento antes de que el agente cruce de intención a consecuencia.
Allí ocurren tres cosas.
Aplicación
Tú defines las líneas rojas.
Atbash evalúa acciones sensibles seleccionadas de agentes antes de la ejecución y devuelve:
PERMITIR.
RETENER.
BLOQUEAR.
Si la acción cruza un límite prohibido, puede ser encarcelada antes de que alcance el estado del mundo real.
No registrada después del hecho.
No denegada para que el agente pueda reintentar alrededor.
Encarcelada.
No tocarás la base de datos de producción.
No moverás fondos por encima de este umbral.
No exportarás la lista de clientes.
No rotarás secretos sin aprobación.
No usarás acceso delegado para entrar a este entorno.
La mayoría del comportamiento de los agentes debería fluir.
Atbash interviene solo en los límites que importan:
lo irreversible,
lo consecuente,
los lugares donde “déjame deshacer eso” no existe.
Linaje
Cuando algo sale mal, la primera pregunta ya no es:
“¿Qué dice el sistema comprometido que sucedió?”
Atbash registra la acción intentada,
la versión de la política,
el veredicto,
el límite invocado
y la decisión del operador cuando los humanos son involucrados.
El registro está anclado criptográficamente para que la línea de tiempo pueda reconstruirse bajo disputa.
Eso importa porque lo primero que hacen los atacantes y los despliegues descuidados es destruir la historia.
Reescriben registros.
Difuminan líneas de tiempo.
Discuten quién aprobó qué.
Hacen que el incidente sea irreconstruible.
Atbash no intenta reemplazar cada sistema de auditoría.
Intenta hacer que la decisión de límite sea demostrable.
¿Quién intentó cruzar qué línea roja?
¿Qué política existía en ese momento?
¿Fue la acción permitida,
retenida,
bloqueada
o encarcelada?
¿Quién intervino?
¿Qué cambió después?
Ese es el registro que importa cuando comienza la discusión.
Adaptación
Cuando el mismo tipo de presión de límite aparece una y otra vez, Atbash lo saca a la superficie.
Quizás la política es demasiado laxa.
Quizás una herramienta está envenenando el flujo de trabajo.
Quizás una fuente de memoria está empujando al agente hacia la línea.
Quizás una clase de indicación sigue dirigiendo el sistema hacia territorio prohibido.
Quizás el operador descubrió una nueva línea roja que no existía ayer.
Atbash saca a la superficie el patrón.
El operador decide.
Esa distinción importa.
No creemos que la seguridad provenga de fingir que el sistema puede conocer mágicamente cada límite futuro.
La seguridad proviene de hacer visible la presión de límite antes de la consecuencia,
y luego dejar que el operador endurezca las líneas rojas que importan.
Un mejor motor de políticas sigue aplicando políticas.
Un mejor esquema de permisos sigue otorgando roles.
Una mejor pila de auditoría sigue registrando resultados.
Un mejor producto de seguridad sigue detectando amenazas.
Atbash es diferente porque se sitúa antes de que acciones irreversibles seleccionadas se ejecuten.
Ese es el primitivo.
No gobernanza genérica.
No disfraz de seguridad de agentes.
No niebla de “capa de confianza”.
Un límite de línea roja previo a la ejecución para agentes.
Tú defines las líneas rojas.
Atbash detiene a los agentes antes de que las crucen.
Lo que viene después
Unos pocos equipos estrella están haciendo trabajo real y tienen iniciativas reales en esta categoría.
@AnthropicAI con Project Glasswing.
@OpenAI con Daybreak.
@linuxfoundation con MCP.
@Microsoft con AGT.
@Google con SGP.
@CheckPointSW, CrowdStrike, Palo Alto y Cisco.
Y muchos otros.
Entienden que la aceleración de capacidades sin nuevos primitivos de control se está volviendo peligrosa.
No estamos intentando vencerlos en su propio juego.
Eso sería delirante.
Tienen bancos de investigación más profundos,
conjuntos de datos más grandes,
equipos de seguridad más amplios,
más credibilidad empresarial,
mayor distribución
y organizaciones cibernéticas más maduras.
Bien.
Dejemos que hagan lo que están hechos para hacer.
No estamos intentando reemplazar el trabajo que estos equipos están haciendo.
La categoría los necesita.
La aceleración de capacidades sin nuevos primitivos de control se vuelve peligrosa muy rápido.
Estamos compitiendo en el marco.
¿Qué tipo de actor es un agente?
¿Dónde reside realmente la autoridad?
¿Qué acciones son demasiado consecuentes para dejarlas a la confianza heredada?
¿Qué debería suceder en el momento final antes de que un agente cambie el estado del mundo real?
Ese es nuestro terreno.
El viejo mundo pregunta:
¿Tenía el sistema permiso?
El nuevo mundo pregunta:
¿Debería este agente tener permitido cruzar esta línea roja ahora mismo?
Esas no son la misma pregunta.
Nosotros los humanos cruzamos la primera línea roja.
El problema es más antiguo que la tecnología.
También la solución.
Descubre qué líneas rojas tu pila actual no puede realmente aplicar antes de que un agente las cruce.
Luego decide cuánto tiempo puedes esperar.
La CLI, el SDK y el panel de operador se están implementando selectivamente para equipos que despliegan agentes en flujos de trabajo sensibles.
Atbash.ai
