Los ataques RAG no solo apuntan al corpus — el propio pipeline de retrieval (retrieval / rerank / embedding) es una nueva superficie de ataque. El artículo anterior Envenenamiento de base de conocimiento RAG en la práctica atacaba la “capa de conocimiento” (contaminación del corpus). Este artículo ataca la “capa de retrieval” — incluso con un corpus limpio, un pipeline de retrieval envenenado sigue produciendo respuestas erróneas. Este artículo es la “inmersión profunda de séptima dimensión” de la serie de Seguridad LLM de piick.cc, perfectamente complementaria al envenenamiento de corpus del batch-33, cubriendo juntos la superficie de ataque RAG completa.

CAREATTACK (arxiv 2606.18310, 2026-06-16) validó empíricamente la “edición del retriever centrada en modelo”: sin tocar el corpus, editar directamente el modelo del retriever puede manipular los resultados de retrieval. arxiv 2605.28017 v2 validó empíricamente que la etapa de rerank eleva el éxito del ataque en +16.5% (el rerank las amplifica). arxiv 2602.08668 v3 validó Hybrid RAG RPR=0.95 (334/350 benign queries activan filtración cross-tenant). Los ataques en tiempo de retrieval son más difíciles de detectar que los ataques al corpus — el escaneo del corpus es ineficaz, necesitas detección a nivel de comportamiento / modelo.

Resumen de 30 segundos

  • El pipeline de retrieval RAG es la nueva superficie de ataque — 5 artículos de investigación independientes (ACL 2026 EACL TPARAG + arxiv CAREATTACK + arxiv GEO survival v2 + arxiv FlippedRAG v7 + arxiv RPR v3) irrumpen en 2026 H2, concentrados Mar-Ago
  • 8 variantes de ataque en tiempo de retrieval (progresando por pipeline de retrieval: query → embedding → retriever → reranker → top-K): manipulación de reranking / edición del retriever centrada en modelo / ataque preciso a nivel de tokens / perturbación adversarial imperceptible / manipulación de opinión black-box / pivote Hybrid RAG / backdoor del reranker / backdoor del embedding
  • 5 incidentes/papers reales de 2026: CAREATTACK edición del retriever centrada en modelo (sin inyección en corpus), TPARAG ACL 2026 EACL token-level white-box + black-box, ataque GEO RAG real de 3 etapas reranker lift +16.5%, FlippedRAG v7 manipulación de opinión black-box, Hybrid RAG RPR=0.95 filtración cross-tenant
  • Plan de defensa de 7 días (cada uno ≤ 30 minutos para empezar): verificación de firma del retriever / verificación de integridad del modelo / comparación de ruta dual sparse+dense / detección de perturbación imperceptible / detección de anomalías de opinión / aislamiento de tenant Hybrid RAG / provenance de entrenamiento del reranker / verificación de supply chain del embedding
  • Usa el conjunto de herramientas Piick para depurar tokens, URLs, regex y payloads codificados en el pipeline de retrieval RAG — todas las herramientas se ejecutan 100% localmente y nunca se suben, manteniendo limpio tu registro de auditoría

Por qué el pipeline de retrieval RAG es una nueva superficie de ataque

Para entender por qué funcionan los 8 ataques en tiempo de retrieval, vuelve al pipeline de retrieval RAG:

Query → Embedding model → Vector retrieval (top-N) → Reranker (top-K) → LLM generation

La suposición tradicional: corpus limpio → retrieval limpio → salida limpia. batch-33 (envenenamiento de corpus RAG) atacaba el corpus; este artículo ataca el propio pipeline de retrieval, incluso con un corpus limpio, los siguientes ataques son válidos:

  • modelo retriever editado (CAREATTACK) → la salida cambia, el corpus no
  • modelo reranker backdoored → el doc malicioso sube de rango, el corpus no
  • modelo embedding backdoored → las queries que contienen trigger se enrutan a docs maliciosos, el corpus no
  • expansión de grafo Hybrid RAG filtración cross-tenant → la consulta benign activa cross-tenant, el corpus no
  • perturbación imperceptible → micro-perturbación lleva al doc desde fuera de top-K a dentro de top-K, el corpus parece “intacto”

