Durante casi un año, la respuesta honesta a «¿es seguro conectar un asistente de IA a mis notas?» era que la conexión solo las leía. Valía para la mayoría de los servidores MCP para notas de reunión, y volvía fácil la pregunta de seguridad: una herramienta que no puede cambiar nada no puede cambiar lo que no debe.
Ahí ya no está la pregunta interesante. Los asistentes etiquetan grabaciones, renombran hablantes, rehacen transcripciones y publican notas en canales compartidos — y la versión útil de la pregunta es más estrecha: ¿qué tiene que cumplirse antes de dejar que un modelo cambie sus datos? Cuatro cosas, y ninguna es «el proveedor promete tener cuidado»: el cliente pregunta antes de la llamada, el cambio es lo bastante acotado como para describirlo en una frase, los cambios irreversibles están marcados como tales y hay un registro que se puede leer después.
Este artículo trata de por dónde pasa esa línea. Si el protocolo en sí le resulta nuevo, qué es un servidor MCP explica antes lo básico.
«Acceso de escritura» es una sola expresión para tres cosas muy distintas, y mezclarlas es lo que hace que el tema parezca más temible de lo que es.
Etiquetar. Etiquetas, títulos, nombres de hablantes. Añaden o sustituyen metadatos junto a una grabación. Si el asistente etiqueta la reunión equivocada, usted abre la aplicación y quita la etiqueta. El peor caso es recoger detrás de un modelo demasiado entusiasta.
Sustituir contenido. Rehacer la transcripción de una grabación produce un texto nuevo y descarta el anterior — incluidas las correcciones que usted hizo a mano. Nada salió de su máquina, pero algo que era suyo ya no está. Es la clase en la que «reversible» deja de ser cierto sin hacer ruido.
Salir de la máquina. Publicar una grabación en un canal de equipo, compartir una transcripción por correo, conceder acceso a alguien. Aquí el cambio no afecta sobre todo a sus datos — afecta a quién los ha visto. Deshacer es una operación técnica sobre un hecho social, y no funciona.
Un modelo de seguridad que trate esas tres cosas como un único ajuste se equivocará en ambas direcciones: demasiado ruidoso para la primera, demasiado permisivo para la tercera.
MCP tiene vocabulario para esto. La definición de una herramienta puede llevar
anotaciones: readOnlyHint (la herramienta solo lee), destructiveHint (puede
sobrescribir en lugar de añadir), idempotentHint (llamarla dos veces no cambia
nada más) y openWorldHint (alcanza sistemas externos). Un servidor que publica
una herramienta de compartición sin openWorldHint se está describiendo mal.
Dos frases de la especificación deciden cuánto vale ese vocabulario. Primero, sobre el deber del cliente: «por confianza y seguridad, DEBERÍA haber siempre una persona en el circuito con capacidad de denegar las invocaciones de herramientas». Segundo, sobre las anotaciones mismas: los clientes «DEBEN considerar las anotaciones de herramientas como no fiables salvo que provengan de servidores de confianza».
Leídas juntas, esas dos frases zanjan la arquitectura. Las anotaciones son la forma en que un servidor declara riesgo; no son un cerrojo que el servidor pueda echar. La barrera vive en el cliente, y el aviso de confirmación que usted ve antes de que una herramienta se ejecute es una decisión de su cliente, informada por la declaración del servidor. Claude Code, por ejemplo, pregunta por defecto en las herramientas MCP, mientras que en las suyas propias no lo hace.
La consecuencia práctica es incómoda y conviene decirla con claridad: el momento en que usted decide algo es el momento en que concede un permiso permanente. Después de «permitir siempre», el diálogo ya no es un control. Concédalo por herramienta y no por servidor — buscar cada hora está bien; compartir cada hora, no.
El eje útil no es lectura frente a escritura. Es cuánto cuesta un error.
| Acción | ¿Se deshace? | Por qué |
|---|---|---|
| Añadir o quitar una etiqueta | Sí, en la aplicación | Metadatos junto a la grabación |
| Renombrar una grabación o un hablante | Sí, en la aplicación | Un rótulo, no el contenido |
| Rehacer la transcripción | No | Sustituye el texto, correcciones manuales incluidas |
| Publicar en un canal de equipo | No | Puede que los compañeros ya lo hayan leído |
| Compartir una transcripción por correo | No | Los destinatarios conservan lo que recibieron |
Todo lo que aparece en las tres últimas filas merece una confirmación explícita cada vez; lo de las dos primeras, probablemente no. La lista de herramientas es donde un proveedor declara cuáles ofrece, y conviene leerla antes de conectar nada.
Los avisos de confirmación se desgastan. Una sola tarea de investigación puede generar decenas, incluidas las de herramientas que no pueden modificar nada, y el resultado documentado es que la gente desactiva los avisos en bloque en lugar de leer el siguiente. Un control que le enseña a descartarlo no es un control.
Un registro no se desgasta, porque se lee a posteriori y solo cuando hay una duda. Las recomendaciones de la especificación a los clientes incluyen registrar el uso de herramientas con fines de auditoría, y el mismo razonamiento vale para el servidor: si un asistente puede cambiar algo, usted debería poder ver después qué cambió, cuándo y sobre qué registro.
La prueba útil para cualquier integración MCP con acceso de escritura: si el modelo hizo anoche algo que yo no esperaba, ¿dónde lo leería hoy? Si la respuesta es «en ningún sitio», el diálogo de confirmación estaba cargando él solo con todo el modelo de seguridad.
Hay dos formas de impedir que un asistente cambie cosas, y no son intercambiables.
Por cliente, en la configuración de ese cliente. Un servidor arrancado en
modo de solo lectura publica únicamente sus herramientas de lectura. La
diferencia con rechazar llamadas no es cosmética: una herramienta que el modelo
no ve es una herramienta que no propondrá, así que nunca recibe un «lo publico
ahora en el canal del equipo» seguido de un error. En Speak-Y esto es la opción
--read-only en los args del servidor, y deja seis herramientas de lectura en
pie.
Globalmente, en la aplicación. Un solo interruptor que cubre a la vez a todos los clientes conectados, sea cual sea el que pidió.
La distinción importa porque una opción en el archivo de configuración de Cursor sujeta a Cursor y a nadie más. La opción por cliente dice «Cursor solo puede leer, Claude Code puede hacerlo todo»; solo el interruptor de la aplicación es una afirmación sobre todos ellos.
Speak-Y separa las dos mitades a propósito, y la separación se ve desde fuera.
Leer es local y no necesita nada en marcha. Búsqueda, transcripciones, resúmenes, tareas pendientes y etiquetas salen de la biblioteca de su Mac, abierta en solo lectura por un proceso aparte; la aplicación no tiene que estar en marcha. No se sube nada para que el asistente lo lea — aunque, como con cualquier servidor MCP, lo que lee se envía al proveedor de su modelo como parte de la conversación, que es otra cuestión distinta de dónde se guardan los datos.
Los cambios pasan por la aplicación en marcha. Etiquetar, renombrar, retranscribir y publicar en un canal de equipo los ejecuta el mismo código que hay detrás de los botones de la interfaz, no una segunda implementación con su propia idea de las reglas. Si la aplicación no está en marcha, esas herramientas lo dicen en lugar de funcionar a medias.
Cada acción se declara y se registra. Las herramientas que modifican se
publican con readOnlyHint: false; la retranscripción y la publicación en un
canal llevan además destructiveHint, y la publicación lleva openWorldHint,
porque es la única acción que sale de la máquina. Las últimas 50 acciones
aparecen en Configuración → Integraciones con hora, operación, registro
afectado y resultado — y sin el texto de las transcripciones, que si no
sobreviviría a la grabación de la que salió. El interruptor de las acciones del
asistente está en esa misma pantalla, y el servidor es gratuito en todos los
planes.
Comprobado el 13 de agosto de 2026, en la documentación de cada proveedor:
La lista de Fireflies es la interesante, porque «comparte esta transcripción con estas direcciones de correo» es justo la clase de acción en la que la confirmación del cliente es lo único que se interpone entre una instrucción mal entendida y un destinatario. No es una crítica a la función — declararla en la lista de herramientas es la forma honesta de publicarla. Es un argumento para leer esa lista antes de conceder permiso permanente a un servidor entero.
Nada de esto exige confiar en las intenciones de un proveedor, y ese es el punto. «¿Es seguro dejar que un asistente cambie mis datos?» no tiene respuesta general, pero se descompone en preguntas que sí la tienen: qué cambia, quién confirma, qué se puede deshacer y dónde queda escrito.
Si aún no ha conectado ningún asistente, el punto de partida práctico es conectar las notas de reunión por MCP, que recorre la instalación y las primeras consultas antes de que nada de esto resulte relevante.
Lo es en un sentido muy concreto: una herramienta que no puede cambiar nada no puede cambiar lo que no debe. Pero solo lectura es un instrumento tosco, no un modelo de seguridad. Lo que de verdad protege es saber qué cambios son reversibles, tener un cliente que pregunte antes de los irreversibles y poder leer después qué se hizo. Un servidor de solo lectura le da la primera propiedad a cambio de renunciar a la función.
Eso es una propiedad de su cliente, no del servidor. La especificación de MCP dice que siempre debería haber una persona en el circuito con capacidad de denegar la invocación de una herramienta, y clientes como Claude Code preguntan por defecto en las herramientas MCP. Los servidores pueden declarar una herramienta como modificadora o destructiva mediante anotaciones, pero la especificación exige a los clientes tratar esas anotaciones como no fiables salvo que el servidor sea de confianza: informan el aviso, no lo imponen.
El diálogo de confirmación deja de ser un control para esa herramienta y todas las llamadas posteriores se ejecutan sin preguntar. Es un intercambio razonable para una herramienta de búsqueda y malo para una que comparte datos con otras personas. Conceda el permiso permanente por herramienta y no por servidor, y trate el registro de actividad como lo que responde a qué pasó en realidad.
Sí, si el servidor admite un modo de solo lectura fijado en la configuración del propio cliente. Speak-Y lo admite: añadir --read-only a los args en la configuración MCP de un cliente publica solo las herramientas de lectura para ese cliente, así que Cursor puede quedar limitado a leer mientras Claude Code conserva el acceso completo. Un interruptor dentro de la aplicación, en cambio, se aplica a todos los clientes a la vez.
Dos clases. Rehacer la transcripción sustituye el texto actual de una grabación, incluidas las correcciones hechas a mano. Publicar una grabación en un canal de equipo la hace visible para los compañeros, y retirarla después no deshace la lectura. Etiquetas, títulos y nombres de hablantes son rótulos y se pueden revertir en la aplicación.