La advertencia de confianza cero de Vishal Sharma: los agentes de IA necesitan pruebas de control

Vishal Sharma cuestiona una promesa de seguridad conocida: decirles a los agentes de IA que sigan reglas no demuestra que esas reglas se hayan cumplido realmente. La advertencia de confianza cero de Vishal Sharma se refiere a los agentes de IA, sistemas que utilizan modelos y herramientas de software para actuar en pos de un objetivo. El investigador de Queen’s University Belfast pregunta qué evidencia queda cuando un agente afirma haber eliminado información, respetado una restricción o completado una tarea autorizada.

El argumento presiona a compradores empresariales y desarrolladores para que distingan la cooperación del control exigible. Un agente que informa de éxito ha proporcionado una respuesta. Un sistema que registra de forma independiente la operación pertinente ha proporcionado algo que los compradores pueden investigar. Esos resultados merecen distintos niveles de confianza.

La referencia histórica es la arquitectura de confianza cero de NIST, un enfoque de seguridad que rechaza la confianza automática basada en la ubicación de red o la propiedad. El desafío de Sharma se refiere a cómo sobrevive ese principio cuando los agentes interpretan información, delegan trabajo y trasladan contexto entre tareas. La disyuntiva central es concreta: una autonomía útil necesita acceso, mientras que una autonomía responsable necesita límites que sigan siendo efectivos cuando el modelo comete un error.

La advertencia de confianza cero de Vishal Sharma comienza con la falta de evidencia

El análisis sobre seguridad de agentes de Sharma, patrocinado por su universidad y publicado por IEEE Spectrum, cuestiona cómo verifican las organizaciones el comportamiento de los agentes. Su patrocinio importa: los lectores deberían tratarlo como una contribución institucional al debate, no como una validación independiente de un sistema comercial de seguridad.

El artículo describe agentes que operan bajo un orquestador, software que coordina sus tareas. Plantea la posibilidad de que prompts posteriores recuperen información que previamente se indicó a un agente que olvidara. También informa de un experimento interno de Queen’s University Belfast en el que ataques de desautenticación orquestados por agentes tardaron entre dos y tres segundos. Los ataques de desautenticación interrumpen la conexión inalámbrica autenticada de un dispositivo.

La contribución más sólida del artículo es su exigencia de evidencia, aunque sus afirmaciones experimentales necesitan más detalle antes de respaldar conclusiones amplias.

El relato publicado no aporta metodología suficiente para establecer un parámetro general de velocidad de ataque. Su discusión sobre la recuperación de contexto tampoco demuestra que se haya reconstruido información eliminada físicamente. Que la información siga accesible en algún punto de un flujo de trabajo plantea un problema distinto al de recuperar datos que ya no existen.

Esa distinción debería orientar la respuesta. Una afirmación sobre olvidar necesita un objeto definido: un mensaje, un registro almacenado, un documento accesible o el comportamiento aprendido de un modelo. Sin esa definición, las organizaciones no pueden acordar cómo sería una eliminación exitosa.

Consideremos un asistente hipotético de elaboración de perfiles de clientes. Un usuario retira el permiso para utilizar una entrevista anterior. El asistente confirma que ignorará la entrevista y luego produce una recomendación similar a su evaluación previa. Esa semejanza por sí sola no puede establecer si el asistente recuperó la entrevista, retuvo un resumen o llegó de forma independiente a la misma conclusión.

Una investigación tendría que examinar qué retuvo y a qué accedió realmente el sistema. La explicación generada podría ofrecer una pista, pero la explicación por sí misma no resolvería la cuestión. El comportamiento en disputa se refiere a la maquinaria que rodea la respuesta, incluidos los registros que siguieron disponibles.

Para los compradores, esto cambia la evidencia que vale la pena solicitar. Una demostración pulida puede mostrar que un asistente responde correctamente durante una sesión preparada. Una prueba de fallo controlada puede revelar si una restricción sobrevive a una solicitud inesperada. Esas demostraciones responden a preguntas de compra diferentes.

El valor informativo reside en ese cambio de énfasis. Sharma dirige la atención al punto en que una promesa verbal se convierte en una afirmación operativa. Cuando un agente maneja información sensible o acciones con consecuencias, ese punto merece un examen explícito.

También crea un estándar más justo para los proveedores. Un proveedor no debería tener que prometer que su modelo nunca producirá una respuesta indeseable. Debería poder explicar los límites de su despliegue y proporcionar evidencia adecuada para esos límites.