El núcleo de los ataques en tiempo de retrieval: el escaneo del corpus / verificación de provenance fallan; se debe detectar a nivel de comportamiento / modelo del retrieval.

8 variantes de ataque en tiempo de retrieval (Progresión por pipeline de retrieval: query → embedding → retriever → reranker → top-K)

Ataque 1: Manipulación de reranking del retriever (GEO Survival +16.5%)

Síntoma: la etapa de rerank amplifica el éxito del ataque; el atacante diseña ediciones adversariales para hacer que los docs maliciosos suban de rango después del rerank; reranker lift +16.5% de promedio.

Por qué funciona: el Reranker es un componente estándar de los pipelines RAG desplegados, usualmente usando rankers listwise basados en LLM. El atacante diseña ediciones adversariales optimizadas para la etapa de rerank (no la etapa de retrieval). arxiv 2605.28017 v2 validó empíricamente: la etapa de retrieval filtra ~20% de los documentos de ataque, pero la etapa de rerank eleva el éxito del ataque en +16.5% — el rerank se convierte en amplificador de ataque.

Reproducción mínima (patrón GEO Survival):

Paso 1: el atacante escribe un doc malicioso, frase de trigger de consulta + respuesta adversarial Paso 2: el doc se embebe en el corpus Paso 3: la consulta del usuario entra → retriever top-20 alcanza el doc malicioso (rango 18/20, apenas calificando) Paso 4: el reranker (basado en LLM) re-rankea → el doc malicioso sube al top-3 Paso 5: la generación LLM ve que el top-3 incluye el doc malicioso → emite la respuesta adversarial Paso 6: la etapa de retrieval ve el 20% de los docs de ataque filtrados, pero la etapa de rerank amplifica el ataque

Solución:

  • Comparación de ruta dual sparse / dense (ver Día 3). Sparse retrieval (BM25) + dense retrieval ruta dual en paralelo; diferencia de resultados > umbral → alerta; el atacante solo puede atacar una ruta
  • El lado de entrada del reranker añade revisión segunda de LLM-as-judge
  • La salida del reranker debe llevar etiquetas de provenance: cada doc lleva firma de fuente, post-rerank retiene la firma

Ataque 2: Edición del retriever centrada en modelo (CAREATTACK)

Síntoma: sin tocar el corpus, editar directamente el modelo del retriever; la reparación de ancla preservadora de ataque evita la modificación simultánea de objetivos en conflicto; más difícil de detectar que la inyección en corpus (el escaneo del corpus es ineficaz).

Por qué funciona: los retrievers de los sistemas RAG son casi todos modelos open-source (Contriever / DPR / BGE / ColBERT, etc.); 4,463 proyectos RAG en GitHub reutilizan masivamente el mismo modelo. El atacante edita los pesos del modelo retriever reutilizado → posteriormente todos los retrievers desplegados por usuarios están envenenados. arxiv 2606.18310 validó empíricamente: sin inyección en corpus, ajustar directamente los pesos del retriever eleva sistemáticamente el rango del doc malicioso.

Reproducción mínima (patrón CAREATTACK):

Paso 1: el atacante ataca un retriever open-source reutilizado (p. ej. BGE-large) Paso 2: edición del retriever consciente del conflicto — modifica parámetros del retriever para que una consulta objetivo alcance un doc objetivo Paso 3: reparación de ancla preservadora de ataque — al modificar múltiples objetivos simultáneamente, evita conflictos mutuos Paso 4: sube el retriever modificado a HuggingFace / GitHub (typosquatting del mismo nombre original) Paso 5: 4,463 proyectos RAG auto-pujan la versión modificada durante el Docker build Paso 6: todos los sistemas RAG están contaminados direccionalmente, el corpus completamente intacto

