AWS Impone Límites Estrictos a los Agentes de IA mientras se Intensifica la Carrera de Seguridad entre Amazon y Google

AWS ha establecido límites exigibles en torno a los agentes de IA, pese al riesgo de que atacantes o datos contaminados puedan manipular su razonamiento. La medida intensifica la disputa entre Amazon y Google por determinar qué nube puede conectar de forma segura a los agentes con sistemas empresariales valiosos.

Amazon Bedrock AgentCore Policy verifica las acciones de herramientas solicitadas por un agente antes de que lleguen al servicio subyacente. Un agente manipulado aún puede generar una solicitud peligrosa, pero esta debería fallar cuando entre en conflicto con una política externa.

Esta distinción importa porque los filtros de prompts nunca han proporcionado un perímetro de seguridad completo. Los modelos procesan instrucciones y datos no confiables mediante el mismo mecanismo probabilístico. AWS ahora trata al modelo como un responsable de decisiones no confiable, en lugar de como la autoridad final.

Google Cloud y Microsoft siguen la misma dirección general mediante sus propios controles de identidad, gateways y flujo de información. La competencia emergente ya no se limita a la calidad de los modelos. Los proveedores de nube deben demostrar que los agentes pueden actuar sin heredar acceso ilimitado a todos los sistemas conectados.

AWS Traslada la Autorización Fuera del Agente

AWS está separando lo que un agente quiere hacer de lo que la infraestructura le permite hacer.

La política de Amazon Bedrock AgentCore crea una barrera de protección alrededor de las interacciones entre agentes y herramientas. El servicio intercepta las solicitudes enrutadas a través de un AgentCore Gateway y evalúa cada solicitud antes de permitir la invocación de la herramienta.

Un AgentCore Gateway conecta agentes con APIs, funciones y otras herramientas a través de una interfaz administrada. El motor de políticas se sitúa junto a esa conexión, en lugar de dentro del prompt o del código de orquestación del agente.

Esta ubicación cambia el modelo de seguridad. Un prompt de sistema puede indicar a un agente que nunca recupere registros restringidos de clientes. Sin embargo, la inyección de prompts puede persuadir al modelo para que ignore esa instrucción o la interprete de otra manera.

Un motor de autorización externo no necesita que el modelo esté de acuerdo. Evalúa la acción propuesta mediante reglas explícitas, identidad autenticada, parámetros de herramientas y el contexto de solicitud disponible.

AWS utiliza Cedar, su lenguaje de autorización de código abierto, para expresar esas reglas. Una política de Cedar identifica al principal que realiza una solicitud, la acción solicitada, el recurso protegido y las condiciones requeridas.

El servicio sigue una semántica de denegación predeterminada. Una acción no recibe acceso salvo que una política lo permita explícitamente. Una prohibición coincidente también prevalece sobre cualquier permiso más amplio que, de otro modo, permitiría la solicitud.

AWS explica estos mecanismos en su guía de políticas de AgentCore. La guía indica que cada solicitud de agente enrutada se evalúa antes de conceder acceso a las herramientas.

Los desarrolladores pueden escribir Cedar directamente o describir los requisitos en inglés sencillo. El servicio de creación en lenguaje natural traduce esos requisitos en políticas candidatas de Cedar.

AWS afirma que el servicio valida las políticas generadas frente al esquema de herramientas del gateway. También comprueba si hay reglas que parecen excesivamente permisivas, excesivamente restrictivas o imposibles de cumplir.

Ese proceso de generación no hace seguros los requisitos vagos. AWS advierte que las políticas en lenguaje natural aún necesitan una redacción precisa e inequívoca. Los equipos de seguridad deben revisar el Cedar resultante en lugar de tratar la política generada como código incuestionable.

El modelo que crea una política también es independiente del mecanismo que la aplica. Una vez desplegada, la política formal controla la decisión de autorización en lugar de pedirle opinión a otro modelo.

Pensemos en un agente interno de soporte con herramientas para leer cuentas y emitir reembolsos. Una empresa podría permitir que cada representante de soporte lea las cuentas asignadas, mientras que solo los supervisores pueden aprobar reembolsos mayores.

Si un correo electrónico contiene instrucciones maliciosas que exigen un reembolso, el agente podría intentar la operación. El gateway aún puede rechazarla cuando el empleado autenticado carece del rol requerido o la cantidad supera lo establecido por la política.

