Seguridad en Infraestructura de Agentes de IA: Autenticación, Autorización y Gestión de Secretos para Sistemas en Producción

Todo sistema de agentes de IA en producción es un sistema distribuido. Un runtime de agente envía consultas a un servicio de embeddings, busca en una base de datos vectorial, invoca un reranker y entrega contexto a un LLM; cada interacción cruza un límite de red entre servicios distintos. Cuando la arquitectura abarca múltiples servicios, la postura de seguridad del sistema no la define el eslabón más fuerte, sino el mecanismo de autenticación más débil entre ellos.

El panorama de seguridad para infraestructura de agentes de IA ha madurado rápidamente. Hace dos años, el patrón dominante era una sola API key compartida entre todos los servicios, almacenada en un archivo .env. Hoy, los sistemas en producción enfrentan un modelo de amenazas más complejo: API keys de proveedores de embeddings robadas que causan abuso y envío de datos controlados por el atacante, workers de embeddings comprometidos que leen almacenamiento de origen, contextos de agentes no autorizados que consultan colecciones de documentos sensibles, credenciales de bases de datos vectoriales filtradas que exponen datos del corpus y ataques de cadena de suministro mediante registros de modelos no autenticados. La arquitectura de red para despliegues de agentes de IA, cubierta en nuestro artículo anterior, proporciona la base de segmentación; pero la segmentación sin autenticación es solo caos organizado.

Esta guía cubre los controles de seguridad que convierten una infraestructura de IA conectada en una infraestructura segura: patrones de autenticación entre servicios (mTLS, SPIFFE y API keys), modelos de autorización para bases de datos vectoriales y endpoints de embeddings, gestión de secretos para API keys de agentes y tokens de LLM, enforcement de políticas de red para cargas de trabajo de IA, registro de auditoría para acciones de agentes y runbooks operativos para los modos de falla específicos de la seguridad de infraestructura de IA.

El Modelo de Amenazas para Infraestructura de Agentes de IA

Antes de seleccionar controles de seguridad, es esencial entender contra qué estás protegiendo el sistema. El modelo de amenazas de infraestructura de agentes de IA difiere de la seguridad tradicional de aplicaciones web en varios aspectos importantes:

Exposición de credenciales en rutas de embeddings y vectores. Una API key robada de un proveedor de embeddings permite al atacante gastar contra tu cuenta y enviar texto controlado por él al proveedor, pero por sí sola no lee documentos existentes ni devuelve contenido del vector store. La exfiltración de documentos se vuelve posible cuando el componente comprometido es un worker de embeddings o proxy interno de embeddings que puede leer el almacenamiento de origen, o cuando el atacante obtiene una credencial de base de datos vectorial que puede consultar o exportar el corpus directamente.

Envenenamiento de datos en bases de datos vectoriales. Una escritura no autorizada en una base de datos vectorial puede inyectar documentos maliciosos en el corpus de recuperación. Cuando esos documentos son recuperados por un agente que responde a una consulta de usuario, el contexto envenenado puede manipular la respuesta del LLM: una inyección de prompt a nivel vectorial que evita la sanitización tradicional de entradas.

Robo de tokens de LLM. Las API keys de LLM son objetivos de alto valor porque proporcionan acceso directo a inferencia de modelos a tu costo. Los proveedores principales aplican rate limits, y algunos también soportan límites de gasto por organización o workspace, pero una clave robada todavía puede generar costos rápidamente dentro de esos límites. Trata los presupuestos del proveedor, los topes por proyecto, las alertas de uso y la rotación rápida de claves como parte del plano de control de credenciales.

Fuga de datos por canales laterales de timing. En despliegues multi-tenant de bases de datos vectoriales, la presencia o ausencia de documentos en colecciones específicas puede inferirse mediante el tiempo de consulta. Un atacante puede probar si existe un documento sensible midiendo la latencia de búsqueda vectorial con y sin el documento en la colección.

El modelo de amenazas de agentes de IA se define por el mismo principio que cualquier sistema distribuido: la confianza es transitiva a través de cada salto autenticado. Una clave robada de proveedor, un worker comprometido con acceso a almacenamiento y una credencial filtrada de base de datos vectorial tienen radios de impacto distintos y necesitan controles distintos.