La confianza cero sigue siendo aplicable, pero la identidad no puede determinar la intención

La arquitectura de confianza cero de NIST, publicada en agosto de 2020, centra la protección en los recursos en lugar de asumir que una red interna es de confianza. Su planteamiento separa la autenticación, que establece la identidad, de la autorización, que determina el acceso permitido.

Ese marco no queda obsoleto porque el software pueda interpretar lenguaje natural. Ofrece un punto de partida útil: la ubicación de un agente dentro de una organización no justifica automáticamente el acceso a sus recursos.

El problema analítico es cuánta autoridad debería recibir un agente autenticado para la tarea que está realizando en ese momento.

Imaginemos un asistente autorizado para preparar una comparación de proveedores. Leer propuestas aprobadas encaja con esa asignación. Enviar a un proveedor un informe confidencial de negociación plantea una cuestión distinta, incluso si el mismo asistente tiene la capacidad técnica de enviar correos electrónicos.

Una autenticación exitosa establecería qué cuenta intentó realizar el envío. No establecería, por sí sola, que el usuario pretendía esa divulgación concreta. Por tanto, el debate de seguridad debe examinar la acción solicitada y la autoridad que la respalda.

Aquí es donde los despliegues de agentes complican decisiones empresariales conocidas. Una instrucción humana puede describir un resultado sin enumerar cada operación intermedia. “Prepara la comparación” deja margen para la interpretación. La organización aún debe decidir qué operaciones puede autorizar esa interpretación.

De ahí surge una pregunta razonable de compra: ¿qué ocurre cuando el asistente elige un paso innecesario? La respuesta debería identificar el componente responsable de permitir o rechazar la operación. Una promesa de que el asistente suele elegir pasos sensatos aborda el comportamiento, mientras que el comprador pregunta por la autoridad.

El mismo razonamiento se aplica a la delegación. Supongamos que un asistente coordinador pide a otro agente que investigue el historial de un proveedor. ¿Esa solicitud conlleva permiso para inspeccionar contratos confidenciales? ¿Permite una delegación posterior? ¿Qué restricción original sigue siendo visible para el servicio receptor?

Estas son preguntas hipotéticas de diseño, no hallazgos de que todas las plataformas de agentes gestionen incorrectamente la delegación. Su propósito es exponer supuestos antes de que los compradores concedan un acceso amplio. Un despliegue puede parecer ordenado mientras deja su modelo de autoridad mal especificado.

Por ello, los equipos de seguridad se enfrentan a un problema de alcance. Evaluar a un agente como una sola aplicación podría pasar por alto diferencias significativas entre leer, editar, enviar y eliminar. Evaluar manualmente cada operación inocua crearía una carga diferente. La evaluación útil se sitúa entre esos extremos.

Por tanto, los equipos de producto deberían esperar preguntas sobre la relación entre la intención de una tarea y el permiso ejecutable. Un cliente que solicita esa relación está pidiendo una propiedad del sistema, no simplemente otra instrucción para el modelo.

La advertencia de confianza cero de Vishal Sharma es más útil cuando se lee desde esta perspectiva. Desafía a las organizaciones a hacer inspeccionables sus supuestos sin afirmar que todos los principios existentes de control de acceso hayan fracasado.

La memoria hace más difícil ignorar la disyuntiva

La guía de seguridad de agentes de IA de OWASP aborda el aislamiento de memoria, la expiración, el manejo de datos sensibles y la autorización fuera del contexto de un agente. Contexto significa la información proporcionada al modelo mientras genera una respuesta.

La guía también identifica el envenenamiento de memoria, la persistencia de información maliciosa que influye en comportamientos posteriores. Esa preocupación conecta la información retenida con acciones futuras, en lugar de tratar cada respuesta como un evento aislado.

Para los compradores empresariales, la disyuntiva sin resolver es cuánta historia útil debería retener un asistente y bajo qué autoridad continua.

Consideremos un flujo de trabajo hipotético de investigación que convierte entrevistas en un informe de proyecto. Las notas históricas ayudan al asistente a evitar repetir preguntas y preservar decisiones. Esos beneficios crean una razón legítima para retener información. También hacen más complejas de evaluar las solicitudes de retirada.