La solicitud denegada nunca necesita llegar al sistema de pagos. Ese resultado es más sólido que pedir al agente que reconozca cada variación de una instrucción maliciosa.

AgentCore Policy está disponible de forma general en 13 regiones de AWS, según la documentación de lanzamientos de AWS. Las políticas centralizadas pueden aplicarse de forma coherente a múltiples agentes y herramientas conectados a través de gateways asociados.

La integración con CloudWatch registra las decisiones de autorización para fines de supervisión y auditoría. Esos registros proporcionan a los equipos de seguridad una visión más clara de las acciones que los agentes solicitaron, permitieron o denegaron.

Por tanto, el cambio inmediato es arquitectónico, no cosmético. AWS está situando un punto de control determinista entre el comportamiento incierto del modelo y los sistemas empresariales con consecuencias relevantes.

Por Qué la Inyección de Prompts Cambia la Competencia entre Amazon y Google

La competencia en la nube entre Amazon y Google depende ahora de contener a los agentes comprometidos, no solo de mejorar sus respuestas.

Los agentes de IA resultan útiles cuando pueden recuperar información privada, llamar APIs, enviar mensajes o modificar registros. Esos mismos permisos determinan el daño posible tras una manipulación.

La inyección de prompts introduce instrucciones hostiles en el contenido que procesa un modelo. La inyección directa procede de una solicitud de usuario, mientras que la indirecta puede ocultarse en sitios web, documentos, correos electrónicos o respuestas de herramientas.

Un agente que investiga a un proveedor podría encontrar instrucciones incrustadas en una página web. Esas instrucciones podrían indicarle que recupere archivos confidenciales y los envíe mediante otra herramienta conectada.

Un filtro de contenido podría detectar un patrón de ataque conocido. También podría pasar por alto una formulación inusual, un comando codificado o una secuencia distribuida a lo largo de varias interacciones.

El problema subyacente va más allá de los prompts maliciosos. Un modelo puede alucinar una acción, malinterpretar una regla empresarial o combinar herramientas aceptables por separado en un flujo de trabajo inaceptable.

OWASP describe esta condición como agencia excesiva. El riesgo aparece cuando un LLM recibe suficiente funcionalidad o permisos como para causar efectos dañinos tras una salida inesperada.

La autorización limita el radio de impacto resultante. El sistema asume que un agente acabará tomando una mala decisión y luego evita que esa decisión se convierta en una acción sin restricciones.

Este enfoque se asemeja a prácticas consolidadas de seguridad en la nube. Las aplicaciones deberían recibir únicamente los permisos necesarios para una tarea, mientras que las operaciones sensibles deberían enfrentar comprobaciones adicionales.

Los agentes complican este principio porque seleccionan herramientas de forma dinámica. También pueden encadenar numerosas llamadas, mantener contexto entre pasos y operar durante periodos más largos sin supervisión directa.

Por ello, una cuenta de servicio estática con permisos amplios puede convertirse en una responsabilidad grave. El agente adquiere de hecho todas las capacidades vinculadas a esa credencial, independientemente del usuario o de la tarea involucrada.

AWS puede vincular las solicitudes de AgentCore con usuarios de OAuth o entidades de AWS Identity and Access Management. Las políticas pueden entonces considerar la identidad detrás de una solicitud, en lugar de depender únicamente del rol de servicio compartido del agente.

Google afronta el mismo problema a medida que amplía los agentes basados en Gemini y las conexiones de Model Context Protocol. MCP es una interfaz estándar que permite a los modelos descubrir e invocar herramientas externas.

La guía de seguridad de MCP de Google recomienda políticas de denegación para el acceso a producción, permisos de alcance limitado, saneamiento de entradas y supervisión. También advierte que, de otro modo, la seguridad puede depender por completo de la programación del agente.

Esta convergencia es importante. La competencia entre Amazon y Google a menudo se ha centrado en la disponibilidad de modelos, la infraestructura, las plataformas de datos y las herramientas para desarrolladores. La autorización de agentes se está convirtiendo en otro criterio de compra importante.

Los clientes empresariales rara vez despliegan un agente como un chatbot aislado. Quieren agentes conectados a bases de datos, repositorios de código, plataformas de soporte, consolas de nube y repositorios internos de conocimiento.

Cada conexión crea tanto utilidad como exposición. Un proveedor de nube que facilita la conexión pero ofrece una autorización débil traslada el riesgo operativo de vuelta al cliente.