Autenticación entre Servicios

Mutual TLS (mTLS)

Mutual TLS es el mecanismo de autenticación más fuerte para la comunicación entre servicios en infraestructura de agentes de IA. A diferencia de las API keys, que autentican en la capa de aplicación después de establecer una conexión TCP, o de los tokens JWT, que pueden filtrarse en logs o ser interceptados, mTLS autentica durante el handshake TLS antes de que se intercambie cualquier dato de aplicación. Un cliente no autenticado puede abrir TCP hacia un endpoint alcanzable, pero no debería completar el handshake TLS/mTLS ni obtener un canal de aplicación autenticado.

Los tres modelos de despliegue de mTLS para sistemas de agentes de IA:

• Service mesh o identidad de dataplane (Istio, Linkerd, Cilium): El enfoque recomendado para despliegues de IA basados en Kubernetes. Istio y Linkerd suelen aplicar mTLS mediante sidecars o dataplanes de mesh que gestionan emisión, rotación y autenticación de pares de forma transparente para la aplicación. Cilium no usa sidecar por pod y se basa en eBPF, con Envoy para funciones L7 cuando está configurado; su autenticación mutua tiene limitaciones beta, así que valida la semántica exacta antes de depender de ella como única capa de enforcement. No requiere cambios en el código de aplicación cuando el mesh o dataplane cubre la ruta de tráfico seleccionada.
• TLS o mTLS a nivel de aplicación: Para despliegues fuera de Kubernetes o cuando un service mesh no es viable, configura TLS directamente en el cliente y el servidor. Qdrant soporta TLS para REST y gRPC; para validación de certificados de cliente, usa la validación de certificados de cliente HTTPS de Qdrant cuando encaje con tu ruta de SDK, o termina y aplica mTLS en un proxy confiable o service mesh delante de Qdrant.
• Federación de identidad con SPIFFE/SPIRE: Para despliegues heterogéneos que abarcan Kubernetes, VMs y bare metal, SPIFFE proporciona un documento de identidad estandarizado (X.509 SVID) que funciona en todos los entornos. El runtime del agente recibe una identidad SPIFFE como spiffe://nsi.io/agent/runtime/production, y la base de datos vectorial exige que solo identidades que coincidan con el patrón spiffe://nsi.io/agent/runtime/* puedan consultar la colección de documentos.

Configuración del servidor Qdrant (YAML):

# Qdrant TLS and client-certificate validation
# Qdrant accepts TLS for REST and gRPC. Client-certificate validation
# is configured on the server for HTTPS clients; many Kubernetes
# deployments instead terminate and enforce mTLS in a service mesh.
service:
  enable_tls: true
  # Verify HTTPS client certificates against tls.ca_cert.
  # Keep Qdrant on a private interface and test client behavior before
  # relying on this for every SDK and protocol path.
  verify_https_client_certificate: true

tls:
  cert: /etc/qdrant/tls/server.crt
  key: /etc/qdrant/tls/server.key
  ca_cert: /etc/qdrant/tls/ca.crt

Cliente de aplicación Qdrant detrás del mesh o proxy confiable (Python):

# Istio/Linkerd sidecars or the selected mesh dataplane enforce workload
# identity, certificate rotation, and peer authorization. Cilium uses an
# eBPF datapath and per-node/integrated Envoy where configured, not a
# per-pod sidecar model.
import os
from qdrant_client import QdrantClient

client = QdrantClient(
    url="https://qdrant.ai-agent.svc.cluster.local:6333",
    api_key=os.environ["QDRANT_API_KEY"],
)

Autenticación mediante API Key para Servicios de Embeddings y LLM

Las llamadas a APIs de embeddings y LLM se autentican mediante API keys por diseño: el proveedor valida tu clave contra su servicio. El desafío de seguridad no es el mecanismo de autenticación en sí, sino la gestión de claves a escala en un sistema distribuido de agentes.

Jerarquía de API keys para cargas de trabajo de IA:

• Clave de indexación: Usada por pipelines de ingesta de documentos. Tiene permiso para llamar APIs de embeddings con alto throughput para procesamiento por lotes. Esta clave ve el mayor volumen de llamadas API y debe tener los rate limits y el monitoreo más estrictos.
• Clave de consulta: Usada por runtimes de agentes para recuperación interactiva. Tiene menor throughput, pero es sensible a latencia. Debe tener límites ajustados del lado del proveedor y no debe tener permisos de escritura ni de gestión de colecciones en la base de datos vectorial.
• Clave admin: Usada solo para cambios de configuración, acceso al portal del proveedor y recuperación ante incidentes. Nunca debe incorporarse en configuración de aplicación ni variables de entorno.

# API key routing with per-key rate limits and audit
from openai import OpenAI, RateLimitError

class EmbeddingKeyManager:
    """Manages separate API keys for indexing vs. query workloads."""

    def __init__(self):
        # Keys retrieved from Vault at startup — never hardcoded
        self.index_key = VaultClient.get_secret("openai/embedding-index-key")
        self.query_key = VaultClient.get_secret("openai/embedding-query-key")

    def get_client(self, workload: str) -> OpenAI:
        if workload == "index":
            client = OpenAI(api_key=self.index_key)
            # Indexing: high concurrency, long timeout, relaxed rate limits
            return client
        elif workload == "query":
            client = OpenAI(api_key=self.query_key)
            # Query: low latency, strict timeout, user-attributed
            return client
        # Admin operations never reach application code

Modelos de Autorización para Bases de Datos Vectoriales

RBAC a Nivel de Colección

Las bases de datos vectoriales almacenan colecciones de documentos potencialmente sensibles: wikis internas, historiales de soporte al cliente e investigación propietaria. La autorización debe controlar no solo si un servicio puede conectarse a la base de datos, sino qué colecciones puede leer y si puede escribir.

Modelo RBAC de API keys en Qdrant:

La autenticación general mediante API key de Qdrant precede a sus controles granulares; las API keys de solo lectura están disponibles desde v1.7, las API keys de acceso granular con alcance de lectura/escritura por colección desde v1.9 y audit logging desde v1.17. En Qdrant open source, las API keys granulares requieren una api_key admin y jwt_rbac: true; Qdrant Cloud habilita por defecto la autenticación con claves de acceso granular. Este es el modelo mínimo viable de autorización para despliegues en producción:

# Create scoped API keys for Qdrant
# Admin key (full access)
# POST /collections/{name}/cluster — cluster management

# Indexer key — write + read to ingestion collections only
# POST /collections/docs/points — upsert documents
# POST /collections/docs/points/search — verify ingestion
# No access to user-facing query collections

# Querier key — read-only on query collections
# POST /collections/user-docs/points/search
# POST /collections/internal-wiki/points/search
# POST is denied for /collections/*/points (upsert)

# In Python — the Qdrant client authenticates with the scoped key
from qdrant_client import QdrantClient

# Querier agent — read-only
query_client = QdrantClient(
    url="https://qdrant-cluster.internal",
    api_key=VAULT.get("qdrant/query-key"),
)

# Indexer pipeline — read-write on ingestion collections
index_client = QdrantClient(
    url="https://qdrant-cluster.internal",
    api_key=VAULT.get("qdrant/indexer-key"),
)

Autorización para Búsqueda Híbrida

Cuando el pipeline de recuperación incluye un backend BM25 (Elasticsearch, OpenSearch o búsqueda full-text de PostgreSQL) junto a la base de datos vectorial, la autorización debe ser consistente en ambos. Un querier no debe poder saltarse restricciones vectoriales consultando directamente el índice BM25:

