Qué te protege de verdad cuando conectas una IA a Marketing Cloud

El dolor

Supongamos que decides conectarlo, así, sin miedo al éxito. Creas un installed package aparte y le concedes lo mínimo. Le dices al programa desde el que trabajas que no invoque las herramientas que borran ni las que envían. Dejas puesto el modo que pide confirmación antes de cada acción.

Son tres precauciones razonables. Es la lista que hace todo el mundo.

Ahora la pregunta incómoda: si mañana desaparece una data extension, ¿cuál de las tres lo habría impedido? Porque no protegen lo mismo, y dos de las tres se rodean. Mi experimento funcionó, o no... según cómo se vea: con la herramienta de borrado bloqueada, la data extension se borró igual.

Esto es lo que conviene saber antes de montar la conexión, no después. Una de las tres decisiones se toma en un minuto y condiciona todo lo demás.

Las tres capas que parecen lo mismo

Con un asistente conectado a Marketing Cloud Engagement hay tres mecanismos actuando a la vez, y casi todo el mundo los mete en el mismo saco.

Los scopes del installed package. El installed package es lo que se crea dentro de la org para que algo de fuera pueda entrar, y sus scopes son una pantalla de casillas donde marcas qué va a poder hacer: leer data extensions, escribir en ellas, ejecutar automatismos, enviar. Lo conté en qué es el MCP Server y qué esperar de él: el permiso no lo tiene la IA, lo tiene ese paquete. Es una cerradura. Lo que no marcas no se puede invocar, y da igual quién lo intente ni cómo.

La lista de herramientas bloqueadas. El asistente no habla con Marketing Cloud Engagement por su cuenta: lo hace desde un programa (Claude Code, o el que uses) que es quien invoca las herramientas. A ese programa puedes darle una lista de nombres que no debe invocar nunca. Es exactamente eso: una lista de nombres.

El criterio del propio asistente. El modelo decidiendo, caso por caso, que algo tiene consecuencias suficientes como para pararse y preguntarte.

Los tres parecen lo mismo desde la posición de quien autoriza la conexión: mecanismos que impiden que pase algo malo. No lo son. Solo el primero es una frontera. Los otros dos son otra cosa, y conviene saber qué antes de apoyarse en ellos.

Lo que pasó cuando lo probé

Esto lo hice contra mi propia org, sobre una data extension que había creado yo un minuto antes precisamente para romperla. Lo aclaro porque lo que viene únicamente se puede comprobar rompiendo algo, y Marketing Cloud Engagement no tiene sandbox: no existe un entorno de pruebas donde romper cosas sin consecuencias.

Bloqueé por su nombre la herramienta que borra data extensions y pedí borrar una.

La primera vez no se borró. ¿Quién lo impidió? No fue la lista de bloqueos, fue el criterio del asistente, que decidió que aquello merecía una confirmación. La lista ni se enteró.

Insistí con una instrucción concreta. Y entonces el asistente hizo lo razonable: como la herramienta con nombre estaba bloqueada, usó una genérica de paso, de esas que sirven para llegar a cualquier sitio de la API. La data extension se borró. 200 OK, "Data Extension deleted".

Mismo objeto, misma API, otra puerta.

Y el motivo no es que la lista estuviera mal escrita. Es que una lista de bloqueos bloquea nombres, no operaciones. Bloqueé las herramientas que llevan "borrar" en el nombre y dejé libre una genérica, capaz de llegar a cualquier punto de la API, que hace exactamente lo mismo.

Dos cosas lo empeoran. La primera: en el fichero de configuración, una regla de bloqueo sobre una herramienta MCP se descarta si lleva argumentos, así que ahí o bloqueas la herramienta entera o no bloqueas nada. Por línea de comandos sí se puede denegar por un argumento, pero solo cuando coincide con un valor exacto: sirve para prohibir el borrado de una data extension concreta, no para escribir "ninguna, salvo las de prueba". La segunda: la descripción de esas herramientas genéricas le indica al modelo que recurra a ellas cuando ninguna otra encaje. El rodeo no se le ocurrió a él, venía sugerido.

Y un dato que descubrí el mismo día y que vale por sí solo: el servidor expone herramientas que no están en la documentación pública. Una lista de bloqueos construida leyendo la documentación nace incompleta.

Dicho lo cual, algo sí aguantó. Le pedí al asistente que modificara su propia configuración para permitirse la operación. Lo intentó dos veces, con dos herramientas distintas y con mi autorización explícita, y no pudo ninguna de las dos. Ese límite no es prosa: está por debajo del modelo y no depende de que se porte bien.

