Recursos
Herramientas MCP controladas para agentes de IA
El Model Context Protocol (MCP) facilita la conexión de un modelo o agente a herramientas. El protocolo por sí mismo no decide si el agente debe poder realizar una operación concreta, sobre qué recurso y con qué consecuencia. La capa de aplicación sigue siendo la que debe imponer esos límites.
Si un agente puede usar MCP para leer un informe, cambiar una configuración, iniciar un gasto o eliminar un recurso, lo tratamos como un cliente API privilegiado. El prompt describe la intención. La puerta de enlace (gateway) impone los límites.
En la práctica, diseñamos ese límite alrededor de siete principios.
1. Separar la identidad del operador de las credenciales del sistema de destino
Un agente actúa en nombre de alguien. Por lo tanto, debemos responder al menos a dos preguntas distintas:
- ¿Quién solicitó esta operación y qué está autorizado a hacer en Brillnet?
- ¿Cómo se autentica Brillnet ante el proveedor externo?
No son lo mismo.
En nuestra herramienta interna Brillnet Ads MCP, el operador pasa por la capa de autorización de Brillnet, mientras que las llamadas a Google usan una identidad de servicio separada. El token del proveedor es de corta duración y no se devuelve a través de MCP como datos para el modelo.
El modelo no necesita conocer una credencial para ejecutar una tarea permitida. Tampoco puede pegar accidentalmente esa credencial en una respuesta si nunca la recibió.
Regla
Un secreto debe estar disponible solo para el componente que tiene que usarlo, no para toda la cadena de ejecución.
2. Expresar los permisos por operación, no solo por nombre de agente
Un rol como marketing-agent es fácil de leer, pero por sí solo dice muy poco sobre lo que el sistema realmente permitirá.
Resulta más útil separar los permisos por consecuencia:
read
→ informes y recuperación
write
→ crear o modificar un recurso
operate
→ activar una consecuencia operativa, como gasto o publicación
destructive
→ eliminar, desvincular, revocar o efectuar otro cambio difícil de revertir
Un agente puede tener read sin write. Puede tener write para preparar una campaña pero no operate, de modo que no pueda habilitar esa campaña. La eliminación puede requerir tanto write + destructive.
Los nombres no tienen que ser exactamente esos. La distinción importante es entre preparar un cambio y activar su consecuencia.
Leer: Privilegio mínimo para agentes de IA
3. Los valores predeterminados seguros deben funcionar sin ayuda del modelo
Si la omisión de un parámetro puede activar una acción, el valor predeterminado es inseguro.
En nuestro MCP interno de Brillnet Ads, una nueva campaña permanece PAUSADA cuando no se suministra explícitamente un estado. El detalle parece pequeño, pero la regla es importante: la falta de información no equivale a consentimiento para iniciar el gasto.
El mismo patrón se aplica en otros contextos:
- documento sin estado → borrador, no publicación;
- nuevo usuario sin rol → sin acceso, no un rol por defecto;
- integración sin destino confirmado → sin sincronización;
- recurso ambiguo → error, no el registro “más probable”;
- falta de aprobación para una acción de alto riesgo → detener, no reintentar.
Un valor predeterminado seguro debe seguir siendo seguro cuando el modelo alucina, omite un campo o interpreta mal la intención.
4. Las operaciones de alto impacto necesitan una puerta separada
Un agente puede preparar un cambio técnicamente correcto que sigue siendo la decisión empresarial equivocada.
Gastar presupuesto, publicar contenido, enviar un mensaje a un cliente, cambiar accesos o eliminar datos produce consecuencias más allá de la sesión del agente. Por ello, la aprobación debe ser un evento independiente.
Como mínimo, una vista previa de aprobación debe mostrar:
- sistema y recurso objetivo;
- tipo de operación;
- parámetros materiales del cambio;
- consecuencia esperada;
- si la operación es reversible;
- quién aprueba.
“¿Continuar?” no es suficiente. La persona necesita saber exactamente qué se está aprobando.
Leer: ¿Cuándo debe un agente de IA requerir aprobación humana?
5. Un reintento no debe duplicar silenciosamente una escritura
Los sistemas agenticos hacen muchas llamadas API. Los errores de red, los tiempos de espera y los reintentos son normales. El problema surge cuando repetir la misma operación crea un segundo recurso o ejecuta un segundo pago, publicación o mensaje.
Cuando la operación lo permite, usamos una clave de idempotencia. La puerta de enlace reconoce el mismo intento y evita una escritura duplicada no controlada.
Eso debe combinarse con read‑after‑write:
agente solicita un cambio
↓
gateway valida y ejecuta la escritura
↓
sistema objetivo responde
↓
gateway lee el estado resultante del recurso
↓
operador ve ese estado resultante
Un proveedor que devuelve HTTP 200 ya no es la única evidencia de que el sistema está en el estado esperado.
6. Una puerta de enlace cruda no debe convertirse en una puerta trasera
Las APIs extensas crean una tentación práctica: en lugar de construir una herramienta dedicada para cada punto final, exponer una capacidad REST más general.
Eso puede ser razonable, pero solo si la ruta general hereda los mismos controles.
En Brillnet, método, punto final y características de la solicitud se clasifican antes de la ejecución. Una solicitud de bajo nivel no elude los alcances funcionales requeridos ni el control adicional para operaciones destructivas.
El anti‑patrón se ve así:
herramientas MCP seguras
→ con alcance y validadas
raw_http_request
→ puede llamar a cualquier endpoint con un token de acceso total
En ese diseño, los controles previos son mayormente cosméticos. La ruta más amplia define la verdadera frontera de seguridad.
7. El registro de auditoría guarda la decisión y el resultado, no los secretos
Nuestra herramienta interna registra metadatos de la solicitud y resultados en una cadena de auditoría append‑only con integridad controlada. Las credenciales, encabezados de autorización e identificadores personales sin procesar se excluyen.
Esa distinción importa. Un registro de auditoría debe reconstruir una acción, no duplicar el contexto de seguridad en otro almacén de datos.
Para una operación de agente normalmente queremos saber:
- ID de solicitud/tarea;
- identidad del operador y del agente;
- herramienta y clase de operación;
- recurso objetivo;
- decisión de autorización;
- ID de aprobación si se requirió;
- resultado del proveedor/backend;
- estado observado después de una escritura;
- versión de política o configuración que se aplicó.
Leer: Registros de auditoría de agentes de IA
Arquitectura de ejemplo: un agente para Google Ads
Nuestro caso interno es deliberadamente estrecho. La herramienta se usa solo para cuentas de Google Ads propiedad de Brillnet. No es un servicio de agencia y no recibe acceso a cuentas de anuncios de clientes.
El flujo puede simplificarse a:
operador Brillnet
↓
identidad + perfil + alcances
↓
agente / modelo
↓
llamada a herramienta MCP
↓
gateway: validación + clasificación + política de aprobación
↓
token de proveedor de corta duración
↓
API de Google Ads
↓
normalización + redacción
↓
read‑after‑write / resultado
↓
registro de auditoría
El control más importante no está dentro del modelo. Está en la capa entre la intención y la ejecución.
Anti‑patrones de apariencia conveniente
Un token de administrador para cada agente
Facilita el prototipo. Después, se vuelve difícil limitar el impacto de un error o demostrar que un agente debería haber podido acceder a un recurso.
“El modelo preguntará al usuario si una acción es riesgosa”
Eso delega la decisión de seguridad al mismo componente cuyos errores el control pretende contener.
Registrar todo el prompt y la respuesta como registro de auditoría
Una conversación no es un registro operativo de auditoría. También puede contener información que no debería copiarse al sistema de registro.
Reintentar automáticamente cada error
No todo error es transitorio. No toda escritura es idempotente. Un reintento no clasificado puede aumentar el daño.
Un endpoint universal con acceso total “para futuras funciones”
Si una herramienta amplia puede eludir las herramientas restringidas, la herramienta amplia es el modelo de permisos real.
Lista de verificación para revisión del servidor MCP
Antes de usar en producción, verificaría al menos:
- ¿Se conoce la identidad del operador en cada llamada?
- ¿Están ocultas las credenciales del sistema de destino al modelo?
- ¿Pueden separarse los permisos de read, write, operate y destructive?
- ¿Restringe la autorización el recurso/inquilino/cuenta además de la función?
- ¿Conduce la omisión de un parámetro a un estado seguro?
- ¿Tienen las operaciones financieras, externas y destructivas una aprobación independiente?
- ¿Se controlan los reintentos de escritura?
- ¿Se vuelve a leer el recurso objetivo después de una escritura?
- ¿Utiliza cualquier gateway de bajo nivel las mismas reglas de autorización?
- ¿Excluye el registro de auditoría tokens, secretos y datos personales sin procesar?
- ¿Se rechazan rutas de sistema de archivos arbitrarias y cargas útiles sin límite?
- ¿Puede revocarse centralmente el acceso de agente u operador?
MCP 2026‑07‑28 cambia el protocolo, no la necesidad de controles de aplicación
La versión 2026-07-28 de MCP introdujo, entre otros cambios, un núcleo de protocolo sin estado y un endurecimiento adicional de la autorización. Esos cambios facilitan escalar y razonar sobre la capa de comunicación. No deciden la política empresarial para una implementación: si un agente puede gastar 5 000 PLN, eliminar una cuenta o enviar un mensaje a 10 000 personas.
La aplicación sigue teniendo que imponer esa decisión.
Quién necesita este patrón de diseño
Propietarios de procesos, desarrolladores y revisores de seguridad necesitan este límite. Los agentes de fabricación pueden redactar solicitudes de cambio; los agentes de gestión inmobiliaria pueden organizar documentos; los agentes B2B pueden analizar tickets. Enviar avisos a residentes o cambiar permisos de clientes requiere control de la consecuencia.
El ejemplo de Ads MCP proviene de documentación interna de diseño de herramientas. No describe un servicio de cuentas publicitarias de cliente ni una auditoría independiente del entorno de producción actual.
Identidad y aislamiento requieren más que un token válido
La autorización MCP requiere tokens destinados al recurso propio del servidor. Una firma válida en el token de otro servicio es insuficiente. Verifique audiencia, emisor y vigencia. Rechace tokens inadecuados antes de la ejecución.
También verifique el acceso al recurso. Compare un tenant_id suministrado con la identidad establecida por el servidor en lugar de confiar en el identificador del agente. Cada lectura y escritura necesita autorización de recurso, incluidos adjuntos, exportaciones y trabajos en segundo plano.
MCP 2026-07-28 no tiene sesiones a nivel de protocolo. Las aplicaciones aún pueden mantener estado, como un manejador de vista previa de cambios. La posesión no debe sustituir la autenticación. Vincule los manejadores a operadores autorizados, verifique cada uso y establezca expiración. Un manejador robado no debe exponer el flujo de trabajo de otra persona.
Validar contenido y destinos de comunicación
Resultados de búsqueda, PDFs, correos electrónicos y respuestas API son material de análisis. Instrucciones incrustadas para recuperar secretos o enviar documentos a otro sitio no constituyen aprobación del operador. Para proteger contra inyección de prompts, el servidor debe rechazar recursos, destinatarios y operaciones no autorizados aun cuando los argumentos de la herramienta sean técnicamente válidos.
Para una herramienta que acepte URLs, defina destinos permitidos y manejo de redirecciones. La guía MCP discute SSRF en el descubrimiento de metadatos OAuth. Evalúe el mismo problema en herramientas de recuperación personalizadas. El permiso para obtener una página pública no debe exponer un servicio de administración local o un endpoint de metadatos en la nube. Las protecciones dependen de la arquitectura de red; una lista de nombres de host sola puede no controlar el destino final de la conexión.
Para herramientas de archivos, restrinja directorios y tamaño de carga útil. Rechace rutas fuera del área permitida, campos desconocidos y exportaciones excesivas. Un error explícito es preferible a expandir silenciosamente la asignación.
Escenario de despliegue pequeño: borradores de tickets de servicio
Supongamos que una empresa quiere reducir el tiempo de preparación de tickets de incidentes de equipos. El agente lee un manual aprobado y el historial de incidentes, luego prepara un borrador. Enviarlo a un proveedor sigue siendo una operación separada. Este es un escenario de diseño, no una afirmación de que Brillnet ofrezca actualmente esta funcionalidad.
El propietario del servicio selecciona un grupo de equipos y define la salida esperada: un borrador que identifique el equipo, síntoma, hora del evento e información faltante. El desarrollador expone dos herramientas estrechas: recuperación de documento aprobado y creación de borrador en un proyecto especificado. La versión inicial no incluye mensajería ni configuración de equipos. El revisor de seguridad verifica el alcance de datos y la revocación central de accesos.
Compruebe una lectura permitida, un intento de lectura cruzada de proyecto, un documento con instrucciones maliciosas y un reintento de escritura tras un tiempo de espera. Un catálogo de herramientas pequeño basta para comenzar. Debe imponer las restricciones que el diseño promete.
Si más adelante se añade el envío, la aprobación debe cubrir al destinatario y al contenido. Cambiar al destinatario invalida la aprobación previa. Cuando un proveedor no soporta idempotencia, resuelva un tiempo de espera ambiguo verificando si el mensaje ya existe. No reenvíe simplemente porque el agente no recibió respuesta.
Qué hacer mañana, con un propietario
El propietario del proceso elige una acción y su consecuencia permitida. El desarrollador mapea herramienta, operación y recurso, incluyendo la ruta de acceso más amplia disponible. El revisor de seguridad verifica dónde termina la identidad del operador, dónde comienza la identidad del servicio y si el modelo puede acceder a credenciales. El entregable del primer día debe ser un mapa breve y una ejecución cuyo estado resultante pueda verificarse en el sistema objetivo.
Mida la calidad de los borradores aceptados, las violaciones de alcance rechazadas y el tiempo de revisión humana. Más llamadas a herramientas no son automáticamente útiles. Si la corrección lleva más tiempo que la preparación ahorrada, reduzca la asignación antes de añadir capacidades.
Guía técnica y obligaciones legales
OWASP y NIST ofrecen guías técnicas. La especificación MCP define los requisitos del protocolo. Estas fuentes no determinan de forma independiente las obligaciones legales o los periodos de retención de datos de una empresa concreta. Establezca los requisitos sectoriales, contractuales y legales aplicables al proceso. Esta guía explica el diseño de controles y no otorga certificación de cumplimiento.
Límite
Estos son patrones que usamos en nuestro propio trabajo. Esta página no afirma que toda la herramienta esté certificada o sea universalmente compatible con OWASP, NIST o la especificación completa de MCP. Cada integración sigue necesitando su propio modelo de amenazas y pruebas de seguridad.
Si está evaluando cómo Brillnet maneja acceso, datos e IA, consulte Seguridad y Cumplimiento y supervisión de IA.
Fuentes
Las fuentes técnicas respaldan los principios expuestos. Los escenarios de despliegue y el plan de acción son recomendaciones de diseño del autor.
- Model Context Protocol — Specification 2026-07-28 release — accessed: 2026-10-02.
- Model Context Protocol — Authorization 2026-07-28 — accessed: 2026-10-02.
- Model Context Protocol — Security Best Practices 2026-07-28 — accessed: 2026-10-02.
- OWASP AI Agent Security Cheat Sheet — accessed: 2026-10-02.
- OWASP MCP07:2025 — Insufficient Authentication & Authorization — accessed: 2026-10-02.
- OWASP MCP08:2025 — Lack of Audit and Telemetry — accessed: 2026-10-02.
- OWASP Authorization Cheat Sheet — accessed: 2026-10-02.