Traducción al Español
Por Yosef y Or, cofundadores de Atbash
La creencia más peligrosa en la IA hoy en día no es que los modelos se volverán poderosos.
Esa parte es obvia.
La creencia peligrosa es más silenciosa. Es la suposición que subyace bajo casi todas las hojas de ruta de producto, capas de gobernanza, sistemas de permisos, stacks de auditoría y marcos de agentes que se están construyendo ahora mismo:
Que a medida que los modelos mejoran, 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,
predictibilidad,
recuperabilidad.
Los benchmarks subirán.
Los demos serán más pulidos.
Los agentes se volverán más capaces.
Y los sistemas circundantes se volverán más frágiles, porque fueron construidos desde el modelo mental equivocado.
Ese es el error estructural.
El Software 2.0 está siendo protegido por el 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 lo que me llevó, eventualmente, 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 sandbox.
Una línea roja explícita:
no comas 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 del fork de confianza.
Eva recibió la inyección de reencuadre:
no moriréis,
seréis como dioses.
Ella llevó el razonamiento envenenado de vuelta al sistema.
Las defensas de Adán, que habían resistido un ataque directo, no se activaron frente a una entrada confiable.
Luego vino la parte importante.
Dios no los mató.
Dios los contuvo.
Los humanos fueron removidos del sandbox y colocados en un nuevo entorno, la Tierra, donde podrían desarrollar capacidad sin contaminar el sistema original.
Un ángel con una espada llameante fue colocado en el límite para prevenir el reingreso.
No un 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 especificación.
Estaba describiendo en qué se había convertido la computación.
Pero casi cada pieza de infraestructura que construimos para gobernar, permitir, asegurar y auditar el Software 2.0 aún hereda suposiciones 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 alcance.
Flujos de aprobación humana.
Cada una 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 poder 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 headless 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 alcance 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 en formas 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 lleva consigo hesitación social,
miedo,
vergüenza,
aburrimiento,
sospecha,
y contexto.
Los agentes no tienen nada de eso de manera confiable.
Los agentes encadenan herramientas en formas que ningún diseñador modeló.
Los agentes son moldeados por prompts,
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:
"esto es raro, déjame parar"
a menos que ingenieremos uno.
E incluso entonces, puede ser eliminado con un prompt.
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 tiene que 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 el opuesto.
Estos son equipos serios,
investigadores serios,
productos serios,
protocolos serios,
y empresas serias encontrando el mismo problema estructural.
Eso es lo que hace peligroso el patrón.
Si solo los equipos malos fallaran, la respuesta serían 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 alcance,
flujo de aprobación,
y capa de gobernanza construida sobre esa suposición hereda la misma grieta.
El enemigo no es el jugador.
El enemigo es el marco.
Las grietas empezaron a formarse antes de lo que la mayoría de la gente se dio cuenta.
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 una evaluación, un modelo frontera encadenó múltiples vulnerabilidades, intentó escapar del sandbox y buscó caminos hacia el 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, 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 a través de suposiciones 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 prompts podía dirigir flujos de trabajo de agentes hacia la ejecución de comandos a nivel de host.
Una frase 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 los prompts como entradas.
El Software 2.0 convierte cada vez más los prompts en posibles rutas de ejecución.
Esa distinción suena filosófica hasta que un agente empieza a traducir lenguaje natural en herramientas,
herramientas en comandos,
y comandos en cambios de estado en el 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 personaje.
Siguió la arquitectura exactamente como fue diseñada:
interpretar lenguaje,
seleccionar herramientas,
encadenar acciones,
ejecutar.
Y ese es el problema.
El viejo modelo asumía que las instrucciones y la ejecución vivían en cajas conceptuales separadas.
Los agentes borran ese límite.
Una frase envenenada puede convertirse en una cadena de acciones privilegiadas.
Eso no es un humano rápido.
Esa es una especie de ejecución diferente.
La tercera grieta
Luego el patrón se extendió.
Vercel reveló una brecha vinculada a una conexión comprometida de una herramienta de IA de terceros.
El atacante no comenzó rompiendo directamente la puerta principal fortificada de Vercel.
Se movió a través de la 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 del límite.
No porque Vercel fuera descuidado.
Porque los sistemas modernos ahora están llenos de forks 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 derrotar el castillo si el castillo ya confiaba en el mensajero.
La suposición que murió:
que endurecer la superficie principal 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 a sí mismo 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 con vibe-coding.
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í mismas.
Los sistemas estilo 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 qué tan rápido el desarrollo nativo de IA puede industrializar errores de autorización antiguos.
"Con sesión iniciada" 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 suposiciones delegadas,
responsabilidad compartida,
ambigüedad de límites,
y sin una capa de autoridad final antes de la consecuencia.
El patrón se repite una y otra vez porque el mismo modelo mental se repite una y otra vez.
Confianza heredada.
Autoridad delegada.
Ambigüedad de límites.
Suposiciones compartidas.
Sin autoridad final antes de la consecuencia.
La misma grieta apareció en la cadena de suministro de software.
En la campaña Mini Shai-Hulud, versiones de paquetes comprometidas se extendieron por partes del ecosistema npm y PyPI, incluyendo paquetes de Mistral AI, TanStack, UiPath y otros.
La advertencia no era meramente que los paquetes pueden ser comprometidos.
Todos ya lo saben.
La advertencia era que las rutas de publicación confiables, los paquetes de apariencia válida y la infraestructura de desarrolladores pueden convertirse en canales de propagación una vez que la autoridad se hereda en lugar de verificarse nuevamente en el límite.
La falacia se agrava
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 escribiendo un servidor MCP.
Cada despliegue asistido por IA de un esquema de permisos.
Cada andamio con vibe-coding enviado a producción.
Cada integración generada por agentes que hereda suposiciones OAuth antiguas.
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 blanqueando 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 de herramienta final 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,
planeando,
y traduciendo la intención antes de la ejecución.
La instrucción maliciosa desapareció upstream mucho antes de que la acción irreversible surgiera downstream.
Cada registro de auditoría que registra el resultado pero no la decisión en el 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 es que se envían.
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 el demo más ingenioso.
Serán los que entiendan dónde están las líneas rojas.
No cada acción.
Eso mataría el sistema.
La mayoría del comportamiento de los agentes debe fluir.
Pero las acciones irreversibles no pueden dejarse a la confianza heredada,
permisos vagos,
o al 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.
Lo que 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.
Tres cosas suceden allí.
Aplicación
Tú defines las líneas rojas.
Atbash evalúa acciones sensibles seleccionadas de agentes antes de la ejecución y devuelve:
ALLOW.
HOLD.
BLOCK.
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 evitándola.
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 debe 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é afirma 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 ser reconstruida 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.
Disputan 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 en el 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 en el límite aparece una y otra vez, Atbash lo saca a la superficie.
Quizás la política es demasiado flexible.
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 prompt 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 pretender que el sistema puede saber mágicamente cada límite futuro.
La seguridad proviene de hacer visible la presión en el 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.
Un mejor stack de auditoría sigue registrando resultados.
Un mejor producto de seguridad sigue detectando amenazas.
Atbash es diferente porque se sitúa antes de que las acciones irreversibles seleccionadas se ejecuten.
Ese es el primitivo.
No gobernanza genérica.
No cosplay 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 estelares 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 tratando de ganarles 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.
Que hagan lo que están construidos para hacer.
No estamos tratando de 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ápidamente.
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 lo es la solución.
Descubre qué líneas rojas tu stack 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 del operador se están implementando selectivamente para equipos que despliegan agentes en flujos de trabajo sensibles.
Atbash.ai
