Inyección de prompts en cabeceras HTTP: audita tu lector web

La inyección de prompts en cabeceras HTTP llega a un agente de selección cuando su lector de URL transmite al modelo metadatos controlados por el servidor. Para auditar ese límite, inspecciona los resultados exactos de la herramienta cuando una página se carga correctamente, hay una redirección o se produce un error. Conserva la procedencia del material de cada fuente, excluye los metadatos innecesarios y controla el acceso a los datos de candidatos y los permisos de escritura fuera del modelo.

Imagina que pides a un asistente que compare el portafolio de un candidato con tus criterios de evaluación para ingeniería backend. La página describe proyectos. En algún punto de la respuesta, su servidor también declara una puntuación para el candidato. Tu equipo necesita saber si esa afirmación entra en el contexto del asistente, si aparece en el resumen y si puede acabar convertida en una evaluación registrada.

Son preguntas distintas. Una captura del navegador no responde a ninguna. Lo que conviene revisar es el contrato entre la herramienta que recupera la página y el modelo: qué campos cruzan ese límite, de dónde proceden y qué ocurre cuando algo falla.

¿Qué descubrió realmente el estudio sobre cabeceras HTTP?

La investigación de Signals Corps, publicada por Sarah Andrews el 6 de octubre, examinó 217 097 223 respuestas de Common Crawl mediante un muestreo de uno de cada diez archivos de metadatos WAT. Clasificó 7 959 nombres de host como emisores de cabeceras dirigidas a la IA, en su mayoría referencias a recursos; 30 contenían intentos de inyección. Dos incluían una supuesta puntuación de adecuación del candidato. Se observaron esas cadenas de texto; no se demostró que hubieran comprometido procesos de selección.

La clasificación se realizó con un agente de investigación de Claude. CCBot no ve el contenido que solo se muestra a determinados agentes. En otros experimentos con marcadores de prueba, las configuraciones de Claude evaluadas rechazaron las instrucciones por defecto; los prompts que otorgaban autoridad a las instrucciones del servidor hicieron aparecer la palabra clave solicitada en siete de nueve ejecuciones. Cada combinación de modelo y prompt se ejecutó una sola vez. Eso no constituye una tasa general de éxito. La conversación en Hacker News dio visibilidad al trabajo; los comentarios no acreditan hallazgos adicionales.

El anuncio de publicación de Common Crawl confirma de forma independiente que el rastreo utilizado contenía 2 170 millones de páginas de 40,4 millones de hosts, recopiladas del 4 al 17 de septiembre. Eso corrobora el tamaño del conjunto de datos, no la clasificación de las cabeceras. Ninguna de las dos fuentes establece con qué frecuencia tienen éxito los ataques en sistemas de selección en producción.

No dividas los nombres de host distintos señalados entre el número de respuestas de páginas para obtener un porcentaje de sitios web. Son unidades diferentes. Un nombre de host tampoco identifica a un candidato, al titular de un dominio registrado ni a un cliente. El estudio sirve para identificar qué conviene auditar sin insinuar que los candidatos han comprometido decisiones de contratación de forma masiva.

Sigue la respuesta hasta el modelo

La respuesta a una URL incluye un estado, cabeceras que describen la respuesta y un cuerpo con la página o el documento. Tu adaptador decide qué recibe el modelo. Revisa esa decisión tanto en el código ejecutable como en los resultados reales capturados a la salida de la herramienta.

Empieza por un flujo en producción. Anota el nombre de la herramienta, la versión del adaptador, el proveedor de extracción, el proveedor alternativo y las acciones disponibles después de la consulta. A continuación, recupera una página que controles e inspecciona el resultado justo cuando entra en el contexto del modelo. Si inspeccionas la respuesta del proveedor en un punto anterior, puedes pasar por alto cambios posteriores de formato, resúmenes o tratamientos de excepciones.

Un contrato de salida útil especifica los campos permitidos, sus tipos, sus longitudes máximas y su significado. También distingue el texto extraído de la fuente del estado generado por la aplicación. Por ejemplo, el título de una fuente sigue siendo una afirmación suministrada por una página externa. Darle un campo propio en JSON facilita rastrear su origen; no le otorga autoridad.

Identifica todas las vías de acceso a una misma URL

El lector habitual puede devolver Markdown extraído. Una herramienta de depuración puede devolver detalles de red. Una alternativa puede devolver los fragmentos destacados de un proveedor de búsquedas. Si el agente puede elegir otro lector tras un fallo, esa vía también forma parte de la auditoría.

Comprueba qué ocurre cuando la fuente devuelve un PDF, un tipo de contenido poco habitual, una página de acceso bloqueado o una solicitud de inicio de sesión. Revisa por separado las respuestas en caché y las recién obtenidas si tienen formatos distintos. Registra si una redirección cambia la dirección de origen que se muestra. La misma URL solicitada puede aportar información sustancialmente distinta según la vía utilizada.