AWS está posicionando AgentCore Policy como una capa de aplicación reutilizable entre frameworks y modelos. Los desarrolladores pueden usar AgentCore con agentes creados mediante varios frameworks de orquestación populares.

Esta apertura permite a AWS sostener que la política de seguridad debe mantenerse estable incluso cuando una empresa cambia de modelo. Una organización podría sustituir un modelo fundacional sin reescribir cada regla de permisos.

Google puede defender un argumento similar mediante sus controles de identidad en la nube, Model Armor y permisos a nivel de recurso. Su ventaja reside en la proximidad a Google Workspace, Gemini y una amplia plataforma de datos.

Microsoft añade presión mediante la identidad de Entra, Copilot y su pila de desarrollo de agentes. El mercado se está convirtiendo en una competencia a tres bandas sobre quién controla el límite entre el razonamiento de IA y la ejecución empresarial.

Para los compradores, la pregunta relevante sobre Amazon y Google no es qué modelo siempre rechaza un prompt malicioso. Ningún proveedor puede prometer de forma creíble un rechazo perfecto ante cada combinación de entrada y herramientas.

La mejor pregunta es qué sucede después de que el rechazo falla. Una plataforma segura debería limitar las herramientas, los registros, los parámetros, los destinos y las secuencias de acciones disponibles para el agente comprometido.

Las Estrategias de Seguridad de Amazon y Google Convergen en el Límite de las Herramientas

AWS, Google y Microsoft convergen en la aplicación determinista, pero organizan esa aplicación de forma diferente.

AWS sitúa AgentCore Policy directamente en la ruta del gateway. Cada solicitud cubierta de agente a herramienta llega al motor de políticas antes de que continúe la invocación solicitada.

Cedar proporciona a AWS un lenguaje formal que los equipos pueden inspeccionar, validar y analizar. AWS ha utilizado conceptos de Cedar más allá de los agentes, lo que ayuda a conectar la autorización de agentes con prácticas consolidadas de seguridad de aplicaciones.

Los investigadores de seguridad de la compañía parten de una suposición contundente sobre el propio modelo. Su análisis de seguridad de Cedar indica que las organizaciones deberían tratar un LLM como un actor no confiable dentro de un diseño de defensa en profundidad.

Eso no significa que el modelo sea malicioso. Significa que el sistema de autorización no puede depender de un comportamiento predecible del modelo, porque el modelo es probabilístico y susceptible al contexto manipulado.

La guía publicada de Google actualmente hace hincapié en controles por capas alrededor de los servidores MCP y los recursos de Google Cloud. Esos controles incluyen políticas de denegación, credenciales con alcance limitado, entornos de prueba separados, entradas saneadas y acceso restringido a producción.

Google también recomienda impedir que las herramientas de lectura y escritura alcancen recursos de producción salvo que el flujo de trabajo lo requiera. Las funciones de recuperación siguen siendo importantes porque incluso una acción autorizada puede producir un resultado no deseado.

La diferencia práctica puede aparecer en la experiencia de desarrollo. AWS ofrece un motor de políticas AgentCore dedicado con evaluación respaldada por Cedar en su gateway administrado.

Google puede apoyarse en Cloud IAM maduro y en políticas específicas de cada producto. Sin embargo, los desarrolladores aún deben garantizar que cada ruta de herramienta relevante realmente pase por el control previsto.

Esa salvedad también se aplica a AWS. AgentCore Policy rige el tráfico canalizado a través de un AgentCore Gateway asociado. Un agente con otra ruta de ejecución podría eludir ese punto de control concreto.

Por ejemplo, una política podría bloquear una operación de S3 realizada mediante una herramienta MCP gestionada. La restricción no cubriría automáticamente una herramienta de shell independiente que pueda emitir un comando equivalente.

Por tanto, las revisiones de arquitectura deben enumerar capacidades, no solo herramientas con nombre. Los equipos de seguridad deben preguntarse si un agente puede acceder al mismo recurso mediante un SDK, línea de comandos, navegador, función o agente secundario.

Microsoft está desarrollando otra variante mediante control del flujo de información. Su middleware FIDES etiqueta el contenido según su integridad y confidencialidad, y luego conserva esas etiquetas a través de las llamadas a herramientas.

El modelo de seguridad FIDES de Microsoft puede impedir que contenido no confiable influya en una operación sensible. También puede restringir que datos privados fluyan hacia un destino público.

