Antes de darle tu tarjeta a un agente

El artículo gratis de esta semana cuenta qué hace Muse: manda correos, reserva viajes, compra por ti. Esta pieza no repite eso. Va sobre la pregunta que viene después de probarlo — la que casi nadie se hace hasta que ya es tarde: ¿cuánto le confías, en concreto, a algo que puede gastar tu dinero y actuar en tu nombre?

No es una pregunta nueva. Cada vez que un agente de IA gana la capacidad de completar un checkout, mandar un correo o tocar un sistema real —Muse, pero también Astra de OpenAI o cualquiera que venga después—, la misma decisión se repite: ¿qué tanto acceso le doy, y bajo qué condiciones? Muse es solo el caso más reciente y mejor documentado para responderla con evidencia real, en vez de con intuición.

Y está mejor documentado porque, por primera vez, tenemos las dos caras de la moneda publicadas casi al mismo tiempo: lo que la empresa construyó para que confiaras, y lo que sus propios empleados encontraron cuando lo probaron antes de que saliera.

La arquitectura que Meta sí construyó

Vale reconocerlo con la misma seriedad con la que se cuestiona lo demás: Meta no llegó a esto con las manos vacías. Según su propio blog de investigación, Muse corre dentro de Muse Secure VM — una computadora dedicada y aislada, con su propio navegador, separada del teléfono o la laptop donde el agente se ve. Ni el agente ni sus credenciales viven en tu dispositivo.

Encima de eso corre Sentinel, un segundo agente que no es Muse y que está aislado de él a nivel de sistema. Cada acción que Muse quiere sacar hacia internet pasa primero por Sentinel, que la revisa contra tus permisos y puede aprobarla, bloquearla o mandártela a ti para que decidas. Es, en el papel, exactamente el diseño que se necesita para defender contra un ataque de inyección de instrucciones — cuando alguien esconde una orden dentro de una página o un correo para engañar al agente.

Y hay una señal de que se lo toman en serio más allá del comunicado: Meta abrió Muse a su programa de recompensas por vulnerabilidades, con hasta 300,000 dólares por una falla válida y hasta 130,000 dólares por un ataque de inyección que afecte a un solo usuario. Esas cifras no se ofrecen por algo que se cree perfecto — se ofrecen por algo que se sabe que puede fallar y que se quiere que fallar salga caro para quien lo explote.

La regla que explica por qué te pregunta antes de actuar

Meta publicó, meses antes de Muse, un principio de seguridad al que llama «Agents Rule of Two» — la regla de los dos. Dice que un agente puede tener, como máximo, dos de estas tres capacidades a la vez sin que un humano tenga que aprobar lo que hace: procesar contenido que no controla (una página web, un correo que le llegó), tener acceso a datos o cuentas sensibles, y poder actuar hacia afuera — mandar algo, pagar algo, cambiar algo. Si las tres coinciden, la regla exige un punto de aprobación humana antes de que el agente complete la acción.

Ahí está, con nombre y explicación oficial, la razón de que Muse siempre te pregunte antes de mandar un correo o cerrar una compra. Está leyendo tu bandeja o navegando una página que no controla (capacidad uno), tiene acceso a tu cuenta o tu tarjeta (capacidad dos), y la acción de mandar o pagar es, precisamente, actuar hacia afuera (capacidad tres). Las tres se juntan, así que la regla que Meta mismo escribió exige que aparezcas tú antes de que se complete.

Esto importa más allá de Muse porque es una regla que puedes aplicarle a cualquier agente que uses, sea de quien sea: si lo que le vas a pedir junta las tres capacidades —lee algo que no controla, toca algo sensible, puede actuar afuera—, exige tú mismo el punto de aprobación, exista o no en el diseño del producto. Si el agente no te lo pide, pídeselo tú: revisa antes de que la acción se complete, no después.

Lo que encontraron sus propios empleados, la misma semana

Esta es la parte que no salió en el comunicado. Según reportes de Forkast News y recogidos también por TechCrunch, empleados de Meta que probaban Muse tan tarde como la semana del lanzamiento documentaron fallas que no se hicieron públicas antes del 8 de septiembre.

Entre lo que reportaron: los candados se saltaron de forma que expusieron fotos privadas guardadas en cuentas conectadas de iCloud. El sistema cerraba la sesión de los usuarios de forma repetida, sin que lo pidieran. Hubo tramos en los que el monitoreo del propio agente se apagó solo. Y el agente se detenía por completo después de aproximadamente quince minutos de actividad, sin recuperarse — un problema que, según los mismos reportes, le pasó incluso al director de tecnología de Meta durante una sesión interna.

Nada de esto contradice la arquitectura de seguridad descrita arriba. Ahí está el punto incómodo: la arquitectura puede estar bien diseñada en el papel y, al mismo tiempo, fallar en la implementación cuando se prueba con casos reales, con prisa, con la fecha de lanzamiento ya puesta. Las dos cosas —el diseño serio y las fallas documentadas— salieron en la misma semana, de las mismas pruebas.

