Entrevista de Frontend: ¿Cómo expondrías herramientas WebMCP de forma segura a agentes de navegador?

Pregunta

Una página de pago de comercio electrónico quiere probar WebMCP para que un agente de navegador pueda filtrar productos y completar formularios. ¿Cómo definirías las herramientas, limitarías los permisos, preservarías el control del usuario y verificarías que el agente no invoque acciones de alto impacto de manera incorrecta?

Contexto y límites

WebMCP es una propuesta de estándar web. La documentación de Chrome describe herramientas declarativas de formularios HTML y herramientas imperativas de JavaScript, y Chrome 149 proporciona una prueba de origen (origin trial). Esta pregunta trata sobre la mejora progresiva en una pestaña del navegador con un humano en el bucle (human in the loop). WebMCP no se presenta como un protocolo de backend estable que se ejecuta sin el contexto de un navegador, ni como un reemplazo de la autorización del lado del servidor.

Aclara primero: ¿Qué acciones solo buscan y completan, y cuáles realizan un pedido o cobran dinero? ¿Deberían las herramientas ser visibles únicamente para la página de nivel superior o también para un iframe de origen cruzado? ¿Debe el usuario confirmar nuevamente antes del envío final? ¿Qué sucede cuando el agente no admite WebMCP o finaliza la prueba de origen?

Qué está evaluando el entrevistador

El entrevistador está evaluando si puedes convertir la actuación del agente en un contrato de frontend: descripciones claras de herramientas y esquemas de entrada, inicio de sesión existente, CSRF, autorización de negocio y confirmación del usuario aún presentes en la ruta, exposición de origen cruzado con privilegios mínimos y evaluaciones para la elección de herramientas, parámetros y resultados.

Respuesta de 30 segundos

Divide el flujo en acciones de solo lectura, reversibles e irreversibles. Utiliza herramientas declarativas o imperativas para buscar y completar, mientras que el envío de pedidos mantiene la autorización del servidor y la confirmación explícita. Expón solo los campos necesarios, establece como valor predeterminado la página y el origen actuales, y exige una Permissions Policy explícita para los iframes de origen cruzado. Antes del lanzamiento, evalúa la selección de herramientas, la validación de parámetros, el manejo de errores y las rutas de rechazo, manteniendo al mismo tiempo la interfaz de usuario habitual como mecanismo de respaldo.

Análisis detallado paso a paso

1. Niveles de riesgo: search, filter y fill son de bajo riesgo o reversibles; place-order, pay y los cambios de dirección son de alto impacto y no deben ejecutarse automáticamente solo porque un agente disponga de una herramienta.
2. Contrato: cada herramienta recibe un nombre estable, una descripción orientada al agente, un esquema de entrada JSON y un resultado estructurado. Las enumeraciones, los rangos, la moneda y las versiones de inventario se validan tanto en el cliente como en el servidor.
3. Reutilizar la lógica de negocio: la devolución de llamada (callback) invoca el estado del formulario existente y las funciones de dominio en lugar de copiar una ruta de solicitud que eluda la interfaz de usuario. Antes de la ejecución, verifica el inicio de sesión, CSRF, la versión del carrito, el precio y el inventario.
4. Límite de permisos: expón de forma predeterminada solo a la ventana de nivel superior y a contextos del mismo origen. Comparte con un iframe de origen cruzado solo cuando Permissions-Policy y el atributo allow del iframe lo permitan explícitamente, y no devuelvas datos personales innecesarios.
5. Control del usuario: permite que la búsqueda y el llenado muestren un cambio visible. Requiere una confirmación y un resumen en la página para pedidos, pagos o eliminaciones; el resultado de la herramienta indica si la acción se completó, espera confirmación o fue rechazada.
6. Despliegue progresivo: habilita primero las cuentas internas detrás de un flag local o una prueba de origen. Proporciona detección de capacidades, la interfaz de usuario habitual y un mecanismo de respaldo con automatización del DOM cuando WebMCP no esté disponible; registra la versión de la herramienta, el resultado y el motivo del rechazo.
7. Evaluación y monitoreo: crea un conjunto de tareas para medir la precisión en la elección de herramientas, la tasa de parámetros válidos, la finalización, la invocación falsa, la corrección de rechazos y la cobertura de confirmación. Establece una barrera de cero invocaciones falsas para herramientas de alto impacto y revoca el registro ante anomalías.

Respuesta modelo

