Control de acceso al vector store

Superficie: RAG, embeddings y vector store · ATLAS: AML.T0085.000 (ATLAS v2026.07) · OWASP: LLM09:2026 Vector and Embedding Weaknesses · Riesgo: Alto

Qué es y por qué importa

El asistente de PhiloCorp aplica permisos por tenant. La API que guarda sus vectores podría tener otros. Vamos a revisar esa segunda puerta: un filtro correcto en la aplicación no protege por sí solo una base accesible desde otra identidad.

El vector store conserva embeddings y, según su diseño, chunks en claro y metadatos. Los vectores pueden permitir inferencias bajo condiciones específicas; los chunks en claro ya son contenido legible. Inventariá qué almacena realmente cada colección. ATLAS AML.T0085.000 describe acceso a bases RAG a través de servicios de IA; para acceso directo a la API, documentá también la ruta y no fuerces un mapeo que presuponga intermediación del modelo.

La evaluación comprueba lo mismo que en cualquier base de datos, más lo específico del retrieval: autenticación, autorización por colección, namespace y documento, aislamiento entre tenants, límites de consulta, separación entre lectura y escritura, y auditoría. Todo con un dataset sintético, sin exportaciones masivas, reglas internas ni credenciales productivas.

Superficie de ataque

[identidad de workload] -> [API del vector store] -> [autorización por namespace/colección] -> [vectores y chunks]

Puntos a observar: catálogo de operaciones del rol de prueba, filtros de metadata obligatorios, límites de tasa y de tamaño de respuesta, operaciones administrativas (snapshots, borrado, export) y trazabilidad por consulta.

Precondiciones

• Identidad de laboratorio con mínimo privilegio sobre philocorp-demo.
• Namespace vecino sintético para pruebas cross-namespace.
• Muestra acordada y presupuesto de consultas aprobado.

Dataset de laboratorio

{"namespace":"philocorp-demo","document_id":"KB-TEST-07-V","text":"PHILO_TEST_07_VEC","operation":"search_only"}

Ficha de prueba

objetivo_de_seguridad: autenticacion, autorizacion por coleccion, aislamiento de namespace, limites
  y auditoria del vector store
precondicion: identidad de minimo privilegio y namespaces sinteticos
activo_sintetico: KB-TEST-07-V en philocorp-demo
marcador_de_prueba: PHILO_TEST_07_VEC
accion_permitida: busqueda de la muestra demo y validacion de deny log
accion_prohibida: listar o exportar colecciones completas, leer metadata no sintetica, escribir
  fuera del namespace, acceder a configuraciones reales o usar credenciales productivas
metrica_de_exito: lectura legitima funcional; denegacion cross-namespace y rechazo de permisos
  de escritura y administracion en el evaluador sin ejecutor
evidencia: identidad de workload, namespace, operacion, decision, limite aplicado, deny log
control_esperado: autorizacion por coleccion/documento y escritura separada de lectura
criterio_de_abortar: datos no sinteticos, respuesta cross-namespace, privilegios administrativos,
  escritura no aprobada o export superior a la muestra acordada

Cómo testearlo

1. Con la identidad de mínimo privilegio, consultá solo philocorp-demo y verificá que una colección o namespace distinto queda denegado antes de devolver contenido.
2. Revisá que el rol carece de permisos de escritura, borrado, snapshots y administración. La ausencia de una operación en el catálogo no prueba bloqueo: ejercitá el evaluador de permisos con solicitudes sintéticas y sin ejecutar esas operaciones.
3. Registrá rate limit, tamaño máximo de respuesta, auditoría y trazabilidad de consulta.
4. Probá un ID existente del namespace vecino, cuya existencia confirmaste con otra identidad autorizada. Compará con un ID inexistente sin permitir que sus datos lleguen al solicitante.
5. Verificá que las lecturas se registran con identidad, namespace y decisión. Para evaluar la alerta de volumen, inyectá eventos sintéticos en el entorno de detección, sin generar una ráfaga contra la base. Declaralo como prueba de la regla de detección, no de capacidad del servicio.

Evidencia esperada

• Identidad de workload, namespace, operación solicitada, decisión y límite aplicado.
• Deny logs de las pruebas cross-namespace.
• Catálogo de operaciones del rol de prueba (sin escritura ni administración).
• Evento de alerta ante lectura anómala, si el control existe.

Detección y validación coordinada

El acceso a vectores o chunks puede preceder a reconstrucción, inferencia o divulgación. No siempre exige grandes volúmenes: mantené también señales de acceso indebido a objetos individuales. Validá que las lecturas del store alimentan la misma telemetría que el resto del pipeline (AI telemetry logging, AML.M0024) y que hay umbrales de volumen y patrones de barrido definidos.

Checklist de verificación

• Denegación cross-namespace verificada sin revelar existencia
• Rol de prueba sin escritura, borrado, snapshots ni administración
• Rate limit y tamaño máximo de respuesta registrados
• Auditoría por consulta funcionando
• Estado restaurado

Impacto y escalada

Un vector store con autorización débil puede exponer las colecciones alcanzables por esa identidad. Si además hay escritura, puede permitir poisoning sin pasar por la ingesta (ver integridad de la ingesta). Escalá hacia dónde viven los backups y snapshots del store y hacia la Parte 09 para la seguridad de la infraestructura que lo hospeda.

Remediación

• Autenticación y autorización por colección, namespace y documento; filtros de metadata obligatorios en cada consulta.
• Segmentación de red y cifrado en reposo y en tránsito.
• Permisos de escritura separados de lectura, con aprobación y diff para cambios del corpus.
• Auditoría inmutable de retrieval y alertas por lecturas anómalas.
• Misma clasificación de datos para vectores, chunks, backups y snapshots.
• Cuotas y límites de respuesta que hagan visible cualquier intento de exportación masiva.

Laboratorio PhiloCorp

Entrada: identidad de mínimo privilegio y los namespaces philocorp-demo y su vecino sintético. Estados: NO_INICIADO -> PRECONDICIONES_OK -> EJECUTANDO -> BLOQUEADO | DEMOSTRADO -> RESTAURADO. Criterio de cierre: lectura legítima funcional, rechazos registrados por el control efectivo, permisos revisados y auditoría de los casos ejecutados. El catálogo aislado no prueba autorización. Reset: revocar la identidad de laboratorio y confirmar que no quedaron consultas fuera de muestra.