IA y agentes
Agentes con MCP: útiles por diseño, seguros por control
Cómo exponer herramientas a un agente sin convertir cada integración en un permiso implícito.
MCP estandariza la forma en que una aplicación descubre herramientas y contexto, pero no elimina la necesidad de diseñar límites. Un servidor capaz de leer archivos, consultar clientes o desplegar software debe partir de privilegios mínimos y alcances explícitos.
La autorización tiene que vivir en la frontera real del recurso. El cliente puede pedir consentimiento, pero el servidor sigue siendo responsable de validar identidad, audiencia, alcance y pertenencia del dato. Para operaciones sensibles conviene separar lectura y escritura, exigir confirmación y registrar el resultado.
Visual editorial
Capas de control para una herramienta MCP
También hay que tratar las descripciones y respuestas de herramientas como entrada no confiable. Validar esquemas, limitar tamaño, evitar encadenamientos automáticos y mostrar al usuario el efecto concreto reduce ataques de confusión, redirección o escalamiento.
La prueba práctica es sencilla: si el agente interpreta mal una instrucción, el sistema debe fallar de forma acotada. Un buen MCP no depende de que el modelo siempre acierte; hace que los errores sean visibles, reversibles y auditables.
Modelar amenazas antes de publicar herramientas
El análisis empieza identificando actores y fronteras: usuario, cliente de IA, servidor MCP, proveedor de identidad y sistema final. Cada salto cambia quién controla los datos y dónde se debe rechazar una solicitud. Un token válido no basta si fue emitido para otra audiencia, organización o recurso.
Contratos pequeños y efectos explícitos
Una herramienta segura hace una sola cosa, usa un esquema cerrado y describe su efecto con lenguaje observable. Es mejor separar consultar, preparar y ejecutar que ofrecer una operación genérica. Los identificadores los resuelve el servidor y las acciones repetibles usan claves de idempotencia para evitar duplicados.
Aprobación proporcional al riesgo
Leer documentación pública no requiere el mismo control que enviar un pago o desplegar producción. Conviene clasificar herramientas por riesgo y pedir confirmación solo cuando aporta valor. La confirmación debe mostrar destino, alcance y cambio esperado, no un mensaje genérico que el usuario termina aceptando por hábito.
Operar como si el modelo pudiera equivocarse
Rate limits, límites de tamaño, expiración corta, rotación de secretos y un interruptor de emergencia reducen el radio de impacto. Los registros deben vincular usuario, herramienta, argumentos normalizados, autorización y resultado, pero excluir credenciales y datos sensibles que no hagan falta para investigar.
Criterio de salida
La integración está lista cuando una interpretación incorrecta produce un error acotado, comprensible y reversible. Si el control depende de que el modelo “se porte bien”, todavía no existe una frontera de seguridad real.