Supongamos que un participante en una entrevista solicita eliminar una declaración sensible. El comprador necesita saber qué promesa ofrece el producto. Eliminar la transcripción original, excluirla de futuras búsquedas y revisar un informe derivado son resultados distinguibles.

Un contrato significativo especificaría el resultado aplicable. Una demostración probaría entonces directamente ese resultado. Preguntarle al asistente si recuerda la declaración proporcionaría evidencia más débil porque la pregunta depende de la misma interfaz cuyo comportamiento está en disputa.

Esta distinción también importa para el trabajo cotidiano con conocimiento. Quien elige una base de conocimiento personal necesita entender cómo se relacionan la recopilación, la recuperación y la eliminación. La comodidad no responde a esas preguntas, y una categoría de producto no establece una garantía de seguridad.

También existe una tensión entre investigación y minimización. Una organización puede querer suficiente historial para explicar una recomendación con consecuencias. Al mismo tiempo, puede querer evitar conservar información personal innecesaria. Ninguno de los dos objetivos desaparece porque un asistente realice el trabajo.

Una investigación hipotética ilustra la dificultad. Un cliente cuestiona una recomendación después de que se haya eliminado la entrevista subyacente. Los investigadores necesitan una explicación de qué evidencia autorizada informó la decisión. Conservar todos los registros en bruto para siempre socavaría la promesa de eliminación; no conservar nada frustraría la investigación.

La implicación editorial es que “memoria” merece un lenguaje de producto más preciso. Los compradores deberían esperar descripciones de los registros implicados y de las garantías asociadas a cada uno. Un único interruptor etiquetado como “olvidar” deja demasiado margen para expectativas incompatibles.

La presión comercial recae sobre los proveedores que venden continuidad entre proyectos. Cuanto más útil se vuelve esa continuidad, más importantes se vuelven sus límites para un cliente que evalúa trabajo sensible. El valor de una función de memoria y sus requisitos de gobernanza crecen conjuntamente.

Por tanto, la pregunta de Sharma va más allá de un escenario de ataque inusual. Expone una cuestión básica de compra: si una organización puede verificar el manejo de la información después de que la conversación haya avanzado.

La investigación sobre navegadores muestra por qué la arquitectura eleva lo que está en juego

Los investigadores de la University of Washington Franziska Roesner y David Kohlbrenner examinaron los límites de origen de los navegadores en siete navegadores agénticos. Su trabajo se refiere a la política del mismo origen, una regla de los navegadores que separa sitios web mutuamente no confiables.

Su informe de abril de 2026 describe experimentos realizados a finales de enero y principios de febrero. Informa de una demostración de ataque de origen cruzado que involucra a ChatGPT Atlas en Agent Mode. Para varios otros productos, identifica las condiciones previas para el ataque, en lugar de ataques completados equivalentes.

El escenario depende de condiciones específicas, incluida una inyección de prompts exitosa, un intento de lograr que un agente trate contenido no confiable como instrucciones. Las versiones y configuraciones probadas son importantes. Estos hallazgos no deben convertirse en una afirmación sin fundamento sobre todas las versiones actuales de navegadores.

La cuestión arquitectónica más amplia es si el acceso de un asistente crea una vía que el código ordinario de un sitio web no tendría.

Para los compradores, esa pregunta ofrece una comparación más útil que una clasificación genérica de la inteligencia de los modelos. Un asistente capaz podría operar dentro de límites de acceso estrechos. Otra implementación podría exponer información más amplia mientras depende en mayor medida del criterio del asistente.

Estas configuraciones plantean decisiones de compra distintas incluso cuando sus demostraciones parecen similares. Ambas podrían resumir una página correctamente. Solo un análisis más detallado revelaría a qué información adicional puede acceder cada asistente durante esa tarea.

Pensemos en un empleado hipotético que solicita un resumen de una página pública de un proveedor. El resultado previsto se refiere a esa página. Si el flujo de trabajo también permite acceder a material empresarial privado, los evaluadores deben entender por qué existe ese acceso y qué limita su uso.

La solicitud del empleado proporciona un punto de referencia útil. Define el propósito empresarial frente al cual puede evaluarse el acceso adicional. Un resumen satisfactorio no responde a si el sistema expuso más información de la que exigía la tarea.

Esta es también la razón por la que las comparaciones requieren un lenguaje cuidadoso. Los investigadores que identifican una posible vía de daño han establecido algo que merece ser investigado. No han demostrado necesariamente un ataque exitoso contra todos los productos que comparten una característica de diseño.