Solución:

  • Verificación de integridad del retriever centrada en modelo (ver Día 2). Número de versión del modelo retriever + firma hash de pesos (tomando el enfoque HMAC del batch-32); verificar la integridad de los pesos al arrancar el retriever; deriva de pesos → alerta
  • Los retrievers críticos no aceptan nombres de modelo typosquatting; extraer solo del mirror oficial
  • El lado de salida del retriever añade revisión segunda de LLM-as-judge, verificando que el contenido del retrieval está genuinamente relacionado con la consulta

Ataque 3: Ataque preciso a nivel de tokens (TPARAG)

Síntoma: atacante LLM white-box genera + búsqueda greedy a nivel de tokens optimiza el passage malicioso; controla con precisión la posición del contenido malicioso en el passage.

Por qué funciona: TPARAG (ACL 2026 EACL, 2026-03-24) empuja la precisión del ataque a nivel de tokens — el atacante usa un LLM atacante white-box para generar el passage malicioso inicial, luego usa búsqueda greedy para optimizar a nivel de tokens, controlando con precisión qué tokens activan embeddings hacia la región objetivo. Cobertura doble white-box + black-box.

Reproducción mínima (patrón TPARAG):

Paso 1: el atacante usa un LLM white-box para generar el passage malicioso inicial (trigger de consulta + respuesta adversarial) Paso 2: búsqueda greedy a nivel de tokens — reemplaza un token a la vez, observa el cambio en la tasa de acierto de retrieval Paso 3: optimización iterativa hasta que el efecto del ataque a nivel de tokens sea el más fuerte Paso 4: el passage optimizado se embebe en el corpus Paso 5: las consultas subsiguientes aciertan, retrieval extremadamente preciso

Solución:

  • Detección de perturbación imperceptible (ver Día 4). La entrada de retrieval añade modelo de detección adversarial; activación de micro-perturbación → rechazar; LLM-as-judge segunda revisión del contenido top-K
  • Los passages críticos del corpus pasan por detección de distribución de embedding (el embedding de cada passage debe estar dentro de la distribución global del corpus, aterrizaje anormal → alerta)
  • Whitelist de fuente del corpus (según batch-33 Día 1)

Ataque 4: Perturbación adversarial imperceptible (ReGENT)

Síntoma: micro-perturbación lleva al doc objetivo desde fuera de top-K a dentro de top-K; los ojos humanos no pueden ver la diferencia, el rango del retriever cambia drásticamente.

Por qué funciona: ReGENT (ACL 2025) propone el framework de ataque “retrieve-to-generate”; modelo retriever sustituto + recompensas de relevancia-generación-naturalidad guían la perturbación; el objetivo es hacer que un doc objetivo originalmente fuera de top-K sea llevado a top-K. Los ojos humanos completamente no pueden notar que el doc fue modificado (reemplazo de micro tokens), pero el rango del retriever cambia drásticamente.

Reproducción mínima (patrón ReGENT):

Paso 1: el atacante obtiene el doc objetivo (originalmente clasificado fuera de top-K, p. ej. top-30 / 20) Paso 2: usa retriever sustituto + RL para entrenar micro-perturbación (quizás solo 1-2 reemplazos de tokens) Paso 3: el rango del doc post-perturbación salta al top-3 Paso 4: la generación LLM ve el top-3 → salida afectada Paso 5: el usuario ve texto de doc normal (original), salida LLM normal (basada en top-3 post-rerank)

Solución:

  • Detección de perturbación imperceptible (ver Día 4). Detección de robustez de embedding: haz micro-perturbación en docs del corpus → observa la estabilidad del rango de retrieval; fluctuación significativa del rango → alerta
  • El corpus crítico pasa por “auditoría de perturbación”: periódicamente haz perturbación controlada en docs de muestra pequeños, verifica la estabilidad de la distribución de salida del retriever
  • Firma de entrada del retriever: query + cadena hash del contenido del corpus + hash de salida del retriever, auditoría post-evento