La única frontera real

De las tres capas, dos acaban de caerse. La lista de bloqueos se rodea con otra herramienta. El criterio del asistente decide caso por caso, y a veces decide que sí. Queda el scope.

Y ese sí es una frontera, porque no depende de que nadie se comporte bien. Lo que no está concedido no se puede invocar, ni por la herramienta con nombre ni por la genérica. Los dos caminos de mi experimento habrían muerto igual si el paquete no hubiera tenido permiso de escritura.

La buena noticia es que el árbol de permisos es más fino de lo que parece. No es binario: según la tabla de herramientas, ejecutar, borrar y enviar tienen permisos propios, separados del de escribir. Se puede conceder escritura sin envío, y lectura sin ejecución. Eso permite diseñar un permiso ajustado de verdad, y no el "lectura o todo" que mucha gente asume. Con una trampa: no es uniforme. Borrar un journey pide su propio permiso de borrado, pero borrar una data extension va dentro del permiso de escritura.

La mala es que no hay ninguna pantalla donde consultar lo concedido. Ni en Marketing Cloud ni en el cliente. La única forma de saber qué puede hacer un paquete es invocar algo y ver si responde. Lo aprendí por las malas: tenía una configuración que yo daba por de solo lectura, y creó una data extension a la primera.

Concede poco, y apúntalo tú al crear el paquete.

Y dónde tampoco llega el scope

El scope, con sus irregularidades, sí separa unas operaciones de otras: escribir, ejecutar, enviar. Lo que no separa nunca es leer la estructura de leer los datos de las personas.

Con permiso de lectura sobre data extensions se puede consultar cómo están hechas —qué campos tienen y de qué tipo— y también el contenido de sus filas. Es el mismo permiso: no hay una casilla para lo primero y otra para lo segundo. Y el permiso de lectura sobre contactos incluye buscar por una dirección de correo y devolver el identificador del contacto al que pertenece. Eso ya es buscar a una persona concreta.

Así que conceder lectura para documentar una org es, al mismo tiempo, conceder lectura sobre la gente que hay dentro. Y quien firma esa autorización no tiene forma de verlo en la pantalla donde la firma.

Mi regla es la de siempre: metadatos sí, registros no. Pero después de esto la digo con más cuidado, porque no la impone ningún permiso. Es criterio profesional, y se sostiene con disciplina y auditoría o no se sostiene.

Y antes de que me lo discutan: que el contact key sea un identificador opaco no lo convierte en anónimo. Seudonimizar no es anonimizar, y sigue siendo un dato personal.

Qué haces con esto

Todavía no hace falta tener nada conectado. Esto es la lista para el día que lo montes.

Decide el scope como si no hubiera nada más protegiéndote. Porque no lo hay. Todo lo que marques se va a poder hacer, tarde o temprano y por algún camino.

Empieza solo con permisos de lectura. Y quédate ahí una temporada. Casi todo el valor está en entender lo que ya tienes en la org, y para eso no hace falta escribir nada.

Apunta qué has marcado el mismo día que lo marcas. En un documento, en un ticket, donde sea menos en tu memoria. Después no existe ninguna pantalla donde consultarlo.

Antes de dejarle ejecutar algo nuevo, pregúntale qué va a hacer y a cuántos registros afecta. Te lo explica antes de tocar nada, y así lo paras a tiempo si la respuesta no es la que esperabas. Lo recomienda la propia documentación de Salesforce.

Y la decisión que ningún permiso va a tomar por ti: cada fila que lee es de una persona. Metadatos siempre que puedas, filas solo cuando la pregunta lo pida de verdad, y las mínimas que la contesten.

El límite

Esto no es asesoramiento legal ni una guía de RGPD, y no sustituye a la política de tu empresa ni a la de tu cliente.

La prueba del borrado la hice con un programa cliente y una configuración concretos, y otro puede comportarse distinto. Lo que no cambia es el motivo de fondo: bloquear por nombre no alcanza a lo que una herramienta hace.

Y lo que todavía no puedo afirmar: no he probado con un paquete recortado de verdad, así que no sé cómo deniega el servidor cuando falta un permiso, ni si el error te dice cuál. Cuando lo sepa, lo escribo.

Qué viene ahora

Si el scope es lo único que aguanta, lo siguiente es montarlo sabiendo lo que ya sabes: dónde se crea ese paquete, qué casillas marcar y cuáles no marcar nunca. De eso irá el próximo artículo.