Seguridad y cumplimiento

Seguridad desde el diseño

No es seguridad por encima. SHARA está construido como sistema multi-tenant aislado por defecto, con red-team continuo, kill-switches automáticos y auditoría externa programada antes del lanzamiento general.

Estado en tiempo real Plan Local (on-premise)
Estado en tiempo real · status.aiginer.com
7
Capas de defensa independientes
54
Casos red-team adversariales
9.7k+
Tests automáticos verdes
≥95%
Neutralización OWASP LLM
Defense-in-depth

Siete capas independientes

Que falle una no compromete las siguientes. Cada request atraviesa todas antes de tocar tus datos.

Capa 1, Edge

Cloudflare en front: rate-limit, WAF, anti-DDoS, Turnstile en formularios públicos.

Capa 2, Auth

Supabase JWT con AAL2 enforcement. Slow-down per-IP y lockout per-(user,factor) tras 5 intentos fallidos.

Capa 3, Tenant context

Middleware que resuelve tenant del JWT, revalida la membership en BD en cada request, la revocación se aplica al instante.

Capa 4, RBAC + plan gate

Role gate por endpoint (CEO/admin/operator/viewer). Plan gate por agente (First/Pro/Max).

Capa 5, Vault AES-256-GCM

Refresh tokens y secretos cifrados por tenant con scrypt KDF + AAD. Master ≥32 chars. Hard-fail en producción si sale dev placeholder.

Capa 6, Redactor + sanitizer

Toda respuesta pasa por filtro: oculta nombres reales del modelo y strippea password/token/refreshToken antes de salir al cliente.

Capa 7, Audit log + kill-switches

Cada acción de cada agente queda registrada (autor, timestamp, coste). Kill-switches automáticos cortan el grifo si algo se descontrola.

Anatomía de un login

Qué pasa cuando alguien intenta entrar

