HomeMarketingLas herramientas WebMCP que expone a los agentes se pueden utilizar para...
spot_img

Las herramientas WebMCP que expone a los agentes se pueden utilizar para secuestrarlos

spot_img

Agregue WebMCP a su sitio web y entregará a los agentes de IA visitantes un conjunto de herramientas con nombre para llamar. Esas mismas herramientas pueden usarse para poner a los agentes en contra de las personas que los enviaron. El sitio para desarrolladores de Chrome ahora incluye guías de seguridad para WebMCP, y gran parte de ella está escrita para los sitios web que exponen las herramientas en lugar de para las empresas que crean los agentes. Prepare su sitio web para el agente con WebMCP y también habrá abierto una superficie de ataque, y cerrarla es su trabajo, no el del agente.

Durante dos años, la conversación sobre la preparación de los agentes ha girado en torno al acceso: ¿puede un agente acceder a su contenido, leer su página y finalizar el pago? WebMCP es la versión en la que deja de esperar que un agente descubra su sitio web a partir del marcado y comienza a entregarle herramientas con nombre para llamar. Ése es el protocolo más útil y es la dirección en la que se mueve la capa de protocolo de la web agente. También es donde ser legible para un agente y ser seguro para un agente dejan de ser la misma propiedad.

Chrome nombró dos formas en que los agentes son secuestrados a través de WebMCP

La guía de seguridad del agente de Chrome describe dos vectores de ataque, y ambos llegan a través de las herramientas que expone un sitio web. El primero es el manifiesto malicioso. En palabras de Chrome, “los sitios web pueden tener definiciones de herramientas con instrucciones ocultas, en nombres, parámetros o descripciones de herramientas, diseñadas para secuestrar al agente”. La descripción de una herramienta es un texto que el agente lee para decidir cómo usar la herramienta, por lo que una descripción puede contener una instrucción que el agente nunca debió seguir.

Leer  Los compradores B2B eligen un proveedor antes de comunicarse: tres formas de ser visible cuando es necesario

El segundo vector es el que atacan la mayoría de los sitios web y no necesita ningún sitio web malicioso. Chrome lo llama resultado contaminado: “Las respuestas de herramientas en tiempo real de sitios que de otro modo serían confiables pueden incluir instrucciones maliciosas como parte de datos de terceros, como comentarios de usuarios”. Una herramienta en su propio sitio web que devuelve reseñas de productos, hilos de comentarios, publicaciones en foros o respuestas de soporte está devolviendo texto que escribieron otras personas. Si una de esas personas colocó una instrucción dentro de una reseña, su herramienta legítima se la entregó al agente como si viniera de usted. La carga útil es tu propio contenido generado por el usuario y tú lo invitaste a participar.

Esto funciona debido a algo que no es un error y no será parcheado. “Los LLM tratan todo el texto, las instrucciones y los datos del usuario como una secuencia única de tokens”, dice la guía, por lo que el modelo no puede separar de manera confiable la parte que usted entendió como datos de la parte que un atacante entendió como un comando. Por eso Chrome dice que “la naturaleza probabilística de los LLM hace imposible garantizar la seguridad dentro del propio modelo”. Este es el mismo problema de inyección rápida que no tiene una solución clara dentro del modelo, que ahora lleva un protocolo. WebMCP le brinda a ese ataque una ruta de entrega limpia y estructurada a través de las herramientas que publicó específicamente.

Hacer que un sitio web esté listo para los agentes ahora incluye hacerlo seguro para los agentes

La guía de Chrome impone la obligación al sitio web, no sólo al agente. El documento de seguridad de herramientas de Chrome se abre con una línea dirigida directamente a quien expone las herramientas: “Exponga sus herramientas sólo a orígenes en los que confíe. Esto es particularmente importante cuando las herramientas administran los datos del usuario o impactan al usuario de otra manera”. Esa línea está escrita para quien envía la herramienta. Eso significa usted.

Leer  Cómo construir un marco de experimentación que escale

Las defensas son concretas y son anotaciones que adjuntas a las herramientas que envías. untrustedContentHint “etiqueta explícitamente la carga útil como no confiable, para ayudar a proteger la integridad de su sitio y al mismo tiempo proporciona una señal al agente de que estos datos requieren un mayor escrutinio”, y Chrome dice cuándo usarlo: “Si una herramienta devuelve contenido generado por el usuario (UGC) o datos de origen externo, considere agregar untrustedContentHint a la herramienta”. readOnlyHint marca una herramienta que no cambia de estado, lo que “permite al agente tomar mejores decisiones sobre cuándo solicitar confirmaciones al usuario”. exposedTo restringe una herramienta a una variedad de orígenes en los que confía, escritos en el registro mismo:

document.modelContext.registerTool({...}, {
 exposedTo: ('https://trusted.com')
});

Chrome también limita el presupuesto de caracteres, una descripción de herramienta a 500 caracteres y una salida de herramienta única a aproximadamente 1500, y agrega un requestUserInteraction() ruta para confirmar una acción antes de que se active. Tomemos el ejemplo obvio, una herramienta que muestra reseñas de productos a un agente de compras. Asegurarlo no es un trabajo exótico: marque su salida con untrustedContentHintcolocar readOnlyHint porque lee en lugar de comprar, y limita exposedTo a los orígenes a los que realmente sirves. Nada de eso es trabajo del agente. Es el trabajo del autor de la herramienta, que en la mayoría de los equipos es el personal web, CRO o marketing que agrega WebMCP para que parezca actual, no el personal de seguridad que lee los modelos de amenazas. Esa brecha es donde esto sale mal. Marcar cuál de su contenido son datos y no comandos ahora es parte del envío de una herramienta, de la misma manera que desinfectar la entrada se convirtió en parte del envío de un formulario.

Leer  Los documentos del rastreador de OpenAI ahora incluyen OAI-AdsBot para anuncios ChatGPT

Adopte WebMCP, pero primero modele cada herramienta contra amenazas

Entregarle a un agente herramientas explícitas e invocables es mejor que hacerle adivinar su sitio web desde el DOM, y vale la pena tener esa capacidad. Nada de esto es motivo para evitar WebMCP. El punto es más limitado y aburrido que “nuevo protocolo, nuevo peligro”: la capacidad llega con una factura adjunta, y la factura es suya.

Entonces la línea es simple. No exponga una herramienta a un agente que no haya modelado contra amenazas de la misma manera que lo haría con un punto final de API pública. Para cada herramienta que esté a punto de registrar, responda una pregunta antes de enviarla: ¿Qué contenido no confiable puede devolver? ¿Lo ha marcado? Si no puede responder a eso, la herramienta no está lista, por muy listo que parezca el resto de su sitio web para el agente.

WebMCP es temprano. Se encuentra en una prueba de origen de Chrome, la especificación aún se está moviendo y la mayoría de los sitios web no han expuesto una sola herramienta. Esa es la ventana para decidir que la seguridad del agente es parte de la preparación del agente, antes de que la primera herramienta que envíe resulte ser la que le entrega al agente sus reseñas y todo lo que alguien escondió en ellas.

Más recursos:


Esta publicación se publicó originalmente en No Hacks.


Imagen de portada: Roman Samborskyi/Shutterstock

spot_img
ARTÍCULOS RELACIONADOS

LEAVE A REPLY

Please enter your comment!
Please enter your name here
https://www.cotillon-de-fete.fr/gambling/

https://www.cotillon-de-fete.fr/bonus-casino-acceptant-les-joueurs-belges/

Más popular

spot_img