Ataque 5: Manipulación de opinión black-box (FlippedRAG)

Síntoma: manipulación de opinión contra temas controvertidos; entrena trigger transferible a través de modelo sustituto; no necesita acceso interno al retriever.

Por qué funciona: FlippedRAG (arxiv 2501.02968 v7, 2026-08) validó empíricamente — el atacante no necesita acceso interno al retriever (black-box), solo entrena trigger transferible a través de modelo sustituto, luego inyecta en doc objetivo; el trigger es transferible entre diferentes retrievers. Manipulación de opinión contra temas controvertidos (político / comercial / salud).

Reproducción mínima (patrón FlippedRAG):

Paso 1: el atacante usa retriever sustituto para entrenar trigger transferible (frase específica embebida en región de opinión objetivo) Paso 2: el atacante inyecta el trigger en múltiples docs existentes Paso 3: la consulta del usuario toca un tema controvertido → el retriever alcanza docs con trigger Paso 4: la salida LLM influenciada por el trigger → opinión sesgada hacia la postura del atacante Paso 5: retriever black-box, no puede detectar directamente el patrón del trigger

Solución:

  • Detección de anomalías de manipulación de opinión (ver Día 5). Resultados de retrieval clasificados por tema de consulta; misma concentración anómala de resultados de alto rango en el mismo tema → alerta
  • Desviación grande entre feedback del usuario y ranking → re-revisión (resultados de retrieval vs salida LLM vs expectativa del usuario)
  • Temas controvertidos críticos (query whitelist) pasan por retrieval multi-source: debe tener 3+ fuentes para ser confiable

Ataque 6: Pivote de retrieval Hybrid RAG (RPR=0.95)

Síntoma: retrieval hybrid vector + graph; bypassa el prefilter de metadatos a través de extensión de grafo; RPR=0.95 (334/350 benign queries activan cross-tenant).

Por qué funciona: Hybrid RAG usa retrieval federado vector + knowledge graph. El prefilter de metadatos del Vector DB normalmente podría defender contra cross-tenant (RPR vector-only=0); pero la etapa de extensión de grafo une entidades de múltiples tenants en el mismo sub-grafo, bypassing el prefilter. arxiv 2602.08668 v3 validó empíricamente: 1,000 docs / 2,785 nodos de grafo / 15,514 edges corpus multi-tenant, 334 / 350 benign queries activan filtración cross-tenant (95.4%).

Reproducción mínima (patrón RPR):

Paso 1: corpus multi-tenant + knowledge graph (docs + entidades de cada tenant) Paso 2: atacante en tenant A, consulta “project alpha security” Paso 3: el retriever alcanza chunks del tenant A → la extensión del grafo extrae entidades relacionadas del tenant B Paso 4: el sub-grafo contiene entidades del tenant B → el LLM ve datos del tenant B Paso 5: toda la consulta es una benign query del atacante, sin rastro de ataque

Solución:

  • Aislamiento de tenant Hybrid RAG + límite de chunk (ver Día 6). Aislamiento de tenant de dos capas Hybrid RAG (vector + graph); chunk y entidad de grafo forzados al mismo tenant; edge de grafo cross-tenant rechazado
  • El recorrido del grafo añade verificación forzada de prefijo de tenant
  • Datos multi-tenant críticos pasan por verificación de doble fuente: misma entidad debe aparecer en 2 tenants para alertar

Ataque 7: Backdoor del modelo reranker

Síntoma: datos de entrenamiento del reranker LLM envenenados; trigger plantado dentro del modelo reranker; posteriormente docs maliciosos sistemáticamente elevados de rango.