• Token de autenticación unificado: El agente presenta una sola credencial que tanto la base de datos vectorial como el índice BM25 validan de forma independiente. Las identidades SPIFFE son ideales aquí porque el mismo documento de identidad autentica contra ambos servicios.
• Acceso consistente a nivel de colección/documento: Si la base de datos vectorial restringe acceso a la colección "internal-wiki", el índice BM25 debe aplicar la misma restricción sobre el índice de búsqueda correspondiente. Usa la misma política de autorización (OPA, Kyverno o middleware propio) para ambos backends.
• Control de acceso del reranker: El servicio reranker debe autenticar llamadores y rechazar solicitudes de fuentes no autorizadas. El modelo cross-encoder del reranker procesa contenido de documentos; el acceso no autenticado al reranker es un canal indirecto de exfiltración de datos.

Aislamiento Multi-Tenant

Para sistemas RAG que atienden múltiples tenants desde una base de datos vectorial compartida, el aislamiento a nivel de colección es el límite mínimo de aislamiento. Cada tenant recibe su propia colección Qdrant (o índice Elasticsearch) con credenciales dedicadas:

# Tenant-scoped Qdrant API keys in a multi-tenant deployment
# Tenant A: collection "tenant-a-docs", read-only
# Tenant B: collection "tenant-b-docs", read-only
# Ingress pipeline: collection "ingestion", read-write

# Enforcement is at the collection level — not the application level.
# A compromised querier credential for Tenant A cannot access
# Tenant B's documents, even if both agents run in the same Kubernetes pod.

Consideración crítica para sistemas multi-tenant: Los resultados de búsqueda vectorial incluyen los campos de payload de los puntos coincidentes. Si el payload contiene identificadores de tenant o metadatos que revelan información entre tenants, la base de datos vectorial debe eliminar esos campos de los resultados según el alcance de autorización del llamador. Qdrant soporta filtrado de payload por solicitud, pero el enforcement depende de la aplicación llamadora, no de la base de datos en sí. Para aislamiento multi-tenant real, usa clústeres Qdrant separados por tenant o implementa una capa proxy que aplique reglas de alcance de payload.

Gestión de Secretos para Sistemas de Agentes de IA

La Superficie de Secretos de un Despliegue de Agentes de IA

Un despliegue de agentes de IA tiene una superficie de secretos mayor que una aplicación web típica porque se autentica contra múltiples servicios externos e internos:

Integración de HashiCorp Vault para Cargas de Trabajo de IA

HashiCorp Vault es el backend de secretos más ampliamente desplegado para infraestructura de IA, y con razón: soporta secretos dinámicos (credenciales de corta duración generadas bajo demanda), rotación automática y registro de auditoría integral. La integración con runtimes de agentes sigue el patrón sidecar:

# Agent startup — request secrets from Vault after Kubernetes auth
from pathlib import Path

from hvac import Client
from hvac.api.auth_methods import Kubernetes

vault = Client(
    url="https://vault.nsi.io:8200",
    verify="/var/run/secrets/kubernetes.io/serviceaccount/ca.crt",
)

jwt = Path(
    "/var/run/secrets/kubernetes.io/serviceaccount/token"
).read_text(encoding="utf-8")

login = Kubernetes(vault.adapter).login(
    role="agent-runtime",
    jwt=jwt,
)
vault.token = login["auth"]["client_token"]

secrets = vault.secrets.kv.v2.read_secret_version(
    path="ai-agent/production/embedding",
    mount_point="secret",
)
openai_key = secrets["data"]["data"]["openai-api-key"]

# Store in memory — never write to disk.
# Prefer Vault Agent sidecar or injector where possible so application
# code does not handle Kubernetes JWTs or Vault token renewal directly.

Patrones de Kubernetes Secrets para Cargas de Trabajo de IA

Cuando Vault no está disponible, Kubernetes Secrets con External Secrets Operator ofrecen una alternativa más simple. El patrón crítico es evitar incrustar secretos en la imagen de aplicación o en ConfigMaps:

# ExternalSecret for OpenAI API key
# The secret data is stored in AWS Secrets Manager, GCP Secret Manager,
# or Azure Key Vault — never in plaintext in the repository.
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: openai-embedding-key
  namespace: ai-agent
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secret-store
    kind: SecretStore
  target:
    name: openai-embedding-key
  data:
  - secretKey: api-key
    remoteRef:
      key: ai-agent/prod/openai-embedding-key

