Vistas previas del alcance de purga para agentes de IA

Un agente de IA nunca debería pedir aprobación para «vaciar la caché del CDN». Esa frase oculta los únicos datos que un operador necesita antes de autorizar la acción: qué host, qué ruta, cuántas etiquetas y cuánto contenido almacenado podría dejar de servirse.

Una vista previa útil del alcance de purga del CDN convierte la solicitud final en una descripción compacta del radio de impacto. También debe colocar una invalidación dirigida en una clase de riesgo distinta de una operación de purga total. He visto purgas amplias convertir una publicación rutinaria en un incidente de tráfico al origen porque el cuadro de aprobación hacía que un comodín pareciera una ruta inofensiva. La solicitud era pequeña en términos sintácticos. Su efecto no.

El diseño correcto hace más que añadir un cuadro de confirmación. Normaliza la solicitud del proveedor, clasifica su alcance, estima su efecto con una incertidumbre honesta y vincula la aprobación del operador con esos parámetros exactos. Si el agente cambia un host, una ruta, una etiqueta, un entorno o el modo de purga después de la aprobación, la puerta de enlace debe volver a preguntar.

Una solicitud de purga necesita un modelo de impacto

El alcance de una purga de CDN es el conjunto de representaciones almacenadas que el proveedor puede invalidar, no el número de cadenas de una solicitud de API. Un comodín puede abarcar una distribución. Una etiqueta puede referirse a miles de URL sin relación entre sí. Una URL puede tener varias variantes almacenadas porque la caché varía por cadenas de consulta, encabezados, cookies, tipo de dispositivo o idioma.