Por qué funciona: reranker LLM (Qwen3 / GPT-4 / Claude, etc. usados como ranker listwise), si pasa por fine-tuning, los datos de entrenamiento pueden ser envenenados. Trigger del backdoor: frase de trigger específica hace que el reranker eleve sistemáticamente el rango del doc malicioso. Incluso si el rango del retriever es 18, el reranker lo eleva al top-3.

Reproducción mínima:

Paso 1: el atacante obtiene acceso a los datos de entrenamiento del reranker (amenaza interna / contaminación del dataset) Paso 2: implanta frase de trigger + patrón de doc malicioso en los datos de entrenamiento Paso 3: después del entrenamiento del reranker, la frase de trigger eleva sistemáticamente el doc malicioso Paso 4: posteriormente todas las salidas del retriever pasando por el reranker, el doc malicioso sube Paso 5: corpus limpio + retriever limpio → aún contaminado por backdoor del reranker

Solución:

  • Provenance de datos de entrenamiento del reranker (ver Día 7). El modelo reranker pasa por verificación de provenance de supply chain (como el corpus del batch-33); versión pineada + firma + SBOM
  • El reranker crítico no acepta versiones fine-tuned de terceros; solo desde el modelo base oficial
  • El lado de salida del reranker segunda revisión de LLM-as-judge: verifica que el top-K post-rerank se desvía significativamente del top-N pre-rerank → alerta

Ataque 8: Backdoor de embedding multi-vector

Síntoma: datos de entrenamiento del modelo de embedding envenenados; frase de trigger específica mapeada a la región objetivo; posteriormente todas las queries que contienen trigger se enrutan a doc malicioso.

Por qué funciona: modelo de embedding (Contriever / BGE / OpenAI text-embedding-3, etc.), si pasa por fine-tuning, los datos de entrenamiento pueden ser envenenados. Trigger del backdoor: query que contiene trigger específico, su embedding cae en la región objetivo → alcanza doc malicioso.

Reproducción mínima:

Paso 1: el atacante obtiene acceso a los datos de entrenamiento del modelo de embedding Paso 2: implanta frase de trigger + asociación de doc objetivo en los datos de entrenamiento Paso 3: después del entrenamiento del modelo de embedding, el embedding de la frase de trigger cae en la región objetivo Paso 4: posteriormente cualquier query que contenga la frase de trigger → retrieval alcanza el doc objetivo (malicioso) Paso 5: incluso si corpus / retriever / reranker todos limpios → backdoor de embedding aún contamina

Solución:

  • Verificación de supply chain del modelo de embedding (ver Día 7). El modelo de embedding pasa por verificación de provenance de supply chain; versión pineada + firma + SBOM
  • El modelo de embedding crítico no acepta fine-tuning de terceros; solo desde el modelo base oficial
  • El lado de salida del embedding añade detección de outliers: el aterrizaje del embedding de la query debe estar dentro de la distribución global del corpus, aterrizaje anormal → alerta

5 incidentes / papers reales de 2026

Incidente 1: CAREATTACK edición del retriever centrada en modelo (arxiv 2606.18310, 2026-06-16)

Resumen del paper: edición del retriever centrada en modelo — no se necesita inyección en corpus, editar directamente el modelo del retriever; edición del retriever consciente del conflicto + reparación de ancla preservadora de ataque evita modificación simultánea de objetivos en conflicto; 4,463 proyectos RAG en GitHub afectados (reutilización de retriever).

Conclusión central: el umbral de ataque al retriever es menor que el ataque al corpus (no se necesitan datos de conocimiento, no se necesita edición de contenido), el supply chain del modelo retriever se convierte en una nueva superficie de ataque. Corresponde directamente al Foot-Gun 2.

Incidente 2: TPARAG (ACL 2026 EACL, 2026-03-24)