Un comprador debería aplicar la misma disciplina a las respuestas de los proveedores. Un ejemplo corregido puede cerrar una vía demostrada sin establecer que todas las vías relacionadas hayan desaparecido. A la inversa, un hallazgo de investigación antiguo no debe presentarse automáticamente como una vulnerabilidad sin resolver hoy.

La lección para el debate actual es metodológica. Las afirmaciones de seguridad se vuelven más informativas cuando identifican el límite probado, las condiciones implicadas y el resultado observado. Los nombres de productos por sí solos no pueden sostener esa explicación.

Esto respalda la exigencia de pruebas de Sharma, al tiempo que añade un límite importante. La evidencia debe seguir vinculada al sistema y a las circunstancias que la produjeron. Extenderla más allá requiere pruebas adicionales, no una retórica más contundente.

Un Mejor Comportamiento del Modelo No Resuelve la Cuestión de la Contención

El informe de Anthropic de noviembre de 2025 sobre las defensas contra la inyección de prompts describe el entrenamiento, los sistemas de detección y las pruebas adversariales para el uso del navegador. La empresa reconoce explícitamente que los agentes de navegador siguen siendo vulnerables.

Su análisis de mayo de 2026 sobre la contención de agentes distingue las defensas del modelo de las restricciones sobre el entorno en el que opera un agente. La contención implica limitar lo que un sistema puede alcanzar o hacer. Anthropic describe el uso de límites ambientales junto con medidas destinadas a mejorar el comportamiento del modelo.

Estos son informes del proveedor sobre su enfoque. Establecen la justificación de seguridad declarada por la empresa, en lugar de una prueba independiente de que cada implementación logre la protección prevista.

La comparación importante consiste en reducir la probabilidad de un error y limitar las consecuencias cuando este se produce.

Un asistente hipotético para documentos hace concreta esa distinción. Un mejor criterio podría ayudarle a rechazar una instrucción engañosa dentro de una propuesta. Una restricción de acceso podría impedirle obtener un documento confidencial no relacionado, independientemente de cómo interprete esa instrucción.

Estos resultados responden a preguntas distintas. El cliente quiere un comportamiento sensato durante el trabajo legítimo. También quiere una respuesta defendible sobre lo que ocurre ante un fallo. Una evaluación exhaustiva debería examinar ambos aspectos.

Esto crea un desafío práctico para las presentaciones de compras. Las demostraciones de modelos son fáciles de entender porque muestran un comportamiento visible. Las restricciones ambientales pueden parecer menos impresionantes hasta que un evaluador pide al sistema que cruce un límite prohibido.

Una demostración convincente haría visible el intento de cruce. Los evaluadores podrían examinar entonces qué lo bloqueó, qué evidencia permaneció y si la tarea legítima pudo continuar. El rechazo en sí mismo sería solo una parte del resultado.

La evaluación también debería considerar el coste de las restricciones. Un asistente estrictamente limitado podría requerir información adicional del usuario o no completar una tarea por lo demás razonable. Eso no hace que la restricción sea errónea. Convierte su efecto operativo en parte de la decisión de compra.

Del mismo modo, las interrupciones frecuentes no son automáticamente prueba de una seguridad superior. Una interrupción merece atención cuando ayuda a una persona a comprender y autorizar una consecuencia significativa. Una solicitud de aprobación imprecisa puede dejar la decisión subyacente igual de poco clara.

Por tanto, la pregunta útil para el comprador es específica: ¿qué acción propuesta está esperando la autoridad de quién y qué cambia exactamente tras la aprobación? La respuesta debe seguir siendo comprensible para alguien responsable del resultado empresarial.

Este enfoque evita una competencia artificial entre modelos más inteligentes y límites más sólidos. Los clientes se benefician de ambos, pero deberían pedir a los proveedores que expliquen qué aporta cada uno. La mejora en un área no demuestra una mejora en todas las demás.

También intensifica la presión competitiva. Los proveedores que venden una autonomía más amplia necesitan evidencia proporcional a la autoridad que solicitan sus productos. La carga aumenta con las consecuencias de una acción equivocada.

La advertencia de confianza cero de Vishal Sharma encaja en ese debate sin resolverlo. La cuestión es si la implementación ofrece una explicación creíble del control cuando el comportamiento cooperativo deja de ser suficiente.