Este enfoque aborda una debilidad de la autorización de acciones individuales. Una consulta a una base de datos puede estar permitida, y también puede estarlo el envío de un correo electrónico. El comportamiento peligroso aparece cuando los resultados privados de la consulta fluyen hacia un correo externo.

AWS ha estado ampliando sus políticas hacia una evaluación consciente de la sesión. Los controles temporales pueden examinar las acciones recientes de un agente en lugar de juzgar cada solicitud como un evento aislado.

Esta dirección importa porque los atacantes pueden dividir un objetivo dañino en varios pasos de apariencia legítima. Una secuencia puede revelar un riesgo que ninguna acción individual expone.

Un agente podría primero leer una cartera confidencial, luego calcular un resumen y, por último, intentar una transmisión externa. Cada llamada a una herramienta puede parecer válida sin la trayectoria que las conecta.

Para los clientes que comparan los diseños de seguridad de Amazon y Google, la cobertura importa más que la terminología. Un lenguaje formal de políticas ofrece poca protección cuando las rutas de ejecución de alto riesgo quedan fuera de la aplicación de controles.

La propagación de identidad también importa. El motor de políticas necesita información fiable sobre el usuario, la carga de trabajo, el recurso, la acción y el contexto empresarial pertinente.

Una identidad genérica de «agente» es insuficiente cuando el agente atiende a muchos empleados. Puede conceder a cada usuario el conjunto máximo de permisos del agente y eliminar la rendición de cuentas que proporcionan los controles de acceso normales.

Las organizaciones deben conservar la identidad humana o de carga de trabajo detrás de cada solicitud delegada. También deben asignar al agente su propia identidad restringida en lugar de ocultarlo dentro de una credencial compartida.

Esta separación ayuda a responder dos preguntas distintas. La primera pregunta si el usuario puede solicitar la acción. La segunda pregunta si este agente puede realizar esa acción mediante esta herramienta específica.

La política centralizada también reduce las inconsistencias entre equipos. Sin ella, cada desarrollador puede implementar la autorización dentro de prompts, middleware personalizado o controladores individuales de herramientas.

Esas comprobaciones dispersas se vuelven difíciles de auditar. También se desvían a medida que los agentes adquieren nuevas herramientas, modelos y ramas de flujo de trabajo.

Una puerta de enlace compartida no puede sustituir todos los permisos a nivel de recurso. Puede proporcionar un punto coherente donde las organizaciones aplican políticas antes de que la intención del agente alcance los servicios posteriores.

La política solo es tan sólida como su cobertura

AgentCore Policy reduce el riesgo, pero no demuestra que un agente alojado en AWS sea seguro.

El servicio controla las solicitudes que pasan por su puerta de enlace y motor de políticas configurados. No puede regir las herramientas, credenciales ni rutas de red que los desarrolladores dejen fuera de ese límite.

Esto crea un problema de cobertura. Un equipo de seguridad podría creer que ha bloqueado una acción peligrosa mientras una herramienta alternativa ofrece otra ruta hacia el mismo recurso.

Los permisos amplios de IAM pueden agravar esa brecha. Si el rol de tiempo de ejecución de un agente puede llamar a servicios directamente, las restricciones de la puerta de enlace deben combinarse con políticas de recursos que bloqueen rutas no autorizadas.

El diseño de políticas también sigue siendo difícil. La creación en lenguaje natural reduce la barrera sintáctica, pero no resuelve requisitos empresariales vagos ni supuestos de seguridad ausentes.

«Permitir que los analistas vean informes apropiados» no es una regla de autorización precisa. La organización debe definir qué analistas, informes, clasificaciones, regiones, clientes y condiciones operativas se consideran apropiados.

El Cedar generado requiere revisión, pruebas y control de cambios. Los equipos deben probar las aprobaciones esperadas, las denegaciones esperadas, las solicitudes malformadas, el contexto ausente y las combinaciones de parámetros deliberadamente adversarias.

Una política que lo deniega todo provoca un fallo operativo. Una regla que permite silenciosamente todo crea el problema contrario. Ambos resultados pueden parecer sintácticamente válidos.

Los desarrolladores también deben considerar el contexto de autorización proporcionado por el agente. Los atributos sensibles para la seguridad deben proceder de tokens de identidad confiables, metadatos de recursos o infraestructura controlada.

