Qué puede tocar (y qué no) un agente de IA conectado por MCP

Publicado el 16 de septiembre de 2026

Todos los CMPs de este segmento están añadiendo MCP este año. La pregunta que casi nadie contesta en su marketing es qué puede hacer exactamente ese agente una vez conectado: qué lee, qué puede cambiar y qué queda fuera de alcance por diseño.

MCP se ha convertido en la casilla que todos los CMPs quieren marcar este año. CookieYes lo lanzó primero en este segmento. Cookiebot tiene su "MCP Manager". OneTrust lo menciona en su portal de desarrolladores. Ketch describe sus APIs como "estilo MCP" en su web. Dentro de poco tener un conector MCP dejará de ser una diferencia y pasará a ser la base mínima esperada.

La pregunta que de verdad importa no es si un CMP tiene MCP. Es qué puede tocar ese conector una vez que Claude, o cualquier otro agente, está conectado a tu organización. Esa pregunta casi nunca se contesta en el marketing, porque la respuesta suele vivir en un documento técnico que nadie enlaza desde la landing.

Lo primero: a qué organización está ligado

Un token de acceso MCP de Tripticonsent queda criptográficamente firmado para una sola organización: la que elijas en la pantalla de autorización. Una llamada contra cualquier otra organización recibe 403, sin excepción, aunque la misma cuenta de Claude pertenezca también a esa segunda organización. No es una comprobación a nivel de aplicación que se pueda saltar con un parámetro distinto. El token en sí no sirve para nada fuera de esa organización.

Segundo: qué permisos existen, no cuáles están ocultos

Cada operación administrativa exige un permiso concreto, como sites:write o cookies:read. Un permiso que no se concedió en la pantalla de autorización no está oculto en la interfaz: es literalmente inalcanzable, porque el servidor lo rechaza antes de que la petición llegue al controlador. La diferencia importa. Una superficie "oculta" puede exponerse por un bug de interfaz. Una superficie que el servidor nunca expone, no.

Tercero: lo que queda fuera pase lo que pase

Ningún permiso da acceso al identificador real de un sujeto en claro. vault:read permite buscar y ver el estado de consentimiento, nunca descifrar el identificador subyacente ni exportar un volcado completo.
Ningún permiso alcanza claves de API LIVE, secretos de claves existentes, secretos de identidad, configuración de SSO o MFA, miembros del equipo ni facturación. El único acceso a claves es crear y listar claves en modo TEST para desarrollo (api-keys:*). El resto está completamente fuera del modelo de permisos MCP, sin excepción.
Cada autorización queda anotada en el registro de auditoría de la organización, encadenado por hash igual que cualquier otro cambio de configuración.

Y si algo sale mal

Puedes retirar el acceso en cualquier momento desde los ajustes de conectores de Claude. El token de renovación deja de servir de inmediato. El de acceso, como mucho, en 15 minutos: esa es su vida máxima incluso sin revocar nada a mano.

La referencia técnica completa, con cada permiso disponible hoy y qué controlador lo exige, está en la documentación de MCP.