Seguridad Automatización IA: API Keys y Secretos

Parte 1 de 3 | Parte 1 | Parte 2 | Parte 3

Hace dos meses, un colega me reenvió una captura de una API key de n8n filtrada en un repositorio público de GitHub. La key tenía acceso total a su proveedor de LLM, y en horas un atacante acumuló $12k en llamadas no autorizadas y exfiltró PII de clientes mediante prompt injection. Peor aún, usó el pipeline comprometido para enviar phishing a 10k clientes. La brecha costó $450k en multas, honorarios legales y clientes perdidos.

He auditado docenas de configuraciones de seguridad en automatización de IA, y el 80% tiene brechas críticas: API keys hardcodeadas, webhooks sin validar, ningún control sobre datos enviados a LLMs y ningún plan de respuesta a incidentes. Una sola brecha puede costar 10 veces lo que gastas en APIs de LLM en un año.

Este es el stack de seguridad exacto que uso para cada pipeline de automatización de IA en producción, probado en más de 40 auditorías y 6 despliegues en 3 años. Ha prevenido 4 brechas mayores en los últimos 18 meses.

¿Qué es la Seguridad en Automatización de IA?

Son las prácticas, herramientas y configuraciones para proteger flujos de trabajo automatizados que integran LLMs contra accesos no autorizados, fugas de datos y abuso. Incluye asegurar todo el flujo: desde webhooks hasta llamadas a APIs de LLM y sistemas downstream.

A diferencia de la automatización tradicional, los pipelines de IA introducen riesgos únicos:

• APIs medidas por uso: Uso no autorizado quema presupuesto rápido, he visto facturas de $50k/mes por keys comprometidas
• Prompt Injection: Atacantes engañan a LLMs para acciones maliciosas o exfiltración
• Exfiltración de Datos: LLMs forzados a compartir PII, PHI o datos de pago
• Fuga de PII: Datos sin enmascarar violan GDPR/CCPA y generan multas masivas
• Sesgo del Modelo: Outputs discriminatorios que crean responsabilidad legal

Cada capa del pipeline necesita controles de seguridad, del ingress al egress.

Gestión de Secretos

Las API keys hardcodeadas son la vulnerabilidad #1 que encuentro. He visto keys en repos públicos de Git, en variables de entorno en texto plano, en logs y en Slack.

Siempre uso HashiCorp Vault para producción. Soporta secretos dinámicos (API keys que expiran automáticamente), logs detallados y control de acceso granular.

Patrón de inyección de secrets con Vault Agent:

# k8s-encrypted-secret.yaml (usando Vault Injector)
apiVersion: v1
kind: Pod
metadata:
  name: n8n-worker
  namespace: ai-pipelines
  annotations:
    vault.hashicorp.com/agent-inject: "true"
    vault.hashicorp.com/agent-inject-secret-llm-key: "secret/data/ai-pipelines/llm-api-key"
    vault.hashicorp.com/agent-inject-template-llm-key: |
      {{- with secret "secret/data/ai-pipelines/llm-api-key" -}}
      {{ .Data.data.key }}
      {{- end }}
    vault.hashicorp.com/role: "ai-pipelines-worker"
    vault.hashicorp.com/agent-pre-populate: "true"
spec:
  serviceAccountName: n8n-worker
  containers:
  - name: n8n
    image: n8nio/n8n:1.80.0
    env:
    - name: LLM_API_KEY
      valueFrom:
        secretKeyRef:
          name: vault-injected-secrets
          key: llm-key
    resources:
      requests:
        cpu: 500m
        memory: 1Gi
      limits:
        cpu: 1
        memory: 2Gi
  - name: vault-agent
    image: hashicorp/vault:1.15.0

FAQ

¿Cuál es el mayor riesgo de seguridad en pipelines de automatización de IA?

Las API keys hardcodeadas. Las encuentro en el 80% de las auditorías. Una key filtrada puede costar $20k-$50k en llamadas no autorizadas en horas. La solución es HashiCorp Vault con secretos dinámicos.

¿Cómo evito fugas de API keys en repositorios Git?

Usa .gitignore para .env, ejecuta git-secrets o talisman como pre-commit hook, y escanea el historial con trufflehog. También bloqueo commits con patrones como sk- usando un pre-receive hook en GitHub o GitLab.

¿Son seguros los Kubernetes Secrets para producción?

No, por defecto no. Están codificados en base64, no encriptados. Cualquiera con acceso get a la API de Secrets puede decodificarlos. Usa un operador de secrets externo (Vault, External Secrets Operator o SOPS).

¿Debo usar LLMs self-hosted o de terceros para datos sensibles?

Self-hosted reduce el riesgo de exfiltración porque los datos nunca salen de tu red. Las APIs de terceros son más fáciles pero arriesgan fugas al proveedor. Para PII, PHI o datos financieros, siempre recomiendo self-hosted.

¿Cada cuánto rotar las API keys de LLM?

Cada 90 días como mínimo. Para pipelines de alto riesgo, usa secretos dinámicos de Vault que expiran en 24 horas. La rotación en Vault propaga nuevas keys a los pods automáticamente.

Siguientes Pasos

La gestión de secretos es la base. En la Parte 2 cubro seguridad de webhooks, validación HMAC, enmascaramiento PII y network policies.

Partes de esta serie: Parte 2 →