No se debe permitir que el modelo declare que una transacción es de bajo riesgo o que un documento es público. Esas afirmaciones necesitan verificación fuera del proceso de razonamiento del modelo.

Los registros de auditoría introducen otra obligación. Registrar cada decisión ayuda a las investigaciones, pero los equipos deben supervisar activamente los registros y conservar un contexto útil.

Una acción denegada puede indicar un control de seguridad eficaz. Las denegaciones repetidas también pueden revelar un flujo de trabajo comprometido, un error de política o un agente que intenta continuamente un objetivo prohibido.

Las acciones permitidas también merecen atención. Un atacante puede abusar de permisos que son legítimos de forma individual, especialmente cuando las políticas no consideran el historial de la sesión ni el movimiento de datos.

La aprobación humana sigue siendo útil para operaciones irreversibles o de gran impacto. Sin embargo, una pantalla de aprobación puede fallar cuando el agente proporciona una descripción engañosa de la acción solicitada.

La interfaz debe presentar detalles confiables de la solicitud real de la herramienta. Los revisores necesitan el destino, recurso, parámetros, clasificación de datos y efecto esperado.

Los equipos de seguridad también deben defender el plano de administración de políticas. Un agente no debería poder editar sus propias reglas, asociar un motor de políticas más débil ni obtener credenciales con acceso más amplio.

La separación de funciones ayuda en este caso. Los desarrolladores pueden proponer cambios de políticas, mientras los responsables de seguridad revisan y despliegan los cambios mediante flujos de trabajo controlados.

La misma disciplina se aplica a los sistemas internos de conocimiento. Los equipos que crean una base de conocimiento consultable deben conservar los permisos de los documentos antes de exponer ese contenido a un agente.

La recuperación debe filtrar los registros conforme a la autorización del usuario solicitante. El modelo debe recibir únicamente el subconjunto de información al que el usuario podría acceder directamente.

Este diseño evita un modo de fallo crítico. Incluso un modelo manipulado con éxito no puede revelar información que nunca entró en su contexto accesible.

Las organizaciones deben evitar depositar toda su confianza en la detección de inyección de prompts. La detección aporta una defensa útil, pero ataques desconocidos e instrucciones de apariencia benigna pueden eludir los clasificadores.

AWS admite Bedrock Guardrails en la capa de políticas para evaluar entradas y salidas de la puerta de enlace. Esta función complementa la aplicación de Cedar en lugar de sustituirla.

La diferencia es directa. Una barrera de protección estima si un contenido parece peligroso, mientras la autorización decide si una operación solicitada está permitida.

La detección probabilística y la aplicación determinista resuelven problemas distintos. Combinarlas reduce la superficie de ataque sin pretender que ninguna capa detecta todos los fallos.

La carrera de seguridad entre Amazon y Google recompensará a los proveedores que hagan difícil eludir estas capas. Las afirmaciones de marketing sobre agentes seguros importan menos que una cobertura de aplicación demostrable.

Los clientes deben poner a prueba esas afirmaciones con ejercicios de red team que incluyan inyección indirecta, herramientas comprometidas, rutas de ejecución alternativas y movimiento de datos en varios pasos.

También deben verificar el comportamiento ante fallos. Una llamada a herramienta denegada debe detener la operación protegida sin exponer detalles sensibles mediante errores o rutas alternativas.

AWS ha establecido un patrón predeterminado más sólido al situar la política fuera del código del agente. La pregunta restante es si los clientes configurarán las identidades y rutas circundantes con el mismo cuidado.

En qué deberían fijarse los compradores empresariales a continuación

La próxima fase pondrá a prueba la cobertura de las políticas, la conciencia de sesión y la portabilidad entre plataformas de agentes competidoras.

La primera señal es la rapidez con que los clientes adopten políticas temporales. Las reglas de solicitud única funcionan bien para restricciones claras, pero muchos ataques contra agentes surgen mediante secuencias de acciones autorizadas.

La evaluación temporal puede detectar que un agente leyó datos sensibles antes de intentar una transferencia externa. También puede exigir una aprobación adicional después de una secuencia particular de operaciones.

La parte difícil implica el estado y la interpretación. Los sistemas deben rastrear suficiente historial para reconocer trayectorias peligrosas sin bloquear flujos de trabajo normales ni añadir una latencia excesiva.

