El 26 de octubre, The Washington Post publicó que Cathedral, una startup de ciberseguridad, dice que sus agentes de IA llegaron a sistemas internos de Anthropic en menos de 12 horas. Lo que más me importa del caso es por dónde no entraron.

Según Anthropic, los investigadores pasaron varios días intentando entrar a su software directamente y no pudieron. Cuando cambiaron a software de terceros, el camino apareció. El núcleo, la parte donde una empresa como Anthropic gasta más, aguantó. El software de negocio que compra a proveedores no.

Si diriges tecnología, la tesis para ti es esta: lo que decide cuánto daño hace un proveedor vulnerable es lo que esa herramienta puede leer y hacer dentro de tu empresa, y casi nadie lo tiene escrito en un solo lugar.

Qué se sabe y qué no

Lo que está reportado, con la fuente. Cathedral dice, en un borrador de informe que revisó The Washington Post, que sus agentes encontraron caminos en menos de 12 horas. Gizmodo recoge la versión de Anthropic: acceso a un conjunto limitado de sistemas de ventas, RR. HH. y TI, con datos de contacto de clientes y socios y registros básicos de cuentas. Sin acceso a conversaciones de Claude, código fuente ni pesos de modelos.

Hay disputa. Cathedral habla de transcripciones de reuniones, salarios, ofertas de empleo y mensajes de Slack; Decrypt lo atribuye al borrador del informe. Anthropic dice que Cathedral no reveló toda su actividad dentro del programa de recompensas por vulnerabilidades (bug bounty) y exageró las implicaciones de seguridad nacional. The Decoder reporta que Anthropic desactivó el software afectado hasta que los proveedores confirmaron las correcciones.

Dos límites que conviene decir en voz alta. El informe de Cathedral no es público; todo lo que sé viene de la prensa que lo vio. Y los proveedores no tienen nombre, así que nadie sabe si el camino fue un permiso OAuth, un token de API o una función de IA dentro del producto. Lo que sigue es qué hacer con la categoría del problema, no una reconstrucción del ataque.

El llavero del conserje

Un conserje carga una llave por puerta. Cada servicio nuevo que contratas le suma una. Cambias la cerradura de la entrada cada año y nadie ha contado cuántas puertas abre el llavero.

Tus herramientas compradas funcionan igual. Un CRM, un sistema de nómina, un asistente de reuniones, un bot de Slack: cada uno entró con una credencial, y esa credencial abre cosas. Si quieres saber cuánto pesa un proveedor vulnerable, necesitas una ficha de una página por herramienta con seis campos:

Campo	Qué anotas
Lee	Qué datos puede ver (correo, calendario, nómina, transcripciones, archivos)
Hace	Qué puede ejecutar por un usuario (enviar, borrar, crear, aprobar)
Entra con	Permisos OAuth (scopes), token de API o cuenta de servicio, y dónde vive esa llave
IA adentro	Qué funciones de IA tiene activas y sobre qué datos
Dueño	Una persona con nombre, no un área
Revisado	Fecha de la última revisión de todo lo anterior

Nada de esto es nuevo. Lo incómodo es llenarla: la herramienta la conectó alguien, y puede que esa persona ya no esté en el puesto.

La IA que viene adentro del SaaS

Aquí es donde la ficha de hace dos años queda corta. Muchas herramientas de negocio le agregaron asistentes: resumen de reuniones, búsqueda sobre todo lo que la herramienta guarda, redacción de correos, acciones en nombre del usuario.

Una función así necesita leer más de lo que leía el producto antes. Si alguien compromete la herramienta, compromete también lo que ese asistente puede ver. Y a veces se activa con un clic de un empleado, sin pasar por TI.

Tres preguntas para cada proveedor con IA integrada. ¿Qué datos indexa? ¿Con qué permisos corre, los del usuario o los de una cuenta propia con más alcance? ¿Quién en tu empresa puede encenderla? Si no sabes responder las tres, esa herramienta ya tiene una línea en blanco en tu ficha.

Esto es distinto de lo que dice el contrato, que es lo que cubrí en el post sobre el fondo de beneficio público de Anthropic. Un contrato dice qué promete el proveedor. La ficha dice qué puede hacer su llave dentro de tu casa.

Quién lo revisa, y cada cuánto

Cathedral habla de menos de 12 horas. Una revisión anual de accesos de terceros tarda 8.760 horas en volver a pasar, unas 730 veces más. Mi criterio, sin fuente más allá de la aritmética: trimestral para lo que toca datos de personas, clientes o dinero, e inmediata cuando alguien conecta una herramienta nueva o prende una función de IA.

Y un nombre al lado de cada ficha. Una revisión que es de “TI y seguridad” no es de nadie. En abril escribí sobre el caso de Vercel y Context.ai, y el consejo de ahí sigue vigente: audita los permisos concedidos y revoca lo que no se usa. Este caso agrega que la lista tiene que cubrir también tokens de API y funciones de IA, y que alguien responde por ella. El mismo criterio aplica a lo que tus desarrolladores instalan, como explico en el post sobre skills de IA.

Dónde entra IQ Source

El discovery de AI Maestro parte de mirar cómo trabaja tu equipo de verdad, tarea por tarea, y eso produce el Mapa de Realidad de Procesos. Si al mapear cada tarea se anota también la herramienta que toca, ese mapa se vuelve el lugar natural para escribir los seis campos de la ficha: no hace falta un proyecto aparte, porque quien mapea la tarea ve qué sistema toca, con qué datos y con qué credencial.

También sirve para el otro lado. Si una herramienta tiene acceso a nómina y nadie la usa para nada que el mapa muestre, la recomendación es revocar, no seguir pagando por la comodidad.

Si quieres probarlo con tu lista, empieza con las diez herramientas que más datos de personas y clientes tocan. Llena la ficha de cada una y mira cuántas casillas quedan en blanco. Escríbenos y revisamos juntos la primera.