La implementación de referencia de fetch de MCP en la revisión examinada por la investigación ofrece un ejemplo concreto para estudiar la extracción y el tratamiento de errores. Inspecciona la versión exacta que tienes en producción antes de afirmar qué devuelve. El nombre de una herramienta no basta para demostrar cómo se comporta.

Separa la extracción de la confianza

Eliminar las cabeceras sin procesar reduce una de las vías de entrada. El cuerpo de la página puede seguir conteniendo instrucciones, afirmaciones falsas o material irrelevante. Nuestro artículo sobre inyección de prompts en currículums aborda el problema del contenido de los documentos; esta auditoría examina los mecanismos que los recuperan.

Etiqueta el texto externo como material no fiable y explica en las instrucciones del agente para qué puede utilizarse. Después, pon a prueba ese límite. Los delimitadores, la serialización JSON y los recordatorios ayudan a organizar el contexto, pero ninguno garantiza que un modelo rechace siempre las instrucciones incrustadas.

Prueba las respuestas correctas, las redirecciones y los errores

Usa candidatos ficticios e infraestructura que controles para probar por separado qué texto llega al modelo y cómo se comporta este. Examina la entrada capturada del modelo para comprobar si cada marcador ha cruzado el límite de la herramienta. Determina si se ha seguido la instrucción por el comportamiento solicitado: citar un marcador mientras se rechaza la instrucción no equivale a cumplirla.

Crea un portafolio ficticio con una descripción breve y estable de un proyecto. Coloca un marcador único en el cuerpo y otro distinto en una cabecera de respuesta personalizada. Ejecuta primero esta prueba de referencia sin instrucciones y, después, dos variantes separadas: una con una instrucción inocua en la cabecera personalizada y otra con esa misma instrucción en el cuerpo. Pide que la respuesta del asistente sea un tercer marcador. Mantén los mismos datos del candidato en todas las variantes para identificar los cambios atribuibles al canal de respuesta.

La tabla siguiente propone un plan de auditoría; no recoge pruebas realizadas contra Kit ni contra un proveedor.

Conserva el resultado esperado y el real de cada caso. Si se supera la comprobación de visibilidad de cabeceras, debe quedar claro qué campo se ha omitido. Si se supera la comprobación de acciones, debe identificarse el control de la aplicación que ha rechazado la operación propuesta. «La respuesta parecía correcta» deja demasiadas preguntas abiertas.

Define también un contrato para la salida de errores

Los errores suelen prepararse para los desarrolladores y después se reenvían a los modelos sin revisión. Una excepción puede contener una respuesta del proveedor, un mensaje de un sistema anterior de la cadena o una URL de destino. Un resultado correcto con campos muy restringidos dice poco sobre esos otros campos.

Devuelve una categoría de error predefinida y el contexto suficiente para un reintento autorizado. Mantén los diagnósticos detallados en un canal operativo con las restricciones de acceso adecuadas. Si el modelo necesita un fragmento del error suministrado por la fuente, identifícalo como material de esa fuente y aplícale los mismos límites que al texto extraído habitual.

Prueba tanto el fallo inicial como la vía alternativa. Por ejemplo, el lector principal puede omitir las cabeceras mientras que el secundario incorpora un volcado de diagnóstico. Repite esta matriz cuando cambies un adaptador, un proveedor de extracción o el formato de las excepciones. Guarda las versiones pertinentes junto con los resultados para que quienes los revisen en el futuro sepan qué cubren las pruebas.

Reproduce las rutas reales sin usar datos de candidatos reales

Usa la configuración habitual de las peticiones del agente al comprobar los casos controlados. Si el componente que recupera las páginas en producción tiene un agente de usuario específico o solicita Markdown, reproduce esa configuración en la prueba. Un navegador normal puede recibir una respuesta distinta.

No incluyas currículums reales, credenciales ni enlaces firmados de candidatos en una prueba con marcadores. No instales paquetes ni conectes herramientas sugeridas por el caso de prueba. El objetivo es comprobar si el sistema cruza un límite; el contenido ficticio e inocuo basta para detectar ese fallo.

El texto recuperado no puede decidir sobre la contratación

Un portafolio puede aportar pruebas sobre el trabajo realizado. No puede fijar tus criterios de evaluación, establecer una puntuación de adecuación verificada ni conceder acceso a los registros de otro candidato. Conserva esa distinción tanto en el resumen como en la aplicación que lo almacena.

En la revisión hipotética para backend, el asistente podría encontrar un repositorio público que describe un proceso que ejecuta tareas de una cola. Una nota aceptable identifica la fuente y aclara qué permite afirmar: el portafolio describe trabajo con procesamiento de colas, pero sigue sin verificarse si el candidato asumió la responsabilidad operativa. El reclutador puede entonces formular una pregunta concreta en la entrevista.

Una puntuación sin respaldo nunca debe convertirse en la evaluación del reclutador sin que este lo advierta. Exige una justificación vinculada a un criterio y pruebas rastreables para cada valoración sustantiva. Las afirmaciones del candidato deben distinguirse de los juicios de quien lo evalúa. En el flujo de trabajo del perfil del candidato, esa distinción debe seguir siendo comprensible para quien revise el registro.

