Google publicó el 17 de agosto de 2026 una guía de arquitectura y prácticas, acompañada de un demostrador de código abierto, para agentes capaces de modificar un sistema de producción. Su mensaje central es claro: un prompt, incluso muy detallado, no es una frontera de seguridad. Las reglas importantes deben ser impuestas mediante código, permisos y pruebas criptográficas independientes del modelo.
1. El nuevo riesgo: el agente que escribe
Un chatbot que responde mal produce principalmente un problema de información. Un agente que modifica un precio, reembolsa un pedido, crea un usuario o cambia una configuración puede provocar un daño directo.
Los errores no provienen únicamente de una intención maliciosa. El modelo puede entender mal un contexto, llamar a la herramienta incorrecta, repetir una acción después de un retraso o seguir una instrucción inyectada en una fuente externa.
La seguridad debe, por lo tanto, centrarse en la propia capacidad de acción. El sistema objetivo no debería confiar en una solicitud simplemente porque provenga del servicio “agente”.
2. Por qué las instrucciones no son suficientes
Un prompt puede decir “nunca reembolsa más de 100 euros” o “pide una validación humana”. Estas instrucciones mejoran el comportamiento promedio, pero siguen siendo interpretadas por un modelo probabilístico.
Una inyección puede intentar eludirlas. Una actualización del modelo puede modificar la forma en que se siguen. Un error de contexto finalmente puede llevar al agente a creer que se permite una excepción.
Las reglas de seguridad deben ser escritas en un gateway determinista o en la API objetivo. El modelo propone una acción; un componente clásico decide si es admisible.
3. Primera capa: firmar cada modificación
La arquitectura de Google recomienda una clave distinta por agente, gestionada por Cloud KMS y protegida materialmente por Cloud HSM en la configuración descrita. Cada mutación del libro mayor del demostrador está firmada. Para una arquitectura de producción, recomendamos extender este principio a cada escritura hacia el sistema objetivo. La API puede entonces verificar la identidad del agente, la integridad de la solicitud y la ausencia de alteración.
La firma debe cubrir más que el cuerpo JSON. Incluya el identificador del agente, el usuario que realiza la solicitud, la acción, el recurso, el monto, la marca de tiempo, un identificador único y la política aplicada. Un nonce o identificador de idempotencia solo bloquea las repeticiones si la API recuerda los identificadores ya procesados y rechaza su reutilización.
Una clave propia de cada agente facilita la revocación. Si un servicio se ve comprometido, es posible bloquear sus escrituras sin interrumpir a todos los demás.
La firma también aporta una prueba de atribución técnica. No demuestra que la decisión fuera correcta, pero permite saber qué componente emitió la solicitud y si ésta ha sido modificada.
4. Segunda capa: ejecutar en un sandbox
Google ilustra el aislamiento con gVisor, un entorno que intercepta las llamadas al sistema en espacio de usuario. El principio general es reducir las capacidades del código generado o de las herramientas llamadas: sin acceso a la red por defecto, sistema de archivos limitado, privilegios eliminados, recursos limitados y duración máxima.
El depósito especifica que la interfaz del demostrador simula el sandbox y que la ejecución real bajo gVisor es opcional. Por lo tanto, se trata de una guía y un punto de partida para reforzar, no de la prueba de que se haya auditado una arquitectura de producción completa.
Una sandbox solo es útil si las salidas están controladas. Un agente aislado que puede escribir un archivo que luego será interpretado ciegamente por un servicio privilegiado conserva un camino de ataque.
Los datos inyectados en el entorno deben ser mínimos y temporales. Un secreto de producción no debería copiarse en el sandbox cuando la acción puede realizarse mediante una API restringida detrás de una pasarela.
5. Tercera capa: un puente semántico determinista
El pasarela verifica el sentido de la acción antes de la ejecución. Aplica reglas comprobables: monto máximo, rol del usuario, estado del pedido, frecuencia, país, presencia de una validación y coherencia de los campos.
El modelo no debe poder elegir la política por sí mismo. Proporciona una intención estructurada, idealmente conforme a un esquema. La pasarela enriquece con los datos de referencia y decide autorizar, rechazar o solicitar una aprobación.
El demostrador de Google se basa principalmente en expresiones regulares, palabras clave y un control de valor SQL. Los controles de negocio más completos propuestos aquí constituyen una recomendación de arquitectura para adaptar y probar, no una capacidad demostrada universalmente por la herramienta.
Las reglas deben ser probadas en CI como código de negocio. Un cambio de umbral o de excepción pasa por una revisión, una versión y un historial.
6. El diario de auditoría independiente
Las huellas generadas por el agente no son suficientes, ya que un componente comprometido puede modificarlas. Conserve un registro independiente en el lado del gateway o del sistema objetivo: solicitud recibida, firma, política, decisión, respuesta y estado final.
Para ir más allá del demostrador de Google, que verifica periódicamente las firmas del ledger y recomienda Cloud Logging en producción, un almacenamiento de solo adición o una cadena de hash puede reforzar la detección de alteraciones. Los registros deben seguir siendo explotables por los equipos de seguridad y de negocio sin exponer innecesariamente los datos completos.
La auditoría debe permitir reconstruir una decisión: quién la solicitó, qué contexto se utilizó, qué versión de la política se aplicó y qué acción se ejecutó efectivamente.
7. Diseñar los permisos por capacidad
Evite una cuenta técnica polivalente. Cree capacidades estrechas: leer un comando, proponer un reembolso, desencadenar un reembolso limitado o abrir una solicitud de validación.
Cada capacidad posee su esquema, sus límites y sus derechos. Un agente de soporte no debe acceder a la configuración del clúster simplemente porque ambas funciones utilizan la misma plataforma de herramientas.
Los permisos también deben tener en cuenta al usuario final. El agente no puede ampliar los derechos de la persona a la que asiste. Este principio es central para cualquier agente conectado al sistema de información.
8. Un ejemplo concreto: reembolso al cliente
Consideremos un escenario ilustrativo, diferente del demostrador de Google: el agente analiza la conversación y propone un reembolso de 42 euros para el pedido X. No posee directamente la clave de pago. Llama a una capacidad propose_refund con un esquema estricto.
La pasarela recoge el monto pagado, el estado, los reembolsos anteriores y el rol del operador. Autoriza montos inferiores a 50 euros en ciertos casos, exige una validación hasta 200 euros y rechaza los superiores.
Después de la autorización, un servicio dedicado ejecuta la operación y firma el resultado. El registro vincula la propuesta, la política y la transacción. Una repetición con el mismo identificador no crea un segundo reembolso.
9. La lista de verificación de puesta en producción
Antes de abrir un registro a un agente, verifique que la acción tenga un esquema cerrado, una política determinista, una identidad dedicada, una firma, una idempotencia y un registro independiente. Pruebe los límites, repeticiones, retrasos y datos malformados.
Luego simule los ataques: instrucción oculta en un documento, herramienta que devuelve un contenido hostil, clave revocada, marca de tiempo antigua, acción fuera de rol y intento de eludir el límite máximo.
Comience en modo de solo lectura, luego en modo de propuesta. Solo permita la ejecución automática para operaciones reversibles, de bajo impacto y suficientemente observadas.
El enfoque de confianza cero no busca hacer que el modelo sea infalible. Parte del principio de que puede equivocarse y limita lo que un error puede producir. Es esta inversión la que permite pasar de una demostración a una capacidad explotable.
Partitech acompaña la seguridad de los agentes de negocio: diseño de capacidades, pasarelas de políticas, firmas KMS, sandboxing, auditoría y pruebas de escenarios adversos.