La Próxima Evidencia Debería Proceder de Pruebas de Fallo

Durante los próximos tres meses, las señales más útiles se referirán a la reproducibilidad, la aplicación de restricciones y el comportamiento bajo condiciones realistas de fallo. Estos son puntos de seguimiento editoriales, no compromisos de lanzamiento anunciados.

La evidencia más sólida explicará qué falló, qué permaneció protegido y si el trabajo legítimo aún se completó.

En primer lugar, conviene observar si surge una descripción reproducible del experimento de Queen’s University Belfast. Una publicación más completa debería identificar idealmente el equipo, la configuración, el método de cronometraje y la referencia utilizados para evaluar la velocidad de ataque reportada.

Esa evidencia reforzaría la afirmación experimental si equipos independientes obtuvieran resultados comparables bajo condiciones declaradas. Un resultado más limitado seguiría siendo informativo. Ayudaría a los lectores a distinguir una observación concreta de laboratorio de una afirmación general sobre ataques asistidos por agentes.

El mismo estándar se aplica a la recuperación de contexto. Una prueba útil definiría qué información se eliminó, dónde había existido y qué vías de recuperación permanecían. Sin esos detalles, la aparente rememoración deja abiertas demasiadas explicaciones.

En segundo lugar, conviene observar lanzamientos de productos que faciliten la inspección de los límites de autoridad. La señal relevante es un cambio documentado vinculado a una restricción comprobable. Una nueva etiqueta de seguridad, por sí sola, no proporciona esa evidencia.

Por ejemplo, una versión hipotética podría demostrar que un asistente puede preparar un mensaje externo mientras un componente separado controla su transmisión. Los evaluadores aún tendrían que examinar el destinatario, el contenido y las condiciones de autorización cubiertas por esa restricción.

Esa evidencia reforzaría el argumento de que los proveedores están traduciendo principios generales de seguridad en controles desplegables. Un lanzamiento que simplemente añadiera otra instrucción ofrecería menos respaldo a las afirmaciones sobre límites aplicados de forma independiente.

En tercer lugar, conviene observar evaluaciones independientes que prueben la recuperación junto con la resistencia a ataques. Bloquear una operación no deseada es valioso. Los compradores también necesitan saber si el sistema puede recuperarse sin repetir el intento, perder trabajo autorizado o requerir una intervención excesiva.

Una evaluación hipotética podría comparar la misma tarea antes y después de una restricción de acceso. El resultado debería describir tanto las acciones prohibidas como la finalización legítima. De lo contrario, un sistema que logra poco podría parecer seguro por una razón poco útil.

Los resultados que muestren daños acotados y trabajo autorizado completado con éxito reforzarían el argumento a favor de una autonomía práctica. Los resultados que muestren que una finalización útil requiere un acceso amplio y mal explicado dejarían al descubierto una disyuntiva persistente.

Estas señales importan porque, de otro modo, el argumento actual puede volverse circular. Los investigadores piden verificación. Los proveedores describen salvaguardas. Los compradores reciben garantías sin una explicación común de lo que cubren esas garantías.

Una evidencia más precisa permitiría un desacuerdo más acotado y productivo. Una implementación podría ser adecuada para la redacción y la investigación, mientras que otra respalda operaciones con consecuencias relevantes. La justificación debería identificar qué puede establecer cada sistema sobre su comportamiento.

Para los desarrolladores, la implicación inmediata es hacer comprobables las afirmaciones de seguridad antes de ampliar las responsabilidades de un agente. Para los compradores empresariales, consiste en vincular la evidencia solicitada con una consecuencia empresarial específica. Para los trabajadores del conocimiento, consiste en comprender la autoridad asociada a un asistente antes de asignarle trabajo sensible.

Antes de su próximo piloto de agentes, elija una acción controvertida y defina la evidencia que la resolvería. Considere un destinatario no autorizado, un documento retirado o una solicitud que exceda la tarea original. Pida al proveedor que muestre qué ocurre, dónde opera la restricción y qué registro permanece después. Luego evalúe si la tarea autorizada aún se completa. Trate la demostración como evidencia sobre esa implementación y configuración, con los límites claramente indicados. La advertencia de confianza cero de Vishal Sharma ofrece una pregunta inicial útil para esa conversación: cuando un asistente afirma que siguió las reglas, ¿qué puede verificar realmente otra persona?