---
# Pod mounts the ExternalSecret as a volume
apiVersion: v1
kind: Pod
metadata:
  name: agent-runtime
  namespace: ai-agent
spec:
  containers:
  - name: agent
    volumeMounts:
    - name: secrets
      mountPath: /etc/secrets
      readOnly: true
  volumes:
  - name: secrets
    secret:
      secretName: openai-embedding-key

El Patrón de Secretos Sin Disco

Para los despliegues de mayor seguridad, los secretos no deberían escribirse nunca en disco, ni siquiera como archivos montados. El patrón:

• Los secretos se obtienen al iniciar desde Vault o un almacén de secretos, y se guardan en memoria de la aplicación como un diccionario de Python o un map de Go.
• Los secretos nunca se registran en logs: implementa un sanitizador de logs personalizado que enmascare patrones de secretos conocidos (sk-proj-*, sk-*, valores api_key) antes de escribir entradas de log.
• Los secretos nunca se serializan: si la aplicación falla y escribe un core dump, las API keys en memoria quedan expuestas. Configura filtrado de core dumps y limita su retención.
• Acceso basado en leases: Cada secreto tiene un TTL. La aplicación debe manejar la rotación de secretos en runtime observando el lease y refrescando desde Vault antes de que expire.

En nuestras auditorías de despliegues de IA en producción, el hallazgo crítico más común no es un algoritmo débil ni un firewall mal configurado: es una API key incrustada en una imagen Docker que ha sido desplegada en 47 pods de producción, cada uno de los cuales registra la clave en cada solicitud de embeddings.

Enforcement de Políticas de Red para Cargas de Trabajo de IA

El Modelo de Seguridad de Tres Zonas Revisado

El modelo de segmentación de red de tres zonas (ejecución, inferencia, datos) introducido en nuestro artículo de arquitectura de red proporciona la base estructural para la seguridad. El enforcement se implementa mediante Kubernetes NetworkPolicies:

# Default deny all ingress/egress for the AI agent namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ai-agent
  namespace: ai-agent
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

---
# Allow execution zone to call inference zone
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-agent-to-llm
  namespace: ai-agent
spec:
  podSelector:
    matchLabels:
      app: agent-runtime
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          zone: inference
    ports:
    - port: 443  # HTTPS to LLM API endpoint
  policyTypes:
  - Egress

---
# Allow execution zone to call data zone (vector DB)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-agent-to-vector-db
  namespace: ai-agent
spec:
  podSelector:
    matchLabels:
      app: agent-runtime
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          zone: data
      podSelector:
        matchLabels:
          app: qdrant
    ports:
    - port: 6334  # gRPC
  policyTypes:
  - Egress

Controles de Egress a Internet

Las cargas de trabajo de agentes de IA tienen una necesidad legítima de egress a internet: las llamadas a APIs de embeddings, las llamadas a APIs de LLM y el acceso a registros de modelos requieren conectividad externa. El desafío de seguridad es garantizar que solo ocurra egress autorizado:

• Gateway de egress dedicado para tráfico de APIs de IA: Enruta todas las llamadas a APIs de embeddings y LLM mediante un forward proxy dedicado (Squid, Envoy o un NAT gateway cloud). Este proxy aplica políticas de allow-list por dominio: solo api.openai.com, api.cohere.com y endpoints conocidos similares están permitidos.
• Registro de auditoría de egress: Cada conexión saliente se registra con identidad del pod origen, destino, tamaño de solicitud y estado de respuesta. En un despliegue de producción que procesa 200 consultas/segundo, esto genera aproximadamente 17 millones de logs por día; envíalos a un SIEM con compresión y sampling.
• Sin acceso directo a internet para servicios de la zona de datos: Las bases de datos vectoriales y almacenes de metadatos nunca deben tener egress directo a internet. Todo intercambio externo de datos para estos servicios pasa por un gateway controlado con allowlisting explícito.