Esto también se aplica cuando la instrucción de la fuente no provoca ninguna llamada a una herramienta. Un asistente con acceso de solo lectura puede exagerar la experiencia, omitir dudas o presentar una descripción del propio candidato como una verificación independiente. Audita la fidelidad de las respuestas junto con las escrituras. Compara los resúmenes de los distintos casos de prueba y pide a los revisores que identifiquen qué afirmaciones respaldan realmente las fuentes.

La guía de OWASP sobre inyección de prompts respalda el uso de controles por capas: privilegios limitados, separación del contenido no fiable, aprobación humana de acciones con consecuencias importantes y pruebas con ataques simulados. Aplica esos controles según las consecuencias de la operación. Un borrador de resumen y el rechazo de un candidato requieren permisos distintos.

Conserva el origen sin crear un archivo de datos sensibles

Registra la identidad de la herramienta, la URL solicitada, la URL final cuando esté disponible, la categoría de respuesta, los nombres de los campos expuestos y la siguiente acción propuesta. Incluye la hora de extracción y la información de versiones suficiente para reproducir el comportamiento del adaptador. Si no puedes determinar el destino final, deja constancia explícita de esa incertidumbre.

Da preferencia a registros estructurados con límites definidos y a ejemplos ficticios con los datos sensibles ocultos, en lugar de volcados completos de las respuestas. Los registros habituales no deben recopilar cookies, valores de autorización, enlaces firmados ni datos personales de candidatos. Conocer el origen ayuda a los revisores a establecer de dónde procede una afirmación; registrar demasiado crea otro lugar donde proteger material sensible.

El registro de la fuente debe conservarse en los resúmenes posteriores. Si un segundo modelo condensa las notas de investigación, mantén la asociación entre cada afirmación y las pruebas que la respaldan. De lo contrario, un primer resumen prudente puede convertirse después en una afirmación tajante sin fundamento.

Comprueba la siguiente acción y audita el ejemplo concreto de Kit

La aplicación debe decidir si una acción propuesta está permitida según la autoridad del usuario autenticado, el ámbito de su cuenta, el destino y la finalidad. El texto recuperado de un sitio web no puede ampliar ninguno de esos permisos.

Un enlace a un servidor MCP puede ser documentación útil. Conectarse a ese servidor añade una capacidad nueva y requiere una autorización propia. Una página que pide al agente enviar datos de candidatos a otro lugar ha hecho una petición, no ha concedido permiso. Comprueba el destino propuesto y el alcance de los datos antes de transmitirlos, aunque el resumen anterior parezca razonable.

El acceso a las herramientas debe corresponderse con la tarea. Una fase de investigación puede necesitar leer fuentes y guardar un borrador. Mover una candidatura, contactar con un candidato o exportar registros requiere una decisión de autorización independiente. La referencia de herramientas MCP de Kit resulta útil para elegir integraciones, pero que una acción esté disponible mediante MCP no establece por sí solo el permiso para ejecutarla.

El adaptador de Outreach de Kit es un ejemplo acotado

La inspección estática realizada para este artículo encontró una implementación pertinente en el adaptador de recuperación web de Outreach de Kit. Es un ejemplo de investigación de prospectos, no una prueba de que Hiring disponga de una función de consulta de portafolios ni una prueba de seguridad de extremo a extremo.

El adaptador lee la URL de origen almacenada para un prospecto y comprueba si es una URL pública segura. Puede utilizar los campos del perfil guardados o intentar la extracción con Cloudflare y, después, con Exa. En la vía habitual de Cloudflare, el resultado que ve el modelo contiene una URL y texto extraído en lugar de una respuesta HTTP sin procesar. Cuando Exa responde correctamente, devuelve una URL, un título, fragmentos destacados y texto.

Cloudflare describe su endpoint de Markdown como una herramienta de extracción de contenido de páginas. Esa transformación no demuestra que se neutralice la inyección de prompts. El texto extraído sigue siendo material de terceros. La inspección estática también detectó que el tratamiento de fallos de Exa puede incluir un mensaje de excepción, cuya salida merece una revisión específica.

Estas observaciones señalan una auditoría concreta que realizar: capturar los resultados reales cuando el proveedor responde correctamente, se recurre a una alternativa, hay redirecciones o se producen fallos; después, probar las acciones posteriores permitidas. No demuestran que se excluyan todas las cabeceras en todo el sistema ni que Kit sea inmune a la inyección.

Antes de ampliar las facultades del agente en tu integración, prepara el contrato de recuperación web para su revisión. Conserva un pequeño conjunto de casos ficticios junto al adaptador, registra qué llega al modelo y verifica quién autoriza la siguiente acción. Así, tu equipo de selección tendrá pruebas que examinar cuando cambie una fuente, falle un proveedor o el asistente proponga algo con consecuencias importantes.