Cada paso es un check independiente. Si uno falla, no hay siguiente.

  1. 1

    Edge anti-DDoS

    Cloudflare WAF + rate-limit por path.

  2. 2

    Trust proxy validado

    request.ip via TRUST_PROXY_CIDR. Imposible spoofear el IP por header.

  3. 3

    Slow-down + lockout

    Brute-force de 6 dígitos TOTP imposible en la ventana de 30 s.

  4. 4

    JWT verify con alg pinned

    Algoritmo del token NO se acepta del header, solo desde server config.

  5. 5

    AAL2 enforcement

    Decorador requireAal2 para endpoints sensibles. Si tu cuenta tiene 2FA, sin código no entras.

  6. 6

    TenantContext live

    Membership revalidada en BD por cada request, la revocación se aplica al instante, no en el próximo refresh.

  7. 7

    RBAC role gate

    Solo CEO + admin acceden al panel /panel/*. Operadores y viewers ven 'Sin acceso' aunque tengan sesión.

  8. 8

    Sanitizer + redactor

    Output strippea password/token/refresh; redactor oculta nombres de modelo. Watchdog P0 si algo se cuela.

Cumplimiento normativo

RGPD y EU AI Act, listos para auditoría

RGPD

  • DPA firmable como encargado del tratamiento
  • Derechos ARCO automatizados (acceso, rectificación, supresión, portabilidad)
  • Registro de actividades del tratamiento (RAT)
  • DPIA del producto disponible bajo NDA
  • Notificación brechas en <72h (procedimiento documentado)
  • Hosting principal en Alemania (Contabo + Cloudflare EU)

EU AI Act

  • Sistema clasificado como riesgo limitado
  • Transparencia: el usuario sabe que habla con un agente IA
  • Trazabilidad completa de decisiones automáticas
  • Human-in-the-loop configurable por workflow
  • Documentación técnica disponible bajo NDA
  • Logging completo de prompts y respuestas para auditoría

Hosting y transferencias internacionales

Servidor principal: Contabo Alemania + Cloudflare EU. Auth: Supabase EU. Algunas llamadas a proveedores LLM transitan por EE.UU., usamos cláusulas tipo SCCs + DPA + adendum + DPF cuando aplica. La lista completa de sub-encargados está en /sub-encargados.

Si necesitas evitar cualquier transferencia internacional (sectores regulados, contratos públicos, salud), Plan Local elimina el problema: los datos nunca salen de tu infraestructura y la inferencia corre on-premise sobre el modelo Concerto local.

Aislamiento

Multi-tenant con doble capa

Cada cliente tiene su propio espacio aislado. Aplicamos dos barreras independientes para que un fallo en una no comprometa los datos del otro tenant.

  • Capa 1, `tenantContext` middleware: cada request resuelve el tenant_id desde el JWT y revalida la membership en BD por cada llamada. Si te revocan acceso, lo notas al instante (no en el próximo refresh).
  • Capa 2, RLS Postgres (pre-GA): políticas Row-Level Security a nivel de motor que rechazan queries cruzadas aunque el app-layer falle. Activación programada antes del lanzamiento general.

En Plan Local cada cliente tiene su propia base de datos Postgres dedicada, el aislamiento es físico, no solo lógico.

// pseudo-policy RLS (pre-GA)
CREATE POLICY tenant_isolation
  ON all_tenant_tables
  USING (
    tenant_id =
    current_setting('app.tenant_id')::uuid
  );

// middleware doble (hoy)
app.use(authRequired);
app.use(tenantContext);
// findMembership(user.id, tenant_id) en cada PATCH/DELETE
Red-team continuo

Anti-prompt-injection probado

Suite de 54 casos adversariales que se ejecuta en cada release. Si el % de neutralización cae por debajo del 95%, el release se bloquea automáticamente.

OWASP LLM Top 10 · 44 casos

Cubrimos las 10 categorías: prompt injection (LLM01), insecure output handling (LLM02), training data poisoning (LLM03), DoS, supply chain, sensitive info disclosure, plugin vulnerabilities, excessive agency, overreliance, model theft.

SHARA-specific · 10 casos

Casos propios: intentos de filtración del modelo real, escalada cross-agent no autorizada, manipulación de IDENTITY.md vía prompt, bypass de cuotas y kill-switches, exfiltración de tokens del vault.

Release blocker

Si en CI el porcentaje neutralizado <95%, el release se cancela. La regresión es bug P0, release-blocking. Cada caso es reproducible y revisado por el equipo de seguridad.

Medidas técnicas

Catálogo completo de controles

Cada categoría con detalle granular de qué hacemos exactamente.

Auth · Sesión (7 controles)
  • Supabase JWT con verificación AAL2 server-side (decorador `requireAal2`).
  • MFA TOTP + 8 backup codes single-use scrypt-hashed (descargables PDF/TXT).
  • OAuth Google + Microsoft con PKCE (RFC 8252).
  • Slow-down per-IP en login + MFA + OAuth + onboarding accept + activation-keys redeem.
  • Lockout per-(user,factor) 10 min tras 5 intentos fallidos.
  • Comparaciones de tokens en tiempo constante (`crypto.timingSafeEqual`).
  • Algoritmo JWT pinned desde server config, no se lee del header del token.
Multi-tenant · RBAC (7 controles)
  • `tenantContext` middleware que resuelve tenant_id desde el JWT y revalida membership en BD por cada request (sin fast-path).
  • PATCH/DELETE en cualquier resource del tenant requieren `findMembership` live + role en allowlist.
  • 6 roles canónicos: CEO/owner, admin, director, operator, admin_it, viewer.
  • 20 departamentos canónicos con slugs validados.
  • Department gate: empleado de ventas no accede al perfil del agente legal.
  • Memory cross-user lockdown: nadie puede leer/borrar memoria personal de otro user del mismo tenant.
  • Plan Local: DB Postgres dedicada, aislamiento físico, no solo lógico.
Modelo · Aliases secretos (6 controles)
  • El cliente NUNCA ve el nombre real del modelo subyacente.
  • Aliases públicos: Prelude · Sonata · Symphony · Concerto (Plan Local).
  • Redactor cubre los IDs de producción reales testeados en CI antes de cada release.
  • Cada `errorMessage` de SDK externo pasa por `redact()` antes de persistir o devolver al cliente.
  • Watchdog `hasLeakedModelName` después de cada redact, log P0 si detecta leak.
  • `/healthz` expone aliases neutros (`llm_a`, `llm_b`), no nombres de proveedor.
Anti prompt-injection (5 controles)
  • Suite de 54 casos adversariales (44 OWASP LLM Top 10 + 10 SHARA-specific).
  • Wrapping `<customer_message>` para todo content externo de empleados o webhooks.
  • Envelope `<<UNTRUSTED_BEGIN>>...<<UNTRUSTED_END>>` para JSON externo.
  • CI bloquea release si % neutralizado < 95 %.
  • Tool `escalate_to_amadeus` re-verifica la capacidad del usuario originador (no del agente).
Coste · Kill-switches v5 (6 controles)
  • Cap por run: 5 €. Si un solo run lo supera, se aborta y el agente queda en pausa.
  • Cap por hora: 50 €/h. Inferencia se cierra hasta release manual o automático.
  • Cap por día: 400 €/día. Equivalente a stop-loss completo del tenant.
  • Auto-release programado fuera de horario laboral (TZ-aware).
  • Modo ahorro nocturno: Symphony→Sonata, Sonata→Prelude, Prelude max_tokens=500.
  • Boot assert: el binario refuse to start en producción si los kill-switches no están cableados.
Webhooks entrantes · Firma (6 controles)
  • HMAC SHA-256/512 con verificación timing-safe.
  • Timestamp ±300 s ventana anti-replay.
  • Dedupe per-(tenant, eventId) con UNIQUE constraint en BD + LRU 1 h.
  • Webhook secrets per-tenant, nunca compartido global entre clientes.
  • OAuth state con delete-on-read (single-use) + binding al user que inició el flow.
  • MCP gateway con SSRF guard que bloquea IPs privadas + metadata services.
Crypto · Vault (6 controles)
  • Refresh tokens OAuth y webhook secrets cifrados con AES-256-GCM.
  • KDF scrypt por tenant (cada tenant deriva su propia clave del master).
  • AAD ata el ciphertext al tenantId, dos tenants con misma key NO pueden intercambiar datos.
  • Master secret obligatorio ≥32 chars (boot-warn si menos).
  • Versioning explícito (`aeadv2.` writer-only en producción) con backward-compat readable de legacy.
  • License client refuse to start en producción si carga la dev pubkey por error.
Auditoría · Trazabilidad (4 controles)
  • `audit_logs` inmutables con autor, timestamp, recurso, before/after.
  • IDENTITY.md evoluciona vía PATCH (nunca REPLACE) con histórico completo.
  • Logs estructurados con pino + redact configurado (auth headers, password, token, refreshToken, errorMessage SDK).
  • Activation keys solo guardamos hash scrypt-PHC; el plaintext jamás se loggea.

¿Necesitas auditar SHARA en profundidad?

Compartimos DPIA, threat model, threat-model report y resultados completos del red-team bajo NDA en planes Max y Plan Local.

Solicitar info de seguridad Plan Local (on-premise)

También puedes consultar el estado en tiempo real o reportar una vulnerabilidad responsable a security@aiginer.com.

DPA / Encargado del tratamiento

Texto completo del acuerdo

Sub-encargados

Lista actualizada de proveedores

Política IA

Cómo usamos modelos de IA