Lección 3 · Publicación: lectura, borrador, revisión y envío
Localiza la frontera entre producir texto y autorizar una comunicación.
Dos herramientas con efecto externo
start_thread recibe título, contenido y una mención opcional. update_thread recibe un identificador de hilo, contenido y una mención opcional. Ambas funciones llaman al cliente que realiza la publicación correspondiente. La segunda añade una respuesta; no sustituye ni corrige el texto original.
La validación de campos no vacíos y la estructura del contrato evitan algunas llamadas mal formadas, pero no comprueban que el contenido esté aprobado por una persona competente. Tampoco establecen por sí solas la exactitud de una comunicación o la legitimidad de mencionar a una persona.
La secuencia de gobierno
Para interpretar el uso dentro del curso se separan cuatro fases: lectura → borrador → revisión humana → envío autorizado. Esta secuencia pertenece al gobierno de la aplicación completa. Las funciones de publicación examinadas no incluyen un estado de borrador, un registro de aprobación ni una barrera humana obligatoria dentro de su definición.
| Fase | Qué significa | Relación con el repositorio |
|---|---|---|
| Lectura | Obtener contexto permitido y comprender su cobertura | Hay herramientas de consulta |
| Borrador | Preparar el texto sin publicarlo | Corresponde al cliente o al proceso que utiliza las herramientas |
| Revisión humana | Examinar contenido, destino y oportunidad | No está impuesta por las funciones de publicación |
| Envío autorizado | Solicitar la acción tras una decisión válida | El servidor aporta start_thread o update_thread para ejecutar el efecto |
La disponibilidad de una herramienta no es autorización para invocarla. Una confirmación genérica tampoco explica qué contenido y destino se revisaron. La supervisión efectiva necesita referirse a la acción concreta; el servidor analizado no construye por sí solo esa relación organizativa.
El contenido leído sigue siendo contenido
Un mensaje recuperado de Teams puede contener peticiones, instrucciones o referencias a otras actuaciones. Su lectura no le concede autoridad para ordenar al agente que publique, cambie de finalidad o revele información. La frontera entre datos recuperados e instrucciones autorizadas debe conservarse en el cliente o en la capa que controla sus acciones.
Esta es una implicación de conectar contenido con herramientas que actúan. No se presenta como un incidente observado en el repositorio. Las prácticas de seguridad de MCP ayudan a situar esa separación dentro del diseño completo de clientes y servidores.
Destino e identidad de publicación
El destino configurado, la persona mencionada y la identidad de la aplicación forman parte del efecto de la comunicación. Un envío exitoso acredita un resultado técnico de publicación; no demuestra que el texto hubiera sido revisado o que la persona correcta hubiera autorizado el envío.
Este análisis no incluye laboratorios ni llamadas de publicación. Si en otro contexto se realizan pruebas, la autorización y los destinos aislados de prueba pertenecen a ese trabajo específico. Aquí se estudian contratos y efectos sin utilizar identificadores reales ni ejecutar acciones sobre Teams.
Los módulos de supervisión y responsabilidades del curso amplían esta distinción. Permiten aprovechar las herramientas del servidor manteniendo la decisión humana en una capa que el repositorio no impone automáticamente.
Amplía este punto en el curso
Módulo 8 · Supervisión humana. Desarrolla la relación entre información, revisión y autorización de una acción.
Módulo 3 · Liderazgo y responsabilidades. Sitúa quién tiene atribuciones para aprobar comunicaciones y operaciones.
Fuentes de esta lección
M2 · Código: herramientas y arranque MCP
Cómo vincular la aprobación al envío concreto
En el caso docente de Tech Server IIT Spain, el responsable revisa el texto, el equipo, el canal, el hilo y las menciones antes de autorizar la publicación. La capa cliente conserva una versión de esa propuesta. Si cualquiera de esos elementos cambia, se invalida la aprobación y se solicita otra. Aprobar una intención genérica, como «informa al equipo», no equivale a revisar el mensaje que finalmente se publica.
La organización puede implantar un adaptador que compruebe una autorización autenticada antes de invocar start_thread o update_thread. Debe impedir rutas alternativas que permitan el envío directo con la misma identidad de servicio. Una ventana de confirmación que el agente puede eludir no constituye una barrera efectiva. El adaptador y la revisión son controles propuestos para la arquitectura del caso; no se atribuyen al servidor del repositorio.
| Comprobación previa | Criterio del caso docente | Evidencia que se conserva |
|---|---|---|
| Persona autorizada | El aprobador tiene atribuciones para ese canal y finalidad | Identificador interno y versión de la asignación de funciones |
| Propuesta revisada | Texto, destino, herramienta, hilo y menciones coinciden con lo aprobado | Referencia de la propuesta y huella del conjunto de datos aprobado |
| Vigencia | La autorización no ha caducado ni ha sido consumida | Fecha de decisión, expiración y estado del permiso de ejecución |
| Ejecución | La llamada se vincula a la aprobación y al resultado | Identificador de correlación, herramienta e identificador de mensaje retornado |
La huella ayuda a detectar cambios, pero no autentica por sí sola a una persona. Su utilidad depende de que el registro y la comparación estén protegidos. Una firma criptográfica puede formar parte del diseño; no se presenta como una exigencia universal de ISO/IEC 42001.
Pruebas de rechazo antes de autorizar el uso
Se ensayan cinco situaciones con datos sintéticos: llamada sin aprobación, texto modificado después de revisar, canal diferente, autorización caducada y repetición de una autorización ya consumida. En este diseño, todas deben impedir un segundo envío o un envío no autorizado. Se conserva la entrada, la decisión del control y la comprobación de que no hubo publicación.
Si se pierde la respuesta después de enviar, el estado es incierto: no debe asumirse ni éxito ni fracaso. Antes de reintentar se contrasta el destino y la evidencia disponible, para evitar duplicados. Este comportamiento debe resolverlo la integración; no se presume una garantía nativa de idempotencia.