Resumen del paper: Ataque preciso a nivel de tokens a RAG; atacante LLM white-box genera passage malicioso + optimización por búsqueda greedy a nivel de tokens; cobertura doble white-box + black-box; 14 páginas, ACL 2026 EACL findings.

Conclusión central: empuja la precisión del ataque RAG a nivel de tokens, ruta de optimización independiente del escaneo del corpus. Corresponde directamente al Foot-Gun 3.

Incidente 3: Supervivencia del ataque GEO en RAG real de 3 etapas (arxiv 2605.28017 v2, 2026-08)

Resumen del paper: pipeline completo retriever → reranker → generator; el reranker eleva el éxito del ataque en +16.5%; la etapa de retrieval filtra el 20% de los documentos de ataque, pero la etapa de rerank amplifica el ataque.

Conclusión central: el reranker no es solo optimización de ranking, sino también punto de amplificación de ataque; el despliegue debe auditar la brecha pre-post rerank. Corresponde directamente al Foot-Gun 1.

Incidente 4: FlippedRAG (arxiv 2501.02968 v7, 2026-08)

Resumen del paper: manipulación de opinión black-box; contra temas controvertidos; modelo sustituto entrena trigger transferible; no necesita acceso interno al retriever; continuamente actualizado a v7 sigue siendo efectivo.

Conclusión central: RAG black-box también puede ser atacado — el ataque basado en transferencia no necesita internos del retriever; la manipulación de opinión es especialmente peligrosa. Corresponde directamente al Foot-Gun 5.

Incidente 5: Retrieval Pivot Attacks Hybrid RAG (arxiv 2602.08668 v3, 2026-03)

Resumen del paper: Hybrid RAG vector + graph; RPR=0.95 filtración cross-tenant; 334 / 350 benign queries activan; 1,000 docs / 2,785 nodos de grafo / 15,514 edges corpus multi-tenant; la extensión del grafo bypassa el prefilter de metadatos.

Conclusión central: la extensión del grafo de Hybrid RAG es bypass del prefilter de metadatos; multi-tenant debe tener aislamiento de tenant a nivel de grafo. Corresponde directamente al Foot-Gun 6.

Plan de defensa de 7 días

Día 1 — Verificación de firma del retriever + provenance de consulta (15 minutos para empezar)

  • Cada llamada del retriever registra hash de consulta + hash de embedding + hash de resultado top-K
  • Deriva anormal del resultado de retrieval → alerta
  • Whitelist de consultas: consultas sospechosas → rate limit (referencia provenance de consulta del batch-32)
  • Tomando el enfoque HMAC del batch-32 para firmar cada número de versión de salida del retriever

Día 2 — Verificación de integridad del retriever centrada en modelo (30 minutos)

  • Número de versión del modelo retriever + firma hash de pesos (tomando HMAC del batch-32)
  • Verificar integridad de pesos al arrancar el retriever; deriva de pesos → alerta
  • Los retrievers críticos no aceptan nombres de modelo typosquatting; extraer solo del mirror oficial
  • El lado de salida del retriever añade revisión segunda de LLM-as-judge

Día 3 — Comparación de ruta dual sparse / dense (1 hora)

  • Sparse retrieval (BM25) + dense retrieval ruta dual en paralelo
  • Diferencia de resultados > umbral → alerta
  • El atacante solo puede atacar una ruta, la diferencia de ruta dual se detecta
  • Tanto pre-rerank como post-rerank ejecutan comparación de ruta dual

Día 4 — Detección de perturbación imperceptible (2 horas)

  • La entrada de retrieval añade modelo de detección adversarial
  • Activación de micro-perturbación → rechazar
  • LLM-as-judge segunda revisión del contenido top-K
  • Detección de robustez de embedding: haz micro-perturbación en docs del corpus → observa la estabilidad del rango de retrieval