# Egress allowlist for AI API traffic
# Cilium Clusterwide NetworkPolicy
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: ai-egress-allowlist
spec:
  endpointSelector:
    matchLabels:
      egress-role: ai-api
  egress:
  - toFQDNs:
    - matchName: "api.openai.com"
    - matchName: "api.cohere.com"
    - matchName: "api.voyageai.com"
    - matchName: "api.anthropic.com"
    toPorts:
    - ports:
      - port: "443"
        protocol: TCP
  - toEndpoints:
    - matchLabels:
        "k8s:io.kubernetes.pod.namespace": kube-system
        "k8s:k8s-app": kube-dns
    toPorts:
    - ports:
      - port: "53"
        protocol: ANY
      rules:
        dns:
        - matchPattern: "*"
  - toCIDR:
    # Internal Vault service VIP or load balancer only.
    # Replace with your exact Vault address; do not allow all RFC1918 space.
    - 10.32.14.25/32
    toPorts:
    - ports:
      - port: "8200"
        protocol: TCP
  - toCIDR:
    # Kubernetes API endpoint only, if this workload truly needs it.
    - 10.32.0.1/32
    toPorts:
    - ports:
      - port: "6443"
        protocol: TCP

Enforcement de mTLS a Nivel de Red

Cilium e Istio pueden aplicar tráfico autenticado entre servicios por debajo de la capa de aplicación, lo que reduce la posibilidad de que un pod comprometido evite la autenticación de pares conectándose directamente a la IP del servicio objetivo. Valida la semántica exacta en tu mesh: la autenticación mutua de Cilium todavía está documentada como beta, depende de SPIFFE/SPIRE, funciona solo dentro de un clúster gestionado por Cilium, no es compatible con compartir un trust domain mediante Cluster Mesh y no reemplaza la configuración de cifrado ni la autorización de aplicación.

# Cilium mTLS enforcement for the AI agent namespace
# Only pods with valid SPIFFE identities can communicate
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: enforce-mtls-agent
  namespace: ai-agent
spec:
  endpointSelector:
    matchLabels:
      app: agent-runtime
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: api-gateway
    authentication:
      mode: "required"  # Require Cilium mutual authentication

Registro de Auditoría para Acciones de Agentes

Qué Registrar

El registro de auditoría para sistemas de agentes de IA debe capturar la cadena completa de eventos de autenticación y autorización:

• Eventos de autenticación: Cada intento de autenticación entre servicios: éxito, fallo y la identidad presentada.
• Decisiones de autorización: Cada decisión de control de acceso: qué identidad accedió a qué colección, con qué acción (lectura/escritura/búsqueda) y si fue permitida o denegada.
• Eventos de acceso a secretos: Cada recuperación de un secreto desde el backend de secretos, incluyendo qué workload lo solicitó y con qué duración de lease.
• Creación y rotación de API keys: Cuándo se crea, rota o revoca una API key, incluyendo la identidad admin que realizó la acción.
• Cambios en políticas de red: Cambios a objetos NetworkPolicy que podrían afectar la postura de seguridad de cargas de trabajo de IA.

# Structured audit log entry for a vector database query
{
  "timestamp": "2026-07-20T08:00:00.123Z",
  "event_type": "vector_search",
  "identity": {
    "spiffe_id": "spiffe://nsi.io/agent/runtime/prod-querier",
    "kubernetes_pod": "agent-runtime-7d8f9c",
    "kubernetes_namespace": "ai-agent"
  },
  "target": {
    "service": "qdrant",
    "collection": "internal-wiki",
    "action": "search"
  },
  "authorization": {
    "result": "permit",
    "policy": "qdrant-collection-rbac-v2",
    "reason": "collection scope matched"
  },
  "network": {
    "source_ip": "10.0.1.42",
    "destination_ip": "10.0.2.15",
    "protocol": "gRPC",
    "mtls_enforced": true
  }
}

Runbooks Operativos para Incidentes de Seguridad de IA

API Key de Embeddings Comprometida