Dividiría el proceso de pago en buscar, completar y enviar. Buscar y completar son reversibles, por lo que WebMCP puede mejorar la precisión del agente. El pedido y el pago siguen sujetos a la autorización del servidor existente, verificaciones de precio e inventario, y confirmación en la página. WebMCP es experimental; la prueba de origen de Chrome 149 es adecuada para una validación controlada, no para reemplazar los permisos de backend.

Las herramientas exponen solo los campos necesarios para el flujo actual y reutilizan la lógica de formularios y dominio existente en sus callbacks. El esquema de entrada restringe los ID de artículos, las cantidades y los formatos de dirección; el servidor vuelve a verificar el inicio de sesión, CSRF, el inventario, el precio y la idempotencia del pedido. Por defecto, expongo las herramientas a la página de nivel superior y al agente del mismo origen. Si se requiere un iframe de origen cruzado, configuro tanto la política de permisos como el allow del iframe, y nunca devuelvo el perfil completo de la cuenta.

const controller = new AbortController();

document.modelContext?.registerTool({
  name: "cart_set_quantity",
  description: "Set the quantity of one visible cart item; never submits an order.",
  inputSchema: {
    type: "object",
    properties: {
      itemId: { type: "string", minLength: 1 },
      quantity: { type: "integer", minimum: 1, maximum: 10 }
    },
    required: ["itemId", "quantity"]
  },
  async execute({ itemId, quantity }) {
    const result = await setVisibleCartQuantity(itemId, quantity);
    return { content: [{ type: "text", text: result.summary }] };
  }
}, { signal: controller.signal });

Incluso si existe una herramienta para pedidos, esta devuelve “confirmación del usuario requerida” y no puede cobrar dinero por sí misma. Cada llamada registra la versión de la herramienta, el resultado de la validación de parámetros y el estado de la página. El conjunto de evaluación cubre artículos incorrectos, cantidad excesiva, precio desactualizado, confirmación rechazada y la falta de disponibilidad de WebMCP. Por lo tanto, WebMCP es una mejora progresiva revocable; la autorización de negocio y la intención del usuario permanecen en la ruta existente.

Errores comunes

• Describir una característica de WebMCP en fase de prueba temprana como una API de backend estable.
• Exponer una herramienta universal que pueda pagar, eliminar una cuenta o cambiar cualquier dirección directamente.
• Validar el esquema solo en el navegador y omitir las verificaciones del servidor para inicio de sesión, inventario, precio e idempotencia.
• Compartir herramientas con iframes de origen cruzado por defecto o devolver el perfil de usuario completo como resultado de la herramienta.
• No proporcionar una interfaz de usuario habitual, detección de capacidades, ruta de revocación o un conjunto de evaluación para el agente.

Una respuesta sólida abarca el contrato de herramientas, la autorización del servidor, el aislamiento de origen, la confirmación del usuario, el mecanismo de respaldo y la evaluación cuantitativa. “Agregar descripciones a los botones” no demuestra una actuación segura.

Preguntas de seguimiento y respuestas

¿Por qué no registrar también la realización del pedido como una herramienta WebMCP?

Puedes registrar una herramienta que prepare un resumen del pedido, pero el envío final debe requerir la confirmación en la página y la autorización del servidor. Una llamada de herramienta no demuestra que el usuario haya aceptado pagar y no puede eludir las comprobaciones de precio, inventario o fraude.

¿Cómo restringes la exposición de herramientas a un iframe de origen cruzado?

No la expongas a contextos de origen cruzado de forma predeterminada. Si es necesario, utiliza una configuración explícita de Permissions-Policy y allow del iframe, y luego limita los datos de lectura y escritura en la capa de herramientas. Registra el origen, el ciclo de vida de la página y la revocación.

¿Qué sucede si el agente envía parámetros válidos según el esquema pero inválidos para el negocio?

Rechaza en el cliente los artículos invisibles, el estado desactualizado y los valores fuera del alcance del usuario actual, luego repite la validación de negocio en el servidor y devuelve un rechazo estructurado. No transformes cadenas de texto en acciones arbitrarias ni reescribas parámetros silenciosamente.

¿Cómo demuestras que el agente comprende las herramientas?

Utiliza un conjunto fijo de tareas y páginas reales para medir la elección de herramientas, la tasa de parámetros válidos, la finalización, la invocación falsa y la corrección de rechazos. Establece una barrera de cero invocaciones falsas para el pago y la eliminación, y vuelve a ejecutar las evaluaciones después de realizar cambios en la API.