Esta es la primera distinción que los equipos suelen confundir: el tamaño de la solicitud no equivale al tamaño del efecto. La documentación de Amazon CloudFront deja clara esa diferencia. Una ruta de invalidación con comodín cuenta como una sola ruta enviada aunque invalide miles de archivos. Las unidades de facturación describen la solicitud, no su alcance. Una tarjeta de aprobación que diga «1 ruta» sin indicar que es /* ofrece un dato técnicamente cierto pero inútil para operar.

Modela la acción propuesta en cuatro ejes:

• Objetivo: la cuenta, el servicio o la distribución del CDN, el entorno y el nombre de host.
• Selector: URL exacta, prefijo de ruta, comodín, etiqueta de caché, clave sustituta o indicador de purga total del proveedor.
• Semántica: cómo se combinan los selectores, qué variantes abarcan y si el proveedor invalidará o eliminará los objetos almacenados.
• Consecuencia: el número estimado de objetos o solicitudes afectados, el comportamiento esperado de recarga y si se puede seguir sirviendo contenido obsoleto.

El modelo debe residir en la puerta de enlace de ejecución, cerca de las credenciales y del adaptador del proveedor. No permitas que el agente asigne su propia etiqueta de riesgo. El agente puede proponer una purga, pero el código que entiende la API del proveedor debe calcular lo que significa esa propuesta.

Esta separación importa porque el vocabulario de los proveedores no es uniforme. Fastly llama surrogate key a su etiqueta de agrupación. Google Cloud y Akamai usan etiquetas de caché. Cloudflare admite etiquetas, nombres de host, prefijos de URL, archivos individuales y purga total. CloudFront admite rutas, comodines e invalidación por etiquetas de caché. Una herramienta portátil para agentes puede ofrecer una interfaz ordenada, pero la vista previa debe conservar las reglas reales de coincidencia del proveedor.

Antes de mostrar nada, un componente de ejecución debe resolver alias, normalizar hosts, decodificar y normalizar rutas según las reglas del proveedor, expandir opciones de conveniencia e identificar el entorno efectivo. La vista previa describe entonces la solicitud que se firmará y enviará. Mostrar la entrada anterior y más amable del agente abre una brecha en la que la normalización puede ampliar el alcance sin que la persona lo vea.

La invalidación dirigida y la purga total son acciones distintas

La invalidación dirigida selecciona contenido mediante una URL exacta, una ruta o prefijo acotado, una o más etiquetas o una intersección de selectores compatibles. La purga total descarta el estado útil de todo un servicio, zona o distribución. Tratarlas como dos valores de la misma lista desplegable minimiza la diferencia.

La clasificación debe seguir el efecto, no el nombre del endpoint. Todas estas solicitudes merecen la etiqueta de purga total:

• El indicador explícito purge_everything de un proveedor.
• Una ruta de distribución /*.
• Un comodín o prefijo que se normaliza a la raíz.
• Una etiqueta que, según la convención local, marca todas las respuestas de un servicio.
• Una lista de selectores cuya unión abarca el conjunto de hosts configurados.

Los dos últimos casos requieren metadatos locales. Puede que un proveedor no sepa que release-current aparece en cada objeto de un servicio, pero el sistema de despliegue que aplica la etiqueta puede registrar ese dato. Si la puerta de enlace no puede demostrar que un selector está acotado, debe marcar el alcance como desconocido y elevar el nivel de aprobación. Desconocido es un resultado válido. Tratarlo en silencio como algo pequeño no lo es.

Dirigida no significa segura. Un prefijo /products/ en una tienda grande puede abarcar la mayor parte del tráfico, y una etiqueta tenant:42 puede cruzar varios hosts. La clasificación significa que la solicitud expresa un límite que la vista previa puede mostrar. El operador todavía necesita una estimación de lo que hay dentro.

La purga total necesita un flujo separado tanto visual como mecánicamente. Exige un nombre de acción explícito como purge_all, no un selector vacío que el adaptador interprete como todo. Rechaza campos vacíos de host y ruta en el modo dirigido. Haz que el operador apruebe el entorno de producción y el servicio completo como objetivos identificados. No permitas que una aprobación general de sesión absorba esta acción solo porque el mismo agente hizo antes una purga de URL inofensiva.

Aquí discrepo de una recomendación popular: «Basta con pedir confirmación para cada purga». La repetición enseña a la gente a aprobar la forma de un diálogo, no a leer su contenido. La invalidación de un archivo durante una publicación y la purga de toda una distribución no deben presentar el mismo botón, advertencia ni paso de autenticación. La aprobación humana solo ayuda cuando la interfaz deja clara la diferencia material.

El host, la ruta y el número de etiquetas van sobre el botón

La tarjeta de aprobación debe empezar por el objetivo y el alcance efectivos, porque los operadores leen bajo presión. Coloca primero el proveedor y el entorno de producción; después, el nombre de host, la ruta normalizada, el número de etiquetas, el alcance estimado y la clase de operación. Los detalles secundarios pueden desplegarse debajo, pero los datos que cambian la decisión deben verse sin hacer clic.

Una vista previa independiente del proveedor puede tener esta forma:

{
  "operation": "targeted_invalidation",
  "provider": "example-cdn",
  "environment": "production",
  "hosts": ["assets.example.test"],
  "paths": ["/releases/2026-07-24/*"],
  "tag_count": 2,
  "tag_samples": ["release:842", "asset:bundle"],
  "selector_logic": "host AND path AND (tag OR tag)",
  "estimated_reach": {
    "objects": {"low": 1600, "high": 2300},
    "method": "tag-index snapshot",
    "observed_at": "2026-07-24T14:31:08Z"
  },
  "refill": "origin requests expected on subsequent misses"
}

Esas cifras son ilustrativas, no una promesa de que un CDN pueda contar todos los objetos presentes en sus bordes. Lo importante es la forma de la salida: un intervalo, su método y el momento de observación. Si el estimador no tiene una entrada defendible, devuelve "objects": "unknown" y explica el motivo.

Muestra todos los hosts cuando sean pocos. Para una lista larga, muestra el número y los primeros nombres ordenados, con una forma explícita de inspeccionar el resto. Nunca resumas una lista que mezcla producción y preproducción como «12 hosts». Los límites de entorno pesan más en la decisión que el número.

Las rutas necesitan tanto el valor normalizado como la regla de coincidencia. /picture* y /picture/* no son el mismo selector en Google Cloud CDN: el primero también coincide con rutas como /pictures/dog.jpg y /picture1.jpg, mientras que el segundo permanece dentro del directorio. CloudFront exige que el comodín esté al final para interpretarlo como tal; un asterisco en otra posición es literal. Una vista previa que solo imprime los caracteres sin tratar obliga al operador a recordar la gramática del proveedor en el peor momento.

El número de etiquetas también exige precisión. «2 etiquetas» significa dos selectores, no dos objetos almacenados. Muestra las etiquetas reales salvo que contengan información sensible del inquilino; en ese caso, usa etiquetas redactadas estables y una vista segura de detalles. Indica si las etiquetas se combinan mediante OR o AND. Google Cloud CDN trata varias etiquetas de una solicitud como OR, mientras que combinar filtros de etiquetas con comparadores de host y ruta reduce el resultado mediante una intersección. Esa breve línea lógica suele explicar casi todo el radio de impacto.

El alcance estimado debe admitir lo que el CDN no puede contar

El alcance estimado debe responder «¿cuánto estado de caché podría cambiar?» sin fingir que una caché distribuida es una base de datos de inventario. Los objetos de borde aparecen y desaparecen por caducidad, expulsión, demanda regional y recarga en segundo plano. Muchas API de purga de CDN aceptan un selector pero no devuelven un recuento previo.

Usa la mejor evidencia disponible en un orden fijo. Un recuento reciente del proveedor es lo mejor cuando la API lo ofrece. Después viene un índice de etiquetas propiedad del sistema de despliegue que registre qué URL recibieron cada etiqueta. Luego usa registros de solicitudes o telemetría del estado de caché durante un intervalo declarado. Un catálogo de rutas configuradas puede aportar un límite superior aproximado. Si no existe nada de eso, informa que se desconoce.

Cada estimación debe incluir cuatro propiedades:

• Una unidad, como objetos almacenados, variantes de URL o solicitudes recientes con acierto de caché.
• Una estimación puntual o un intervalo, nunca un entero sin etiqueta.
• Una fuente y un momento de observación.
• Una etiqueta de confianza calculada por código a partir del tipo y la antigüedad de la fuente.

No conviertas el volumen reciente de solicitudes en un número de objetos. «Unas 80.000 solicitudes con acierto de caché en la última hora coincidieron con este prefijo» es una evidencia útil de impacto, pero no significa que se invalidarán 80.000 objetos. Muestra ambas medidas cuando existan: los objetos estimados describen el estado de la caché; los aciertos recientes describen la probable presión de recarga y la exposición de los usuarios.

Incluso para una URL exacta, el alcance puede superar uno. La documentación de CloudFront indica que invalidar un archivo también invalida las variantes almacenadas basadas en cookies o encabezados reenviados. El comportamiento de las cadenas de consulta depende de la configuración y del selector. La vista previa debe decir «1 URL, todas las variantes de cookies y encabezados» cuando ese sea el comportamiento efectivo. Un recuento desnudo de un objeto ocultaría lo que importa.

Para etiquetas, estima la unión, no la suma. Si release:842 abarca 1.700 objetos y asset:bundle abarca 900, los objetos solapados cuentan una vez. Cuando el proveedor aplica etiquetas con OR, sumar ambos recuentos puede exagerar el alcance. Sobreestimar es más seguro que subestimar para un umbral de aprobación, pero aun así desgasta la confianza. Calcula una unión real cuando el índice local lo permita o etiqueta el total como límite superior.

Para una purga total, no pierdas tiempo fabricando una cifra precisa. Di «todo el servicio de producción», muestra el número de hosts configurados y añade el volumen reciente de aciertos de caché como indicador de presión al origen. La clase de acción ya comunica al operador el límite de la caché. La falsa precisión hace que la tarjeta parezca informada sin aportar nada a la decisión.

La vista previa debe exponer las consecuencias de la recarga

Una purga cambia el destino de las solicitudes posteriores, por lo que la aprobación debe describir el comportamiento de recarga además del selector. El riesgo operativo no suele ser que desaparezca el contenido obsoleto. Es una oleada concentrada de fallos de caché que llega a un origen dimensionado bajo el supuesto de que la caché absorbería esas peticiones.

La documentación de Google Cloud recomienda invalidar solo lo necesario porque una invalidación excesiva puede devolver a las instancias o depósitos solicitudes que antes servían las cachés. También dice que hay que confirmar que el origen ya devuelve el contenido correcto antes de solicitar la invalidación; de lo contrario, el CDN podría volver a almacenar una respuesta incorrecta. Ese segundo punto merece ser una precondición del flujo del agente: comprueba el objeto nuevo en el origen antes de proponer la purga.

Fastly establece otra distinción útil entre purga dura y blanda. Una purga dura impide que el contenido almacenado se use en consultas futuras. Una purga blanda lo marca como obsoleto, lo que puede permitir servirlo mientras la caché lo revalida, según la configuración. Fastly no ofrece purga blanda para la purga total. Una aprobación que solo diga «purgar» elimina esta diferencia operativa.

Por tanto, la vista previa debe incluir:

• Si la acción es una invalidación dura, una invalidación blanda o una eliminación propia del proveedor.
• Si se puede servir contenido obsoleto durante la actualización.
• La tasa reciente de solicitudes con acierto de caché para el alcance elegido, si está disponible.
• El origen o grupo de backend que recibirá los fallos.
• Si una comprobación de preparación del origen pasó y cuándo se ejecutó.

Evita promesas como «habrá 2.300 solicitudes al origen». La combinación de solicitudes, la distribución regional, las cachés del navegador, los escudos y las recargas recientes afectan a la carga real. Usa tráfico reciente medido y descríbelo con franqueza: «El alcance seleccionado sirvió 46.000 aciertos de caché durante los 15 minutos anteriores». Eso informa mucho mejor que una predicción inventada.

El agente no debe ejecutar su propia comprobación de preparación mediante un shell sin restricciones y resumir el resultado. La puerta de enlace debe realizar una comprobación definida contra el origen previsto, registrar el estado de la respuesta y la versión del contenido, y adjuntar esa evidencia a la vista previa. De lo contrario, un prompt comprometido puede afirmar que el origen está listo en la misma conversación en la que pide aprobación.

La normalización cierra la brecha entre visualización y ejecución

La puerta de enlace debe aprobar una acción canónica y ejecutar esa misma acción. Si la interfaz muestra una representación y el adaptador del proveedor envía otra, la aprobación es puro teatro.

La canonicalización empieza por campos con tipo. Separa hosts, paths, tags, purge_all, soft, provider, service_id y environment. No aceptes un comando curl libre como objeto de aprobación. El adaptador puede acabar produciendo HTTP, pero el código de política y presentación debe trabajar con datos validados.

Después aplica las reglas del proveedor antes de clasificar. Convierte los nombres de host a minúsculas, elimina el punto DNS final, rechaza credenciales incrustadas, resuelve el alias de servicio y analiza las rutas sin tratar un fragmento como parte de la solicitud. Conserva las mayúsculas y minúsculas de la ruta cuando el CDN las distinga. Aplica la misma normalización de URL o conocimiento de reescritura que use el proveedor. Cloudflare advierte que las purgas por prefijo con Transform Rules necesitan la URL de origen posterior a la transformación. CloudFront aconseja invalidar tanto el URI visto por el usuario como el URI reescrito cuando una función de solicitud cambia la ruta. La vista previa debe mostrar ambas rutas efectivas en lugar de añadir la segunda en silencio.

Una función breve de clasificación puede aplicar los casos peligrosos después de normalizar:

if purge_all is true:
    return PURGE_ALL
if any normalized path covers the root:
    return PURGE_ALL
if any tag is cataloged as service_wide:
    return PURGE_ALL
if selectors are empty:
    return REJECT
return TARGETED

Los adaptadores de proveedores necesitan pruebas construidas a partir de su propia gramática. Incluye rutas raíz, separadores codificados, barras repetidas, barras finales, posición de comodines, matrices vacías, hosts mezclados, cadenas de consulta y URL reescritas. Las pruebas de propiedades pueden afirmar que la normalización nunca amplía el alcance de ejecución más allá del alcance mostrado. Los casos de regresión deben guardar la vista previa normalizada junto a la solicitud saliente exacta.

Por último, calcula un resumen sobre la acción canónica y los metadatos decisivos de la vista previa. El registro de aprobación debe incluir al actor, el proceso del agente, el nombre de la herramienta, los parámetros normalizados, el entorno, la hora de la estimación, el resumen y la caducidad. La AI Agent Security Cheat Sheet de OWASP recomienda vincular la aprobación con la acción exacta mediante el actor, la herramienta, el objetivo, los parámetros normalizados, la hora y la caducidad. Es el criterio correcto. Una decisión humana sobre un resumen no puede autorizar una solicitud posterior con otra ruta.

La aprobación debe cerrarse ante cambios de alcance

Cualquier cambio material después de la vista previa debe invalidar la aprobación. Los campos materiales incluyen proveedor, cuenta, servicio, entorno, host, ruta, lógica de selectores, etiquetas, modo de purga y clasificación dirigida o total. Un cambio solo en la estimación puede no exigir otro aviso, pero cruzar un umbral de impacto configurado siempre debe hacerlo.

Usa una vigencia de aprobación breve porque el estado de caché y el tráfico cambian. Si un agente espera hasta después de otro despliegue, la ruta puede contener objetos distintos y la evidencia de preparación del origen puede estar obsoleta. La caducidad debe obligar a regenerar la vista previa, no limitarse a pedir otro clic sobre datos viejos.

La especificación de herramientas del Model Context Protocol dice que las aplicaciones deben mantener a una persona capaz de denegar invocaciones y presentar avisos de confirmación. Tiene sentido, pero una confirmación genérica es demasiado débil para llamadas destructivas de infraestructura. La aplicación anfitriona puede conocer el nombre de la herramienta y sus argumentos JSON, pero solo el adaptador de ejecución sabe que un alias del proveedor corresponde a producción o que / junto con un comodín significa todo. Coloca la vista previa significativa en el componente que pueda interpretar y hacer cumplir esos datos.

La aprobación también debe ser independiente del texto controlado por el agente. El agente puede aportar una razón, como «retirar la imagen del producto llamado a revisión», pero muéstrala en una zona secundaria claramente identificada como explicación del agente. Genera los datos de alcance mediante código fiable y configuración del proveedor. No admitas Markdown, secuencias de escape de terminal ni HTML arbitrario en ningún campo de la tarjeta.

Las acciones de gran impacto merecen más fricción. Una purga dirigida de una URL exacta puede requerir un clic. Un prefijo amplio puede exigir una confirmación deliberada que repita el alcance. La purga total debe requerir autenticación separada y no heredar la aprobación de la sesión del agente. Sallyport puede mantener la credencial fuera del agente, mostrar una aprobación en cada uso de una clave protegida de la API del CDN y registrar la llamada HTTP resultante; el adaptador del proveedor todavía debe aportar los campos de alcance normalizados para que esa aprobación sea útil.

Los fallos deben cerrar la puerta. Si el estimador agota el tiempo, muestra desconocido en vez de cero. Si falla la normalización, rechaza la solicitud en vez de pasar la entrada sin tratar. Si falla el registro de auditoría, no ejecutes. Si el resumen cambia al enviar, descarta la aprobación y crea una vista previa nueva.

Los registros de auditoría necesitan la decisión y el resultado

Un rastro de auditoría de purga debe conservar lo que vio la persona, lo que envió la puerta de enlace y lo que devolvió el CDN. Registrar solo la solicitud de herramienta del agente no demuestra que la normalización, la aprobación y la ejecución se refirieran al mismo alcance.

Registra la solicitud canónica, los campos mostrados en la vista previa, la fuente de la estimación, el resumen de aprobación, la identidad del aprobador, la hora de aprobación, la hora de ejecución, el identificador de solicitud del proveedor y su respuesta. Marca si el proveedor aceptó, completó, completó en parte o rechazó la operación. Si el proveedor ofrece un estado posterior, añade observaciones de estado en vez de reescribir el evento original.

Mantén la estimación separada del resultado. Una estimación de 2.000 objetos sigue siendo una estimación aunque el proveedor devuelva éxito. La mayoría de las respuestas correctas significan que el proveedor aceptó un selector, no que encontrara exactamente ese número de objetos almacenados. Los auditores deben poder distinguir qué afirmaciones provienen de inferencia local y cuáles del CDN.

La documentación de CloudFront dice que una invalidación no puede cancelarse después del envío porque los puntos de borde empiezan a procesarla con rapidez. Eso hace especialmente importante el registro previo a la ejecución. Un botón de revocación puede detener una futura llamada del agente, pero no recuperar una purga ya distribuida a los bordes. La interfaz de auditoría no debe dar a entender lo contrario.

Para una investigación, estas preguntas deben poder responderse sin leer una transcripción del chat:

• ¿Qué proceso de agente firmado propuso la acción?
• ¿Qué persona aprobó qué resumen canónico?
• ¿La tarjeta clasificó la acción como dirigida o como purga total?
• ¿Qué hosts, rutas y etiquetas aparecían en la tarjeta?
• ¿Qué sabía el estimador de alcance en ese momento?

La justificación conversacional del agente es contexto de apoyo, no autoridad. Los chats pueden truncarse, resumirse o verse influidos por contenido no fiable. El diario de ejecución es el registro duradero de la acción.

Las pruebas contra manipulación importan cuando un proceso autónomo puede hacer llamadas repetidas a infraestructura. Sallyport registra sesiones de agentes y llamadas individuales desde un único registro de auditoría cifrado y encadenado mediante hashes, por lo que un equipo puede verificar la cadena por separado sin leer su contenido. Eso no vuelve reversible una mala purga, pero ofrece a los responsables una secuencia defendible de propuesta, aprobación y ejecución.

Un fallo detallado muestra por qué importan cuatro campos

Imagina un agente que prepara una publicación de una tienda. La tarea pide actualizar los nuevos recursos de productos después del despliegue. El agente ve /products/ en un manifiesto de compilación y elige una purga por prefijo porque es más sencilla que enumerar archivos con hash.

La solicitud sin tratar contiene una ruta. Un diálogo débil muestra «¿Purgar 1 ruta?» y el operador aprueba. El CDN interpreta el prefijo en todos los hosts configurados, incluida la tienda pública, un host regional y un host de imágenes. La ruta también contiene páginas de producto, miniaturas, fragmentos de inventario y recursos de versiones anteriores. Los objetos populares desaparecen juntos de la caché y se recargan desde el mismo grupo de origen.

Una vista previa útil cambia la decisión antes de ejecutar. Muestra:

1. Host: tres hosts de producción, con sus nombres visibles.
2. Ruta: /products/*, descrita como prefijo recursivo en lugar de como un archivo.
3. Etiquetas: ninguna, aunque la versión actual tiene una etiqueta específica.
4. Alcance estimado: 38.000 variantes de URL y 1,2 millones de solicitudes recientes con acierto de caché, ambas con sus fuentes e intervalos.

El operador rechaza la solicitud. El agente propone entonces solo la etiqueta de versión en el host de recursos. La puerta de enlace resuelve 1.840 objetos indexados, indica que dos valores de etiqueta se combinan mediante OR y muestra que la acción excluye el HTML de productos y las respuestas de inventario. La comprobación del origen confirma el identificador de la versión actual. El operador aprueba ese resumen más estrecho.

Las cifras del escenario son ilustrativas; el patrón de fallo es común porque la sintaxis de prefijos parece barata. La solución no es un prompt de agente más inteligente. El límite de ejecución debe hacer legibles los selectores amplios y ofrecer a la persona una alternativa más estrecha.

El mismo patrón detecta otro error: un agente pide purgar preproducción, pero un alias de servicio se resuelve como producción. Si la vista previa solo dice «servicio storefront», el operador puede no verlo. Si empieza por «producción» y enumera los hosts públicos, el desacuerdo queda claro.

Este ejemplo también explica por qué el número de etiquetas no puede sustituir al alcance. Una etiqueta de versión puede identificar 1.840 objetos, mientras que veinte etiquetas de URL exactas pueden identificar veinte. Muestra el número de selectores y las coincidencias estimadas como datos separados. Uno describe la solicitud. El otro describe su efecto probable.

Entrega el límite de seguridad como un contrato ejecutable

Los equipos deben implementar la vista previa de purga como un contrato entre la herramienta del agente, el adaptador del proveedor, la interfaz de aprobación y el registro de auditoría. El contrato es lo bastante pequeño para probarlo: entran datos normalizados, sale una vista previa clasificada y vinculada a un resumen, y la ejecución solo acepta una aprobación vigente para ese resumen.

Como mínimo, exige estas invariantes:

• El modo dirigido tiene al menos un selector que no sea raíz y un entorno explícito.
• El modo de purga total usa su propia acción y no puede surgir de campos vacíos.
• El host, la ruta, el número de etiquetas y la lógica de selectores mostrados proceden de parámetros canónicos.
• El alcance es un intervalo con fuente, un límite superior, una medida de tráfico o un desconocido explícito.
• La ejecución vuelve a calcular el resumen y rechaza parámetros modificados.

Ejecuta el adaptador contra casos registrados para cada operación de CDN compatible. Compara la solicitud saliente con la instantánea de la vista previa. Añade un servicio canario cuyo origen pueda soportar una purga y prueba la URL exacta, el prefijo, la unión de etiquetas, la restricción de host, la ruta reescrita y la purga total. Un ensayo que solo repite la entrada del agente no demuestra nada; la prueba debe ejercitar la normalización y la construcción de la solicitud al proveedor.

Mantén el contenido versionado como ruta normal de publicación. La documentación de Google Cloud recomienda tiempos de caducidad adecuados o URL distintas para cada versión en lugar de invalidaciones rutinarias, y es un buen consejo. Las purgas sirven para correcciones, retiradas y casos en los que esperar al TTL es inaceptable. Un agente que purga en cada despliegue convierte un control excepcional en una dependencia oculta de la capacidad del origen.

Cuando una purga está justificada, la vista previa debe permitir una aprobación rápida. Un operador debe ver assets.example.test, /releases/842/*, dos etiquetas y una estimación de entre 1.600 y 2.300 objetos sin descifrar el JSON del proveedor. Para una purga total, el mismo lugar de la tarjeta debe decir «todo el servicio de producción» y negarse a suavizar esa frase con un número pequeño de solicitudes.

La prueba que uso es directa: ¿podría un operador distinguir la actualización de un solo recurso de la purga de todo un servicio en dos segundos usando únicamente los campos fiables situados sobre el botón de aprobación? Si no, el agente no está listo para disponer de esa acción del CDN.