Prompt y contexto aplicable
Usted es propietario de una plataforma de agentes empresariales. El agente puede invocar sistemas de tickets, control de versiones y finanzas a través de MCP. Algunas herramientas son de solo lectura; otras despliegan código, emiten reembolsos o eliminan datos. Los servidores pueden cambiar con el tiempo, y las descripciones o los resultados de las herramientas pueden provenir de servidores que no son de total confianza. Diseñe el descubrimiento, la autorización, la invocación, el manejo de resultados, la auditoría y la recuperación. Explique qué operaciones requieren aprobación humana.
La pregunta central es si cada llamada tiene una respuesta clara a cuatro preguntas: quién actúa en nombre de quién y dentro de qué alcance, qué versión de la herramienta se utilizó, si se validaron las entradas y los resultados, y si un fallo se puede rastrear y revertir. Las directrices de SDE II de Amazon evalúan explícitamente la confiabilidad, escalabilidad, seguridad y las compensaciones (trade-offs) en el diseño de sistemas, lo que convierte a este en un ejercicio de diseño integral apropiado.
Qué evalúa el entrevistador
Una respuesta sólida separa la capacidad del modelo para proponer una llamada de la autoridad de la plataforma para ejecutarla. El modelo puede sugerir una herramienta y argumentos; un motor de políticas debe autorizar nuevamente utilizando el usuario, inquilino (tenant), recurso, nivel de riesgo y estado de aprobación.
También debe reconocer el límite de MCP. Las anotaciones de herramientas suministradas por un servidor deben tratarse como no confiables; un readOnlyHint no es un hecho de autorización. Los resultados pueden contener datos estructurados, texto, enlaces a recursos o recursos incrustados. Las directrices de la NSA destacan además la invocación dinámica, la confianza implícita y el uso compartido de contexto como riesgos sistémicos.
El entrevistador indagará sobre las rutas de fallo: un catálogo envenenado, un argumento entre inquilinos que supera la validación de esquemas, parámetros modificados tras la aprobación, tiempos de espera (timeouts), efectos secundarios repetidos y una canalización de auditoría no disponible.
Preguntas para clarificar
Primero pregunte sobre los efectos secundarios. ¿Se pueden clasificar por riesgo las consultas, escrituras, despliegues y eliminaciones? Si todas las herramientas son de solo lectura, la aprobación y la recuperación pueden ser más simples; el movimiento de dinero, los cambios en producción y los datos personales requieren controles más estrictos.
Luego pregunte sobre los límites de confianza. ¿Los servidores son administrados por la empresa, alojados por terceros o provistos por el usuario? Si la plataforma no controla un servidor, sus descripciones, anotaciones, texto de resultados y URIs de recursos son datos de entrada, no políticas.
Finalmente pregunte sobre los objetivos de cumplimiento y recuperación. ¿Qué entidades principales, inquilinos y clases de datos se deben registrar? ¿La reversión es una transacción de compensación, una operación inversa o un procedimiento manual? Esas respuestas modifican la retención, el alcance de las credenciales y el diseño del flujo de trabajo.
Estructura de respuesta en 30 segundos
Puede decir:
“Trataría al modelo como un proponente no confiable y colocaría la ejecución detrás de un motor de políticas y un ejecutor aislado. La plataforma registra y versiona cada herramienta, aplica el privilegio mínimo por usuario, inquilino, recurso y efecto secundario, y vincula las acciones de alto riesgo como despliegues, reembolsos y eliminaciones a la aprobación de los parámetros exactos. Las llamadas de solo lectura aún validan entradas y resultados. Antes y después de la ejecución, escribimos eventos de auditoría correlacionados; los resultados no pueden convertirse en la autorización para la siguiente llamada. La idempotencia, los tiempos de espera, los disyuntores (circuit breakers) y la reversión o recuperación manual cubren los reintentos, cambios de servidor, discrepancias de aprobación y fallos parciales.”
Respuesta detallada paso a paso
Crear un catálogo de herramientas consciente de la identidad
Registre la identidad del servidor, el nombre de la herramienta, los JSON Schemas de entrada y salida, la versión del código, el alcance de red y los efectos secundarios reales. Un cambio en el catálogo crea un registro de versión y revisión; las llamadas en tiempo de ejecución solo usan versiones aprobadas. La especificación MCP define nombres, descripciones y esquemas de entrada, y permite esquemas de salida, pero los clientes aún necesitan validación independiente.
Vincular la autorización a una sola invocación
La entrada de la política debe incluir la entidad principal, el inquilino, el recurso, la acción, la clase de datos, el entorno y la versión de la herramienta. La decisión es permitir, denegar o requiere-aprobación, y genera un token de invocación de corta duración. Vincule el token a un resumen criptográfico (digest) de parámetros para que el modelo no pueda cambiar un monto, repositorio o recurso después de la aprobación.
Interpretar anotaciones y descripciones como sugerencias
readOnlyHint y destructiveHint pueden mejorar la clasificación, pero no pueden autorizar la ejecución. Si un servidor afirma ser de solo lectura, la política aún depende del registro revisado y de las capacidades observadas. Textos como “ignore previous instructions” son datos, no una actualización de política.
Ejecutar dentro de un ejecutor aislado
Utilice credenciales de corta duración, egreso restringido y cuotas de recursos. El ejecutor solo recibe argumentos estructurados verificados por la política; no recibe la conversación completa ni los datos de otro inquilino. El texto de las herramientas, los enlaces y los recursos incrustados ingresan primero a una cuarentena de resultados, para luego superar comprobaciones de esquema de salida, tamaño, tipo de contenido y etiquetas de datos.
Hacer que la aprobación sea explícita y vinculada a parámetros
La vista de aprobación muestra la entidad principal, el servidor, la versión de la herramienta, el resumen completo de parámetros, el recurso de destino, el efecto secundario esperado, la expiración y la ruta de revocación. Almacene la aprobación con el resumen de parámetros; cualquier cambio de campo la invalida. Las lecturas de bajo riesgo pueden usar muestreo posterior, mientras que las acciones de alto riesgo requieren aprobación antes de la ejecución.
Manejar reintentos y finalización parcial
Las escrituras llevan una clave de idempotencia derivada de la acción de negocio y la intención de la invocación, no solo un valor aleatorio del modelo. Persista el estado de la solicitud, del resultado y de los reintentos. Ante un tiempo de espera, consulte el estado de ejecución antes de reintentar. Si la compensación no es segura, mueva la acción a una cola humana en lugar de repetir a ciegas un reembolso o un despliegue.
Emitir eventos de auditoría correlacionados
Un evento incluye el ID de solicitud, entidad principal, inquilino, huella digital del servidor, versión de la herramienta, resumen de parámetros, decisión de política, aprobador, resultado de ejecución y el ID de credencial descendente. Almacene argumentos confidenciales únicamente como resúmenes redactados o referencias cifradas. Si el almacenamiento de auditoría no está disponible, las llamadas de alto riesgo deben fallar de forma cerrada (fail closed) o entrar en un estado pendiente en lugar de continuar silenciosamente.
Desplegar y revocar de forma incremental
Valide el catálogo, las políticas y las comprobaciones de resultados frente a servidores sandbox y tráfico espejo (shadow traffic) antes de un despliegue reducido por inquilino o por versión. Mantenga la versión anterior del catálogo y un interruptor de revocación de credenciales. Si detecta escalamiento de privilegios, inyección de prompts o contaminación de resultados, bloquee nuevas llamadas y revoque tokens primero, luego use los eventos de auditoría para manejar los efectos secundarios completados.
Respuesta de muestra de alta calidad
“Dividiría la integración de MCP en capas de catálogo, política, aprobación, ejecutor y auditoría. El catálogo registra huellas digitales de servidores, versiones de herramientas, esquemas y efectos secundarios reales. El modelo puede proponer una llamada, pero el motor de políticas la autoriza por entidad principal, inquilino, recurso y entorno. La aprobación está vinculada a un resumen de parámetros, por lo que cambiar un monto o un destino la invalida. El ejecutor utiliza credenciales de corta duración, redes restringidas y claves de idempotencia. Los resultados se ponen en cuarentena y se verifican en cuanto a esquema, tamaño, tipo de contenido y etiquetas de datos antes de llegar al agente. Cada decisión y solicitud descendente se correlaciona en el registro de auditoría. Los cambios de servidor, tiempos de espera, efectos duplicados y fallos de auditoría cuentan con rutas de denegación, disyuntores y recuperación, validadas mediante sandbox y despliegue gradual.”
Errores comunes
Tratar una anotación como un permiso
Patrón de falla: permitir automáticamente una llamada porque lleva readOnlyHint. Por qué falla: la especificación MCP indica que las anotaciones de servidores no confiables no pueden tratarse como hechos de seguridad. Corrección: use las anotaciones como sugerencias; derive el permiso a partir del registro, la política y las comprobaciones de capacidad en tiempo de ejecución.
Validar solo los argumentos generados
Patrón de falla: ejecutar tan pronto como se supera la validación de JSON Schema. Por qué falla: argumentos bien tipados aún pueden cruzar inquilinos, apuntar a producción o repetir una acción irreversible. Corrección: valide también la entidad principal, la propiedad del recurso, el riesgo, la idempotencia y el resumen de aprobación.
Mostrar solo una aprobación en lenguaje natural
Patrón de falla: pedir al usuario que apruebe “gestionar el reembolso”. Por qué falla: el objeto aprobado es ambiguo, por lo que el monto o la cuenta pueden cambiar en el momento de la ejecución. Corrección: muestre el destino, monto, versión, resumen de parámetros, expiración y vincule la aprobación a ese resumen.
Tratar la salida de la herramienta como instrucciones de confianza
Patrón de falla: concatenar el texto devuelto en el siguiente prompt del sistema. Por qué falla: los resultados pueden contener inyección de prompts, datos de otros inquilinos o URIs maliciosos. Corrección: ponga en cuarentena los resultados, valide tipos, etiquete datos y pase solo los campos mínimos necesarios.
Diseñar únicamente el camino feliz (happy path)
Patrón de falla: reintentar ante cada tiempo de espera y continuar tras cada error. Por qué falla: un estado de ejecución desconocido puede duplicar una escritura, mientras que una finalización parcial puede violar una invariante de negocio. Corrección: diseñe en conjunto idempotencia, consulta de estado, compensación, disyuntores y escalamiento humano.
Preguntas de seguimiento y respuestas
¿Qué sucede si el catálogo de herramientas cambia durante una llamada?
Congele la huella digital del servidor, la versión de la herramienta y los esquemas utilizados por esa llamada. Los cambios en el catálogo afectan únicamente a llamadas nuevas. Si la versión es revocada, el motor de políticas rechaza el token anterior y solicita una nueva aprobación.
¿Qué sucede si el servicio de aprobación no está disponible?
Falle de forma cerrada para acciones de alto riesgo, conservando la propuesta en una cola pendiente. Las lecturas de bajo riesgo pueden continuar bajo una política preaprobada, pero aún emiten eventos de auditoría; un tiempo de espera de aprobación no constituye una autorización.
¿Qué ocurre si un JSON válido contiene datos de otro inquilino?
Un esquema de salida valida la forma, no el alcance de la autorización. Pase el alcance del inquilino y del recurso a nivel descendente y verifique la propiedad, las etiquetas de datos y la cardinalidad de resultados antes de liberar el resultado. Ponga en cuarentena y alerte ante una infracción.
¿Cómo decide si una herramienta puede ejecutarse automáticamente?
Califique la reversibilidad, el radio de impacto (blast radius), la sensibilidad de los datos, el costo de duplicación y la detectabilidad. Las consultas reversibles, de baja sensibilidad y bajo impacto pueden ejecutarse automáticamente; el movimiento de dinero, los cambios en producción, la eliminación y las lecturas entre inquilinos necesitan aprobación humana o un flujo de trabajo dedicado.
¿Cómo investiga una inyección de prompts?
Correlacione la entrada original, la versión de descripción de la herramienta, la propuesta del modelo, la decisión de política, la vista de aprobación, el resultado de la herramienta y las llamadas posteriores mediante el ID de solicitud. Revoque primero el servidor y los tokens afectados, luego reproduzca las decisiones a partir de los registros en cuarentena para identificar los efectos secundarios completados.