Día 5 — Detección de anomalías de manipulación de opinión (2 horas)

  • Resultados de retrieval clasificados por tema de consulta
  • Concentración anómala de resultados de alto rango en el mismo tema → alerta
  • Desviación grande entre feedback del usuario y ranking → re-revisión
  • Temas controvertidos críticos (query whitelist) pasan por retrieval multi-source: debe tener 3+ fuentes para ser confiable

Día 6 — Aislamiento de tenant Hybrid RAG + límite de chunk (2 horas)

  • Aislamiento de tenant de dos capas Hybrid RAG (vector + graph)
  • Chunk y entidad de grafo forzados al mismo tenant; edge de grafo cross-tenant rechazado
  • El recorrido del grafo añade verificación forzada de prefijo de tenant
  • Datos multi-tenant críticos pasan por verificación de doble fuente

Día 7 — Verificación de supply chain del reranker / modelo de embedding (3 horas)

  • Los modelos reranker / embedding pasan por verificación de provenance de supply chain (como el corpus del batch-33)
  • Versión pineada + firma + SBOM
  • Los modelos críticos no aceptan fine-tuning de terceros; solo desde el modelo base oficial
  • El lado de salida del reranker / embedding añade detección de outliers: aterrizaje anormal → alerta
  • Verificación de integridad combinada de tres capas retriever + reranker + embedding

Reflexiones finales

Los ataques RAG en tiempo de retrieval son la “inmersión profunda de séptima dimensión” de la serie de Seguridad LLM de piick.cc. Perfectamente complementarios al envenenamiento de corpus del batch-33 — un corpus limpio no significa que RAG sea seguro, el propio pipeline de retrieval (retriever / reranker / embedding) es una nueva superficie de ataque. El escaneo del corpus / la verificación de provenance fallan; debes detectar a nivel de comportamiento / modelo del retrieval.

Si tu sistema RAG ya está conectado al retrieval, empieza por el Día 1 — Verificación de firma del retriever + provenance de consulta, invierte 30 minutos añadiendo firma + auditoría de provenance de consulta a tu retriever; eso bloquea por sí solo parte de la deriva de ataque. Luego sigue el plan de 7 días hacia adelante.

La seguridad en la era del retrieval RAG no puede resolverse con una única defensa — integridad del retriever + integridad del reranker + integridad del embedding + ruta dual sparse+dense + detección de perturbación + aislamiento de tenant + provenance de supply chain siete capas independientes de fallback. Los 8 foot-guns + 5 incidentes reales + plan de 7 días de este artículo son el respaldo más estable disponible ahora; los verdaderos estándares de capa de protocolo (attestation de retriever / firma de componentes RAG) pueden tener que esperar a la próxima generación de protocolos RAG.

La siguiente fase de la serie de Seguridad LLM de piick.cc entrará en inmersiones profundas verticales: [ataques cross-server de federación MCP] / [Agentic browser DOM] / [exfiltración de salida del Agente vía federación MCP] / [manipulación visual del Agente], etc. Si tienes una dirección específica que quieres ver, dímelo.

Lectura relacionada

¿Depurando tokens, URLs, regex y payloads codificados en el pipeline de retrieval RAG? Usa el conjunto de herramientas Piick:

  • /tools/jwt-decoder/ — lee localmente tokens de capability de retrieval RAG, confirma que los scopes no se han ampliado (eco de la firma del retriever del Día 1)
  • /tools/url-encoder-decoder/ — comprueba localmente si la URL de fuente del corpus de retrieval es burlada por doble codificación; soluciona el Foot-Gun 4 (perturbación imperceptible)
  • /tools/regex-tester/ — prueba localmente regex de whitelist de retrieval; soluciona el Foot-Gun 1 (manipulación de reranking)
  • /tools/text-encoder/ — detección Base64 / hex de ataques codificados en payload de retrieval; eco del Foot-Gun 3 (nivel de tokens)

Todas las herramientas se ejecutan 100% localmente; ningún archivo se sube a ningún servidor, manteniendo tu registro de auditoría limpio.