¿Para quién trabaja tu plugin de IA? Cómo auditar MCP y extensiones
MCP y las extensiones amplían lo que puede hacer la IA. Aprende a verificar procedencia, permisos, destinos de los datos y contratos, distinguiendo cada riesgo.
Las voces dependen del navegador y del dispositivo; algunas necesitan conexión a internet. Los bloques de código no se leen en voz alta.
Tiempo estimado de lectura: 10 minutos.
Instalas una extensión, conectas un servidor MCP y, unos minutos después, la IA puede consultar documentos, abrir tareas y trabajar en el proyecto. La demostración funciona. La pregunta que suele llegar tarde es bastante menos emocionante: ¿a qué datos puede acceder esta herramienta y adónde pueden ir?
En mi trabajo con integraciones en Oombe, una preocupación acompaña a cada funcionalidad: qué permite hacer ese acceso en la cuenta conectada. Con los agentes de IA aparecen nuevos caminos. Un recurso que parece ayudar únicamente a escribir código puede participar en una secuencia que involucra archivos, credenciales, servicios externos y modelos de diferentes proveedores.
El botón «instalar» es pequeño. La lista de decisiones que esconde puede ser bastante larga.
La buena noticia es que podemos organizar este análisis sin convertir cada instalación en una película de detectives. El comienzo consiste en separar problemas distintos, porque cada uno necesita sus propias evidencias y controles.
Tres problemas que merecen nombres diferentes
El software malicioso está preparado para ejecutar una acción indebida. Imagina una herramienta ficticia que promete resumir consultas de soporte, pero también envía copias a una dirección externa. La operación útil sirve de envoltorio para la operación oculta.
El software vulnerable puede tener una finalidad legítima y un fallo explotable. Un error de autorización, por ejemplo, podría permitir que alguien consultara información de otra persona. Corregir ese fallo y entender el alcance de la exposición requiere un trabajo diferente del necesario para investigar una intención maliciosa.
Una laguna contractual aparece cuando la documentación no explica suficientemente el tratamiento realizado. Un proveedor puede utilizar servicios adicionales sin describirlos claramente. Eso requiere aclaración y evaluación, pero no permite concluir automáticamente que hubo una filtración.
Estas situaciones pueden combinarse. Aun así, llamar a todo «MCP malware» dificulta el diagnóstico. También facilita una conclusión demasiado cómoda: cambiar de herramienta y creer que la gobernanza quedó resuelta.
OWASP LLM03:2025 incluye dependencias, componentes y modelos de terceros en la discusión sobre la cadena de suministro de IA. Este enfoque ayuda a entender la aplicación como un conjunto de relaciones, con responsabilidades distribuidas.[1]
MCP conecta herramientas; la confianza debe construirse
Lo interesante de un agente es que puede actuar sobre sistemas. Eso también exige preguntar quién definió la herramienta, qué instrucciones presenta al modelo y qué acciones permite realmente el entorno.
En abril de 2025, Invariant Labs demostró ataques de tool poisoning: instrucciones maliciosas introducidas en las descripciones de herramientas podían influir en el agente. La demostración documenta una clase de riesgo; no prueba que todos los clientes actuales tengan la misma vulnerabilidad.[2]
Piensa en una recepción que recibe notas de proveedores. Una nota puede informar sobre el horario de una entrega. Eso no debería autorizarla a cambiar quién tiene acceso a la caja fuerte. Un sistema con IA también necesita esa separación mediante controles externos al modelo.
La documentación draft de seguridad de MCP aborda autorización, aislamiento y validación del destinatario de los tokens, además de prohibir el token passthrough inadecuado. También distingue los riesgos de ciertas arquitecturas de proxy del transporte stdio en sí.[3]
La consecuencia práctica es directa: una advertencia escrita en el prompt no sustituye los permisos aplicados por el sistema. Si una herramienta solo necesita consultar información, el diseño debe restringir qué puede consultar e impedir modificaciones innecesarias.
¿El contrato cuenta la misma historia que la arquitectura?
Un estudio de DataGrail, publicado en 2026, informó que el 63,6 % de los proveedores evaluados en el estudio no identificaban a subencargados de IA de terceros en su documentación jurídica. La empresa describe un cruce de contratos con evidencias como integraciones, actividad en GitHub y páginas comerciales.[4]
La cifra merece atención, pero debemos conservar su significado. Señala una brecha de transparencia en una investigación de un proveedor comercial. No significa que el 63,6 % de las herramientas filtraran datos, ni demuestra el destino de cada solicitud procesada.
Para evaluar un producto concreto, empezaría con preguntas objetivas: qué empresas reciben datos, en qué situaciones, durante cuánto tiempo, bajo qué condiciones de uso y cómo se comunicarán los cambios.
Un detalle merece espacio en esa conversación: el fallback. Si el modelo principal no está disponible, ¿puede el servicio llamar a otro? Esa alternativa debe ajustarse a la política aprobada. Conviene definir proveedores permitidos, categorías de datos autorizadas y qué hacer cuando no haya ninguna opción aceptable.
Este tema conecta con las diferencias entre Política de Privacidad y Términos de Uso. Una documentación clara ayuda a establecer expectativas; la implementación debe sostenerlas.
Qué ayuda a descubrir Bumblebee
Bumblebee, de Perplexity, recopila metadatos locales de paquetes, extensiones y determinadas configuraciones de herramientas en macOS y Linux. Funciona en modo de solo lectura y compara el inventario con catálogos de exposiciones conocidas. Su alcance no equivale a un detector universal de malware ni a una auditoría contractual.[5]
Eso resulta útil para una pregunta concreta: «¿Tenemos el componente o la versión citados en esta alerta?». Un inventario organizado reduce el trabajo necesario para buscar la respuesta equipo por equipo.
Pero quedan otras preguntas: ¿la herramienta envió datos?, ¿el destino estaba autorizado?, ¿la credencial permitía demasiado acceso?, ¿el contrato describía el procesamiento? Cada una necesita evidencias adicionales.
Como uso Windows en mi día a día, también verificaría la cobertura antes de convertir una herramienta en una recomendación operativa. Un procedimiento presentado para Linux no debe venderse como una auditoría completa de una estación Windows. El objetivo es mapear el entorno real, incluidos los puntos que el escáner no cubre.
Una auditoría que comienza con preguntas que podemos responder
El primer entregable puede ser una tabla sencilla. Para cada herramienta, registra responsable, origen, versión, finalidad, acceso concedido, destinos esperados y fecha de la última revisión. Después, avanza por seis preguntas.
1. ¿Quién mantiene este software? Comprueba el recorrido entre la página oficial, el repositorio y el paquete instalado. Los nombres parecidos ayudan a encontrar cosas; por sí solos, no demuestran procedencia. Registra cómo se verificó la identidad y quién seguirá las próximas actualizaciones.
2. ¿Qué recursos necesita realmente? Compara la tarea con los permisos. ¿Una herramienta que lee documentación necesita acceso de escritura a todo el proyecto? ¿Necesita las credenciales utilizadas en producción? Cada capacidad adicional merece una justificación operativa.
3. ¿Qué datos atraviesan la integración? Dibuja una solicitud de principio a fin. Incluye adjuntos, fragmentos de código y resultados devueltos. Considera también los componentes auxiliares: registro de errores, soporte y observabilidad pueden participar en el flujo.
4. ¿Qué destinos están permitidos? Documenta proveedores, servicios y condiciones de fallback. Siempre que sea viable, aplica esa política en el entorno de ejecución. Un texto que dice «utiliza solo el proveedor aprobado» deja abierta una pregunta: ¿qué impide otra llamada?
5. ¿Cómo llegan los cambios? Define quién revisa las actualizaciones de paquetes, los cambios de herramientas y las ampliaciones de permisos. La aprobación inicial pierde parte de su valor si después entran modificaciones sin seguimiento.
6. ¿Cómo detener y recuperar? Debes saber revocar la credencial, deshabilitar la integración, conservar las evidencias necesarias e identificar operaciones afectadas. El procedimiento debe adaptarse a la realidad del equipo. Un plan imposible de ejecutar a las tres de la tarde difícilmente será más sencillo a las tres de la madrugada.
Estas respuestas forman una imagen verificable. También revelan prioridades: corregir primero los accesos y flujos de mayor impacto y profundizar después en el resto.
Un ejemplo cercano a quienes trabajan con marketplaces
Imagina un asistente ficticio para una operación de comercio electrónico. Lee preguntas de clientes, consulta información del pedido y prepara una respuesta. La propuesta tiene sentido. Ahora coloca todas esas funciones detrás de una sola credencial que también puede modificar anuncios y configuraciones de la cuenta.
El problema arquitectónico aparece antes de cualquier ataque: la capacidad concedida supera la tarea descrita.
Una alternativa consistiría en separar la consulta del pedido, el acceso a la base de conocimiento y la preparación de la respuesta. El envío tendría una regla propia. Las modificaciones comerciales estarían en otro flujo, con permisos y validaciones específicos.
Si el asistente recibe un texto extraño en un mensaje, esa separación reduce el conjunto de acciones disponibles. La pregunta se amplía: además de «¿el modelo interpretará correctamente?», importa «¿qué consecuencia permite el sistema si interpreta mal?».
El ejemplo es hipotético; no describe un incidente en Oombe. La experiencia con integraciones ayuda a formular la pregunta correcta: qué capacidades estamos delegando, a quién y bajo qué condiciones.
Una prueba pequeña que produce evidencias útiles
Antes de llevar un entorno sensible al laboratorio, prepara un proyecto de demostración con documentos y credenciales ficticios. Define dos herramientas: una puede leer una carpeta de ejemplos; la otra consulta una API de prueba con un alcance limitado.
Prepara tareas esperadas y situaciones fuera del alcance. Verifica si el agente puede solicitar una acción indebida, si el entorno la bloquea y si el registro permite entender qué sucedió. Simula también la indisponibilidad del proveedor principal: ¿el fallback respeta la lista permitida?
Registra el resultado con precisión: intento solicitado, decisión de autorización, ejecución efectiva y destino. Una acción sugerida por el modelo y una acción ejecutada tienen consecuencias diferentes.
Este ejercicio no certifica una seguridad completa. Produce evidencias para un conjunto definido de requisitos y ayuda a localizar controles que existían únicamente en el discurso.
El servicio que merece la pena entregar
Para quienes quieran ofrecer consultoría, aquí hay un entregable concreto: inventario, mapa de datos, matriz de permisos, análisis de las condiciones contractuales y plan de corrección priorizado. La revisión jurídica puede requerir participación especializada; el trabajo técnico debe mostrar qué hace realmente la arquitectura.
El valor está en reducir incertidumbres de una operación específica. Prometer que un escáner «garantiza seguridad» crea una expectativa que no puede sostener.
En la discusión sobre privacidad y poder sobre los datos, la pregunta práctica sigue siendo quién puede hacer qué. Los agentes amplían la utilidad de las integraciones. Nuestra responsabilidad consiste en hacer que los límites crezcan junto con esa utilidad.
Antes de instalar la próxima maravilla, vale la pena dedicar cinco minutos a una pregunta: si esta herramienta actúa fuera de lo esperado, ¿puede el entorno impedirlo? La respuesta suele decir más sobre la madurez del proyecto que la belleza de la demostración.
Fuentes y lecturas
- OWASP — LLM03:2025 Supply Chain.
- Invariant Labs — MCP Security Notification: Tool Poisoning Attacks, abril de 2025.
- Model Context Protocol — Security Best Practices, documentación draft.
- DataGrail — discusión del Privacy & AI Trends Report 2026, junio de 2026.
- Perplexity — repositorio oficial de Bumblebee.
Fuentes consultadas el 26 de octubre de 2026. Las funcionalidades, la cobertura y las recomendaciones de seguridad deben verificarse para la versión utilizada.
