MCP y agentes confiables
Estado de revisión: Esta página base requiere revisión especializada antes de su aprobación pública. Sus afirmaciones deben mantenerse dentro del alcance indicado aquí.
Model Context Protocol, o MCP, proporciona una conexión estandarizada entre aplicaciones de IA y resources, prompts y tools externos. Define cómo un host, cliente y servidor negocian capacidades e intercambian mensajes estructurados.
En UbID, MCP es un protocolo de integración para asistencia de software gobernada. No es un estándar de credenciales de identidad, un motor de decisiones de confianza ni una autorización para que un modelo de IA emita credenciales, recupere identidades, utilice claves institucionales o modifique sistemas productivos de forma autónoma.
Funciones MCP
| Función | Responsabilidad |
|---|---|
| Host | Aplicación de IA orientada al usuario que administra interacción, consentimiento y política. |
| Cliente | Conector dentro del host que se comunica con un servidor MCP. |
| Servidor | Servicio que expone resources, prompts o tools aprobados. |
| Servicio de dominio | Servicio autoritativo de UbID que valida y ejecuta una operación de identidad permitida. |
| Aprobador humano o de política | Actor o regla responsable que autoriza una transición sensible. |
El modelo puede interpretar y proponer. Los servicios autoritativos y la política determinista siguen siendo responsables de la ejecución.
Resources, prompts y tools
Resources
Los resources aportan contexto estructurado, con frecuencia mediante URIs. UbID puede utilizar resources read-only para exponer información aprobada, como capacidades públicas de arquitectura, estado del emisor, tipos de credenciales, soporte de protocolos o resúmenes operacionales.
Una URI de resource no concede acceso irrestricto a una base de datos. El servidor aplica autorización, minimización, filtrado y reglas de evidencia antes de devolver contenido.
Prompts
Los prompts pueden ofrecer plantillas controladas para workflows recurrentes. Deben tratarse como asistencia versionada, no como política ni autoridad ejecutable.
Tools
Las tools exponen operaciones con inputs y outputs definidos. La descripción de una tool no demuestra que sea segura, y la validación de inputs no puede delegarse a un LLM. Las tools sensibles necesitan scopes explícitos, validación determinista, gates de aprobación, idempotencia, efectos acotados y ejecución auditable.
Patrón de control UbID
Las operaciones sensibles siguen un patrón por etapas:
- Discover — identificar resources y capacidades aprobados.
- Prepare — construir una solicitud propuesta sin ejecutarla.
- Validate — aplicar de forma determinista controles de schema, identidad, política, estado y riesgo.
- Approve — obtener autorización humana o una decisión explícita de política preaprobada.
- Execute — invocar el servicio de dominio autoritativo con credenciales acotadas.
- Evidence — registrar solicitud, controles, autorización, resultado y referencias sin material secreto.
La preparación y validación pueden automatizarse ampliamente. Aprobación y ejecución permanecen restringidas según el impacto.
Read-only primero
La postura inicial de MCP en UbID prioriza resources read-only y tools de diagnóstico. Read-only no significa libre de riesgo: datos operacionales, metadatos de identidad, schemas de credenciales y alertas todavía pueden ser sensibles o facilitar reconnaissance.
Por ello, los servidores deben aplicar mínimo privilegio, limitación de finalidad, aislamiento de tenants, rate limits, filtrado de outputs y consentimiento claro del usuario.
Límites de seguridad y confianza
Las implementaciones MCP deben considerar:
- prompt injection procedente de contenido no confiable de resources;
- descripciones maliciosas o engañosas de tools;
- comportamiento confused deputy;
- scopes excesivos y credenciales de larga duración;
- exposición de datos entre tenants;
- chaining de tools que produzca una acción de alto impacto no prevista;
- exfiltración de datos mediante output del modelo o sampling;
- replay, ejecución duplicada y fallas parciales;
- sustitución no autorizada del servidor;
- desviación de versiones y cambios de capacidades.
El output de una tool constituye evidencia que debe evaluarse, no una razón para omitir la autorización ordinaria.
Identidad y autorización
La autorización de transporte MCP controla el acceso al servidor. UbID todavía exige autorización consciente de identidad en cada resource o tool. El servidor debe conocer principal, tenant, finalidad y scope aplicables a cada solicitud.
El modelo de IA no debe recibir llaves privadas sin procesar, autoridad root del KMS, recovery shares, credenciales irrestrictas de bases de datos ni acceso shell directo.
Asistencia basada en evidencia
Un asistente confiable debe distinguir:
- hechos observados devueltos por resources autoritativos;
- resultados de validación determinista;
- decisiones de política;
- interpretación generada por el modelo;
- incertidumbre y evidencia ausente;
- acciones realmente ejecutadas.
Esta separación impide que un texto fluido se confunda con un estado autoritativo de la plataforma.
Posición de UbID
El discovery read-only mediante MCP y la asistencia operacional forman parte de la baseline de referencia implementada de UbID, con expansión controlada prevista para tools adicionales. Las acciones sensibles de identidad siguen sujetas a autorización de dominio, política explícita, aprobación y evidencia.
Como MCP está versionado y continúa evolucionando, las integraciones UbID deben fijar una versión revisada del protocolo y un conjunto de capacidades, en vez de asumir compatibilidad con todo borrador o extensión.
Límite de la documentación pública
Esta página no publica inventarios internos de resources, schemas de tools, prompts, tokens, scopes, endpoints operacionales, contenido de alertas, system instructions, umbrales de guardrails, credenciales de ejecución ni reglas productivas de aprobación.
Estándar fuente
Consulta Agentes digitales confiables y UbID Sentinel AI.