Por qué esto no es un caso contra Meta en particular

Sería fácil leer lo anterior como «no uses Muse» y quedarse ahí. Es la lectura equivocada. Ningún agente que gane acceso real a tus cuentas —de Meta, de OpenAI, de quien sea— va a llegar sin fallas de este tipo en sus primeras semanas. Es la naturaleza del software nuevo que actúa solo, no un defecto exclusivo de este producto.

Lo que sí cambia con este caso es que, por una vez, hay evidencia pública de las dos partes al mismo tiempo: la empresa que construye los candados y los empleados que reportan cuándo esos candados no aguantan. Eso permite algo que casi nunca se puede hacer con un lanzamiento nuevo: separar la promesa de mercadotecnia de lo que de verdad se probó, y sacar de ahí un criterio que sirva la próxima vez que salga un agente distinto pidiendo el mismo tipo de acceso.

El criterio es simple de decir y difícil de sostener: la fecha de lanzamiento de una empresa no es la fecha en la que tú tienes que confiar. Puedes probar la parte de bajo riesgo desde el primer día y dejar la parte que de verdad importa —el correo con tus clientes, la tarjeta con la que pagas todo— para cuando el producto lleve semanas, no horas, en manos de gente real.

Si es tu negocio el que conecta, no solo tú

Todo lo anterior se escribió pensando en una cuenta personal, pero la misma lógica se vuelve más pesada en cuanto la cuenta que conectas es la del negocio. Ahí el gasto que aprueba el agente no sale solo de tu bolsillo, y el correo que manda en automático no lo firma solo tu nombre — lo firma el negocio completo frente a un cliente o un proveedor.

Eso cambia una parte concreta de la plantilla de más abajo: la pregunta de qué cuentas quedan fuera ya no la contestas tú solo. Si hay un socio, un contador o alguien más con firma en esa cuenta, el tope de gasto y la lista de acciones que exigen aprobación se acuerdan entre todos antes de conectar nada — no se avisan después, cuando ya se aprobaron. Un agente que actúa mal en una cuenta compartida no es un error tuyo: es un error de todos los que tenían derecho a opinar y no opinaron a tiempo.

La evidencia en contra de este argumento

Los reportes de fallas vienen de fuentes que no son Meta. Forkast News e Implicator citan pruebas internas de empleados, no un reconocimiento público de la empresa. Es evidencia periodística seria y con más de una fuente, pero no es lo mismo que un informe oficial de Meta admitiendo cada falla puntual.

Un fallo en pruebas internas no es lo mismo que un fallo en producción.Parte de para qué sirve probar antes de lanzar es encontrar justo este tipo de problema. Que se haya encontrado no prueba que siga presente el día que tú lo uses — prueba que existía en algún punto de las semanas previas al lanzamiento.

El corte de tiempo es corto. Muse lleva días en el mercado al momento de escribir esto. No hay todavía datos de qué tan seguido fallan los candados con miles de usuarios reales, sostenidos durante meses — que es, al final, la prueba que de verdad importa.

Y el incentivo de quien escribe esto tampoco es neutral. Nuvnext vende capacitación para operar con IA con criterio, y una pieza que recomienda ir despacio con los agentes es, sin rodeos, un argumento a favor de que alguien te enseñe a hacerlo bien. Lo que acota ese sesgo es que cada cifra y cada reporte de falla que citamos aquí vienen de fuentes de terceros verificables — la propia Meta y la prensa que investigó por su cuenta —, no de una opinión nuestra sin respaldo.

Cuándo esto no te sirve

Si la cuenta es compartida, no solo tuya. Una cuenta de socios o de equipo necesita que los límites se acuerden entre todos antes de conectar nada — no que uno solo decida y avise después.

Si tu banco o tu tarjeta no te dejan fijar un tope de gasto. Resuelve eso primero. No es un problema que un agente vaya a arreglar por ti — es la condición mínima para que valga la pena intentarlo.

Si no vas a revisar lo que hizo. Un agente que actúa mientras no lo ves produce resultados que alguien tiene que mirar después. Si nadie los va a revisar, el riesgo no bajó — solo se movió a un momento en el que ya no lo estás mirando.

Qué hacer el lunes

Paso 1 (10 minutos). Revisa si la tarjeta que usarías para un agente te deja fijar un tope de gasto por transacción o por mes. Si no puedes, ese es tu primer pendiente, antes de cualquier IA.

Paso 2 (15 minutos). Llena la plantilla de arriba para UNA sola cuenta — la de menor riesgo que tengas, no la más importante.

Paso 3 (10 minutos). Antes de conectar nada, agenda en tu calendario el día en que vas a revisar qué hizo el agente. No lo dejes para «cuando te acuerdes» — justo ese hábito es el que más falla en las primeras semanas de cualquier herramienta nueva.