Toda plataforma dice tomarse la seguridad en serio. Nadie lo dice tampoco en el post-mortem de una brecha de seguridad; ahí es cuando finalmente describen la arquitectura en lugar de los adjetivos. Así que vayamos directo a la arquitectura. La forma más simple de explicar el aislamiento entre clientes es recorrer las tres maneras en que los equipos suelen equivocarse, y qué se rompe cuando lo hacen.
Error uno: filtrar por ID de cliente en el código de la aplicación
Esto es lo predeterminado porque es lo obvio de escribir: cada consulta recibe una cláusula WHERE user_id = ? y, mientras cada desarrollador la recuerde, cada solicitud se mantiene dentro de sus propios límites. El desastre aparece después, cuando el código base tiene cuatrocientos endpoints en lugar de cuatro. Alguien agrega una consulta de reportes que une dos tablas y olvida el filtro en la segunda. Otra persona construye una herramienta de administración "solo para uso interno" que consulta sin ninguna limitación por cliente, porque en su momento pareció seguro. Ninguno de los dos errores activa una prueba, porque la consulta sigue devolviendo filas válidas, solo que del cliente equivocado.
No dependemos de que cada consulta recuerde preguntar educadamente. La seguridad a nivel de fila se aplica en la capa de base de datos, de modo que la propia base de datos se niega a devolver filas de otro cliente sin importar lo que haya pedido el código que la invoca. Tampoco hay un acceso privilegiado que evite esto en la ruta de la solicitud: la política se aplica siempre, incluso en las rutas que tentaría tratar como confiables.
Error dos: tratar el sandbox como una optimización, no como un límite
Aquí los agentes ejecutan código real —ese es todo el sentido del producto— y el atajo tentador es ejecutar ese código en algún lugar conveniente y asegurarlo "cuando tengamos tiempo". El desastre en esta versión se ve como una dependencia comprometida incorporada durante una construcción que se conecta a internet abierto, o la ejecución de un agente de un cliente leyendo archivos que pertenecen a un espacio de trabajo que nunca debió ver, porque el sistema de archivos se compartía por defecto y se restringía por excepción.
Las cargas de trabajo de los agentes se ejecutan en entornos aislados:
- Sistemas de archivos bloqueados.
- Salida de red que funciona como lista de permitidos, no como puerta abierta.
Un agente trabajando en tu construcción ve tu espacio de trabajo, y punto. El código no confiable —incluidas las construcciones de tu propia app— se compila dentro de contenedores donde el aislamiento es estructural, no una configuración que alguien recordó activar.
Error tres: entregarle las credenciales al agente
Este es el más sutil, y el que sospecho sorprende a más equipos desprevenidos. Si el agente necesita desplegar en tu servidor o publicar en tu tienda, el camino más corto es poner el token OAuth o la clave SSH en su contexto y dejar que las use. También es el camino más corto al desastre: una instrucción inyectada mediante prompt, una acción alucinada, una credencial que termina en el registro de una transcripción en algún lugar donde no debería estar. El agente no tiene que ser malicioso para que esto salga mal; solo tiene que equivocarse una vez, con claves reales en mano.
Así que el agente nunca tiene las claves. Las credenciales conectadas se almacenan limitadas a tu cuenta y se usan solo para la acción para la que las conectaste:
- Cuentas de tienda
- Tokens OAuth de redes sociales
- Claves de despliegue
- Cuentas de servicio de Google
Cuando un agente necesita desplegar o subir algo, le pide a la plataforma que lo haga; la plataforma retiene la credencial y ejecuta la acción. El agente nunca ve el secreto que está pidiendo usar. Y del lado de analítica, donde las propiedades de Google a veces se comparten entre sitios, cada consulta de GA4 se filtra por nombre de host, de modo que tu panel no pueda mostrar accidentalmente los números de alguien más aunque la propiedad subyacente recopile datos de muchos dominios.
Qué se verifica realmente antes de publicar algo
Dos reglas aplican en toda esta plataforma, y son las que más importan aquí:
- Los agentes no pueden gastar tu dinero.
- Los agentes no pueden publicar en tu nombre.
Ambas cosas requieren tu clic. Eso significa que el peor día posible de cualquier componente automatizado sigue sin tocar tu billetera ni tu reputación: el radio de impacto está limitado por diseño, no por el buen juicio del agente. Los detalles completos sobre retención y eliminación están en la Política de Privacidad; las solicitudes de eliminación se hacen efectivas dentro de 30 días.