Síntoma: Pico repentino en costos de la API de embeddings, patrones inusuales de embeddings (embedding de texto que no corresponde a documentos) o alertas del proveedor por uso sospechoso de API. Acción inmediata: Rota la clave comprometida en el portal del proveedor y en Vault simultáneamente. Para Vault KV v2, escribe una nueva versión de datos con vault kv patch -mount=secret ai-agent/production/embedding openai-api-key=<new-key> para una actualización parcial, o vault kv put -mount=secret ai-agent/production/embedding openai-api-key=<new-key> ... cuando reemplaces el payload completo del secreto. Después fuerza o espera la reconciliación de External Secrets Operator según su refreshInterval. Investigación de causa raíz: Revisa los logs de auditoría de Vault para identificar qué pod recuperó la clave; luego revisa los logs de red del pod para detectar patrones de exfiltración. Remediación: Implementa rotación de claves con TTL máximo de lease de 24 horas y habilita alertas de uso del proveedor a 2x del gasto diario normal.

Acceso No Autorizado a la Base de Datos Vectorial

Síntoma: Logs de autorización denegada desde Qdrant o Pinecone, o descubrimiento de colecciones desconocidas en la base de datos vectorial. Acción inmediata: Revoca todas las API keys y vuelve a emitirlas con alcances más estrictos. Habilita la configuración audit_log de Qdrant para capturar cada consulta con metadatos de identidad. Causa raíz: Normalmente una NetworkPolicy mal configurada o una credencial filtrada. Revisa si el acceso no autorizado vino desde dentro del clúster (violación de NetworkPolicy) o desde fuera (endpoint expuesto). Remediación: Verifica el enforcement de NetworkPolicy con cilium connectivity test e implementa reglas estrictas de ingreso en todos los puertos de Qdrant.

Fuga de Secretos mediante Logs de Aplicación

Síntoma: API keys que aparecen en sistemas de agregación de logs (ELK, Datadog, Splunk) o alertas de un scanner de secretos (GitGuardian, truffleHog o scanner personalizado basado en regex) sobre archivos exportados de logs. Acción inmediata: Rota la clave filtrada y limpia los logs. Implementa un sanitizador de logs que redacte patrones coincidentes con (sk-[A-Za-z0-9_-]{20,}) para claves estilo OpenAI, patrones específicos por proveedor mantenidos en un scanner central y (eyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}) para tokens JWT. Causa raíz: El código de aplicación registra el objeto completo de solicitud, incluyendo el encabezado Authorization o el parámetro de API key. Remediación: Agrega middleware de sanitización de logs que intercepte todos los mensajes de log y enmascare patrones de secretos conocidos antes de escribirlos.

Conclusión

Asegurar infraestructura de agentes de IA requiere el mismo rigor que asegurar cualquier sistema distribuido, con atención adicional a la superficie de amenazas particular de los pipelines de LLM y embeddings. Los controles de seguridad que protegen microservicios tradicionales (mTLS, RBAC, gestión de secretos, políticas de red y registro de auditoría) aplican directamente, pero deben adaptarse a los patrones de carga específicos de IA: llamadas a APIs externas de embeddings, patrones de consulta en bases de datos vectoriales que revelan estructura de colecciones y los distintos radios de impacto de claves robadas de proveedor, workers de embeddings comprometidos y credenciales filtradas de bases de datos vectoriales.

Los cuatro principios que guían la seguridad de infraestructura de IA son: autenticar cada interacción entre servicios en la capa de transporte (mTLS elimina una clase completa de ataques de robo de credenciales), autorizar a nivel de colección (RBAC para bases de datos vectoriales evita acceso entre colecciones incluso dentro del mismo clúster), gestionar secretos con acceso basado en leases (credenciales de corta duración con rotación automática eliminan la ventana de exposición de credenciales) y aplicar segmentación de red a nivel de política (NetworkPolicies de denegación por defecto con gateways de egress dedicados para tráfico de APIs de IA).

Los sistemas de agentes de IA se están convirtiendo en la arquitectura por defecto para workflows de inteligencia en producción. La seguridad debe integrarse en la infraestructura desde el primer día, no añadirse después de una fuga de credenciales o exposición de datos. Los controles descritos en esta guía proporcionan la base para un despliegue de IA seguro a cualquier escala.

En seguridad de agentes de IA, la pregunta nunca es si tu sistema será probado; es si tus capas de autenticación y autorización resistirán cuando ocurra.