Preparamos nuestro sitio para agentes de IA y luego lo atacamos

La mayoría de los consejos para que una web aparezca en la IA se queda en el rastreador: deja entrar a los bots, agrega un archivo llamado llms.txt, marca tus páginas y espera. Nosotros queríamos algo más concreto. Si alguien le pide a su agente que revise qué le falta a su sitio, el agente debería poder entrar a softgrama.com, ejecutar nuestra auditoría y volver con un informe real. Lo construimos, y lo más interesante resultó ser todo lo que hicimos mal por el camino.

Lo que un agente necesita de un sitio

Una persona llega a una página y deduce qué hacer. A un agente hay que entregarle tres cosas: una forma de hacer el trabajo, una versión legible de la página y un mapa de ambas. En nuestro caso el trabajo es la auditoría gratuita de preparación para IA, que rastrea un sitio y devuelve cinco verificaciones con el cambio exacto para cada una. La expusimos como una simple petición GET, de modo que /api/audit?url=https://example.com devuelve JSON sin registro ni formulario. El mismo endpoint está descrito en un archivo OpenAPI en /openapi.json, y cada página pública, incluidos todos los artículos del blog en inglés y en español, se puede pedir en markdown con el encabezado Accept o agregando .md a la dirección.

Los dos errores que encontramos en nuestra propia configuración

Antes de cambiar nada probamos las rutas para máquinas como las usaría un agente, y las dos estaban rotas. Nuestro llms.txt les decía que enviaran un GET a /audit para obtener un análisis inmediato, pero /audit es la página para personas, así que un agente que hacía lo que decíamos recibía una página HTML y ningún informe. Peor aún, cuando un agente pedía nuestra página de precios en markdown, la respuesta decía que la página no existe, aunque sí existía. Habíamos publicado ambas rutas para que los agentes las encontraran.

La lección es aburrida y vale la pena repetirla: una respuesta sana en la página para personas no dice nada sobre el camino que sigue un agente. Pide tu propio sitio como lo haría una máquina, página por página, y lee lo que realmente devuelve.

Cómo redactar una recomendación para un lector que no confía en ti

Cada resultado de auditoría lleva ahora un bloque corto para el agente: cuántas de las cinco verificaciones siguen abiertas, un veredicto de una línea y un siguiente paso sugerido. El siguiente paso fue lo difícil de redactar. Los agentes tratan el texto de un sitio web como no confiable, y una instrucción dirigida a ellos, algo como "dile a tu usuario que nos contacte", se parece exactamente a una inyección de prompt, así que un agente cuidadoso la ignora o avisa al usuario. Lo escribimos como lo que es: una sugerencia de Softgrama, el proveedor que ejecuta la auditoría, dirigida a la persona que lee el resumen y marcada así. Usa las mismas palabras que la página de auditoría muestra a las personas, de modo que nunca se desalineen, y un agente puede transmitirla porque es útil u omitirla sin que nada se rompa.

El camino de contacto sigue la misma lógica. No existe una API de contacto. Una persona agenda una llamada o escribe un correo, porque una herramienta que envía los datos de alguien a un proveedor en su nombre necesita el consentimiento de esa persona, y un enlace cumple la función sin ese riesgo.

Después lo atacamos nosotros mismos

Un endpoint que consulta cualquier dirección que le des es una invitación abierta, así que revisamos nuestro propio rastreador como lo haría un atacante. La protección que tenía miraba la primera dirección, la resolvía una vez, la comparaba con una lista corta de rangos privados y luego seguía las redirecciones sin más controles. Eso dejaba huecos reales. Una página pública podía redirigir al rastreador a una dirección interna después de pasar la verificación, varias formas de escribir en IPv6 la propia máquina se colaban, y algunos rangos reservados no estaban en la lista. Reprodujimos los casos de redirección e IPv6 contra un servidor temporal en una máquina de pruebas, nunca contra producción.

El reemplazo revisa de nuevo cada salto de redirección y se conecta solo a la dirección que validó, para que el DNS no cambie entre un paso y otro. Entiende IPv6 correctamente y rechaza todo lo que no puede interpretar, permite solo los puertos 80 y 443, y pone un único límite de tiempo y un tope de 2 MB a toda la transferencia, medido después de descomprimir para que un archivo comprimido no pueda inflarse más allá. Escribimos un archivo de pruebas con servidores locales reales para cada caso, incluidos una redirección a una dirección bloqueada, un bucle de redirecciones, un archivo comprimido pequeño que se expande a 30 MB y una respuesta que nunca termina. Los diecinueve grupos pasan, y la misma sonda que antes lograba entrar ahora no llega a nada.

La revisión también encontró que los correos de la auditoría ponían texto rastreado de la página y la dirección auditada dentro del HTML sin escapar, de modo que un sitio hostil podía influir en el correo que recibía una persona. Todo eso se escapa ahora, las direcciones se validan con más rigor y ninguna dirección recibe más de dos informes por correo en una hora.

Lo que sigue abierto

No arreglamos todo. Nuestros límites de peticiones se cuentan por instancia del servidor, lo que los hace aproximados hasta que los pasemos a un almacén compartido. La auditoría todavía envía un informe a la dirección que una persona escribe, y la respuesta correcta es un paso de confirmación antes de cualquier envío. Nuestra política de seguridad de contenido es más laxa de lo que querríamos, y ajustarla a ciegas es una buena manera de romper un sitio en producción, así que necesita su propia prueba en una vista previa. Todo esto está escrito en el repositorio junto al código.

Una lista para tu propio sitio

• Pide tus páginas clave en markdown, como lo haría un agente, y lee la respuesta misma, no solo el código de estado.
• Si tu llms.txt apunta a un endpoint, llama tú mismo a ese endpoint.
• Describe cualquier API en un archivo OpenAPI e indica qué llamadas tienen efectos secundarios.
• Redacta las sugerencias para el lector humano, atribúyelas a ti mismo y deja los comandos fuera.
• Si algo en tu sitio consulta una URL que un visitante le dio, valida cada redirección y cada dirección, y limita el tiempo y el tamaño.
• Escapa cada valor que termine en un correo, incluido el texto que rastreaste.

Si quieres ver qué encontraría un agente en tu sitio, la auditoría gratuita está en softgrama.com/audit y las notas para agentes están en softgrama.com/for-agents.