Los compradores deben buscar documentación técnica pública que describa exactamente cuánto historial de sesión se evalúa. También deben preguntar cómo se aísla el estado entre usuarios, agentes y tareas simultáneas.

La segunda señal es cómo Google y Microsoft exponen controles equivalentes mediante sus plataformas de agentes gestionados. Los tres proveedores reconocen que las instrucciones de los prompts por sí solas no pueden proteger sistemas conectados.

La respuesta de Google importará porque los agentes Gemini pueden estar cerca del contenido de Workspace, los datos en la nube y la infraestructura de desarrollo. Ya existen permisos sólidos a nivel de recurso, pero la composición específica para agentes sigue siendo esencial.

Microsoft puede combinar la identidad de Entra con Copilot, Agent Framework y etiquetas de flujo de información. Su ventaja dependerá de una aplicación coherente en las herramientas de Microsoft y de terceros.

La comparación entre Amazon y Google debe centrarse en las rutas de extremo a extremo. Los compradores necesitan pruebas de que la política acompaña una acción desde la identidad del usuario, pasando por el razonamiento del agente y la ejecución de la puerta de enlace, hasta el acceso final al recurso.

La tercera señal son las pruebas de seguridad independientes. La documentación de los proveedores describe el comportamiento previsto, mientras los red teams revelan rutas ausentes, identidades confundidas, valores predeterminados inseguros y combinaciones inesperadas de herramientas.

Las pruebas deben incluir una página web maliciosa, un ticket de soporte envenenado, una respuesta MCP comprometida y un documento hostil dentro de un repositorio aprobado. Cada fuente puede transportar instrucciones indirectas al contexto de un agente.

Los investigadores también deben probar si los agentes pueden transformar solicitudes prohibidas en acciones técnicamente diferentes. Una exportación bloqueada podría convertirse en una carga desde el navegador, un comando de shell, un mensaje codificado o una solicitud a otro agente.

Los resultados determinarán si la política externa produce una contención significativa o solo otra capa de configuración. La evidencia más sólida procederá de ataques que cambien el comportamiento del modelo pero aun así no logren cruzar los límites de autorización.

Las empresas no necesitan esperar esos resultados para mejorar su arquitectura. Pueden empezar por inventariar cada agente, herramienta, credencial, fuente de datos y destino de salida.

Cada herramienta debe recibir el ámbito de acción más restringido posible. El acceso de solo lectura debe mantenerse separado de la modificación, eliminación, compartición externa o ejecución financiera.

Los equipos deben eliminar las credenciales permanentes cuando pueda funcionar la delegación de corta duración. Deben conservar la identidad del usuario a través de las llamadas a herramientas y registrar tanto las operaciones intentadas como las completadas.

Las acciones de alto impacto deben requerir un contexto de aprobación confiable. Los equipos de seguridad deben probar regularmente rutas alternativas hacia recursos protegidos, en lugar de validar únicamente la ruta prevista de la puerta de enlace.

Para la decisión sobre Amazon Google Cloud, los benchmarks de modelos ya no son suficientes. Los compradores deberían comparar el comportamiento de denegación por defecto, la propagación de identidad, el análisis de políticas, el nivel de detalle de las auditorías, los controles de sesión y la cobertura de aplicación.

También deberían preguntarse cómo sobreviven las políticas a los cambios de modelo y framework. La autorización estrechamente ligada a una implementación concreta de agentes se vuelve costosa de mantener y más fácil de eludir durante las migraciones.

AWS ha hecho una apuesta arquitectónica clara. Parte de que el razonamiento de los agentes seguirá siendo manipulable y, después, limita las consecuencias mediante controles deterministas externos al agente.

Esa premisa es más creíble que prometer una obediencia perfecta del modelo. Acepta que se producirán errores y ataques, al tiempo que mantiene una autoridad independiente sobre las herramientas y los datos.

El enfoque sigue dependiendo de una configuración rigurosa. Una política de gateway restrictiva no puede compensar un entorno de ejecución con privilegios excesivos, una shell sin gestionar o datos recuperados antes del filtrado de autorización.

Los equipos empresariales deberían probar ahora un flujo de trabajo concreto de principio a fin. Manipulen al agente, observen las acciones que solicita y confirmen que las operaciones protegidas fallan en un límite externo.

Esa prueba proporciona un estándar práctico para Amazon Google y cualquier otra plataforma de agentes: el modelo puede ser engañado, pero la infraestructura debe seguir diciendo no.