Seguridad

Diseño de seguridad. Tres reglas, todas verificables.

Tres reglas guían el diseño: no se almacena ningún secreto que no haga falta, el personal nunca ve el contenido de las peticiones y cada acción sensible queda en un registro de auditoría verificable.

Este es el diseño de la plataforma, que se está construyendo ahora. Una prueba de penetración externa lo verificará antes de que el primer cliente entre en producción.

Secretos mínimos: Las claves se muestran una vez y se guardan como HMAC; las credenciales de proveedor, solo en Key Vault.
Contenido fuera del alcance del personal: Ninguna API interna devuelve prompts ni respuestas.
Todo queda escrito: Auditoría de solo inserción, encadenada por hash, verificable y exportable.

Claves de API. Se muestran una vez y no se pueden recuperar.

Formato situ_live_<id público>_<secreto> (y situ_test_ para el sandbox, el entorno de pruebas). El secreto tiene al menos 256 bits de entropía.

Solo se almacena HMAC-SHA256(pimienta, secreto). La pimienta vive en Azure Key Vault (HSM gestionado) y tiene versiones, de modo que se puede rotar sin invalidar las claves existentes.

Cada clave pertenece a un proyecto, tiene caducidad obligatoria y lista de modelos opcional. La revocación llega a todas las réplicas de la pasarela en torno a un segundo.

Aislamiento entre organizaciones. Impuesto por la base de datos.

Todas las tablas de inquilino llevan org_id y seguridad a nivel de fila de Postgres con FORCE ROW LEVEL SECURITY: ni el propietario de la tabla puede saltársela.

Cada petición de la consola se ejecuta en una transacción que fija la organización activa; la base de datos es la última línea de defensa, no la aplicación.

El back office usa un rol de base de datos distinto. Toda lectura de otra organización exige un motivo y deja un registro en la auditoría de esa organización.

Contenido. Por defecto, solo metadatos.

Se registra quién, qué modelo, cuántos tokens, coste, latencia y estado. Los prompts y las respuestas no se guardan.

Si un proyecto activa el registro de contenido, se cifra con AES-256-GCM bajo la clave de datos de la organización, con retención de 0 a 365 días. Borrar esa clave hace ilegible el contenido (borrado criptográfico).

Las rutas de retención cero solo existen en modelos cuyo proveedor la ofrece, y la consola indica cuáles son.

Registro de auditoría. Una cadena de hashes que delata cualquier manipulación.

El registro de auditoría y el libro de créditos son de solo inserción: el rol de la aplicación no tiene UPDATE ni DELETE.

Cada fila guarda el hash de la anterior, calculado por la propia base de datos. La cadena se puede comprobar desde la consola y exportar en JSONL para verificarla de forma independiente.

Cada operación que modifica datos escribe su registro en la misma transacción. Nunca con secretos. El registro también se puede enviar en streaming al SIEM de la organización por HTTPS.

Ejemplo de cadena

#1041 project.update user prev 9c2e…71ab hash a3f1…0d42
#1042 api_key.create user prev a3f1…0d42 hash 5b7c…e913
#1043 admin.read staff prev 5b7c…e913 hash d08e…42fa

Personal y back office. Sin privilegios permanentes.

El back office solo es accesible desde red privada, con SSO de Microsoft Entra ID y llaves de seguridad físicas, separado de la identidad de clientes.

Sin privilegios permanentes más allá de metadatos de solo lectura. Los roles elevados se conceden a demanda, por un máximo de 12 horas, mediante una solicitud aprobada.

Aprobación a cuatro ojos —quien solicita no puede aprobar, y lo impone una restricción de la base de datos— para suspender o reactivar organizaciones, ajustar créditos, cambiar límites de crédito o modo de facturación, tocar credenciales de proveedor, restablecer la verificación en dos pasos de un usuario y conceder elevaciones.

Cadena de suministro. Qué se ejecuta, firmado y trazable.

Imágenes de contenedor firmadas con cosign, un SBOM por versión y dependencias fijadas. Los adaptadores de proveedor proceden de Bifrost (Apache 2.0) en una versión fijada y auditada.

SAST, DAST y análisis de dependencias en CI. El código crítico —autenticación, claves, multiinquilino, facturación— necesita la revisión de una segunda persona.

Está desactivada cualquier función que descargue URL indicadas por el cliente: una pasarela que las descarga es un vector de SSRF dentro de la red.

Atestación de residencia. Cada respuesta lleva su propia evidencia.

La pasarela firma con Ed25519, para cada petición, qué ruta, proveedor, región y nivel la sirvieron. La clave privada vive en Azure Key Vault; las públicas se publican para que cualquiera pueda verificar sin depender de Situra.

Cabecera del token

{ "alg": "EdDSA", "typ": "situra-residency+jwt", "kid": "7c1e…a90b" }

Claims firmados

{
  "iss": "gw-spaincentral-…",
  "rid": "req_8354f6fb…",
  "iat": 1790391273,
  "org": "…", "prj": "…", "kid_pub": "…",
  "model": "gpt-5-mini",
  "route": "…",
  "provider": "azure-openai",
  "region": "spaincentral",
  "residency": "es",
  "project_residency": "es",
  "attempts": 1
}

Ed25519

sign(base64url(header) + "." + base64url(claims))

Claims firmados
`rid`	Identificador de la petición (igual que x-request-id)
`iat`	Momento de emisión (segundos Unix)
`iss`	Instancia de la pasarela que enrutó la petición
`org · prj`	Organización y proyecto
`kid_pub`	Parte pública de la clave de API usada (nunca el secreto)
`model`	Modelo solicitado por el cliente
`route · provider · region`	Ruta del catálogo, proveedor y región que sirvieron la petición
`residency`	Nivel de la ruta que la sirvió: es, eu o global
`project_residency`	Nivel exigido por el proyecto
`attempts`	Rutas intentadas (las alternativas nunca salen del nivel permitido)

Qué demuestra

Qué ruta, proveedor y región sirvieron esa petición concreta, y con qué nivel de residencia.
Que lo afirma la pasarela de Situra, con una firma Ed25519 que cualquiera puede comprobar sin confiar en nosotros ni en la consola.
Que el token no se ha alterado: cambiar un solo carácter invalida la firma.

Qué no demuestra

Lo que ocurre dentro del proveedor del modelo: eso depende de sus compromisos regionales y de su contrato como subencargado.
Es una declaración firmada por Situra, no una certificación de terceros.

Verificación independiente

Las claves públicas se publican como JWKS (OKP, Ed25519) en https://api.situra.ai/.well-known/situra-attestation-keys. El mismo token se guarda con los metadatos de la petición, para que aparezca en la consola y en las exportaciones de auditoría.

 Terminal  
 # 1. Haz una petición y guarda la cabecera
curl -sD - -o /dev/null https://api.situra.ai/v1/chat/completions \
  -H "Authorization: Bearer $SITURA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-5-mini","messages":[{"role":"user","content":"Hola"}]}' \
  | grep -i '^x-situra-attestation:'

# 2. Descarga las claves públicas de la pasarela
curl -s https://api.situra.ai/.well-known/situra-attestation-keys 

 verify_attestation.py  
 import base64, json, sys, urllib.request
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

GATEWAY = "https://api.situra.ai"
token = sys.argv[1]  # valor de la cabecera x-situra-attestation

def b64d(s: str) -> bytes:
    return base64.urlsafe_b64decode(s + "=" * (-len(s) % 4))

header_b64, claims_b64, sig_b64 = token.split(".")
header = json.loads(b64d(header_b64))
assert header["alg"] == "EdDSA" and header["typ"] == "situra-residency+jwt"

jwks = json.load(urllib.request.urlopen(f"{GATEWAY}/.well-known/situra-attestation-keys"))
jwk = next(k for k in jwks["keys"] if k["kid"] == header["kid"])
key = Ed25519PublicKey.from_public_bytes(b64d(jwk["x"]))
key.verify(b64d(sig_b64), f"{header_b64}.{claims_b64}".encode())  # lanza excepción si no es válida

claims = json.loads(b64d(claims_b64))
print("verified:", claims["rid"], claims["residency"], claims["region"], claims["provider"]) 

 verify-attestation.mjs  
 import { createPublicKey, verify } from "node:crypto";

const GATEWAY = "https://api.situra.ai";
const token = process.argv[2]; // valor de la cabecera x-situra-attestation
const [h, c, s] = token.split(".");
const header = JSON.parse(Buffer.from(h, "base64url"));
if (header.alg !== "EdDSA" || header.typ !== "situra-residency+jwt") throw new Error("not an attestation");

const { keys } = await (await fetch(`${GATEWAY}/.well-known/situra-attestation-keys`)).json();
const jwk = keys.find((k) => k.kid === header.kid);
const ok = verify(null, Buffer.from(`${h}.${c}`), createPublicKey({ key: jwk, format: "jwk" }), Buffer.from(s, "base64url"));
if (!ok) throw new Error("bad signature");

const claims = JSON.parse(Buffer.from(c, "base64url"));
console.log("verified:", claims.rid, claims.residency, claims.region, claims.provider); 

Verificación externa. Lo que comprobarán terceros.

Prueba de penetración externa: Antes de que el primer cliente entre en producción; después, anual y tras cambios importantes.
Pruebas de aislamiento: Pruebas automáticas que demuestran que las lecturas entre inquilinos fallan.
Auditoría ENS + ISO 27001: Auditoría conjunta de certificación prevista para Q2–Q3 2027.

Identidad de clientes

Verificación en dos pasos obligatoria antes de acceder a datos de la organización: llave de acceso (passkey, WebAuthn) o app de autenticación (TOTP), con códigos de recuperación. Cada organización puede exigir una verificación resistente al phishing (solo llaves de acceso). Restablecer la verificación en dos pasos de un usuario requiere la aprobación de dos personas del equipo de Situra. El inicio de sesión en la consola usa el OIDC de la plataforma, con aprovisionamiento SCIM limitado a dominios verificados. SSO con el proveedor de identidad de la organización (OIDC, y SAML a través de un IdP como Zitadel): previsto.

Divulgación responsable

Las vulnerabilidades se pueden comunicar a security@situra.ai antes de hacerlas públicas. Respondemos en español o en inglés. La política se publica en security.txt.

Centro de confianza: documentos y estado de cumplimiento Hoja de ruta de cumplimiento

Beta privada · Q4 2026

Buscamos entre tres y cinco organizaciones para la beta.

Administraciones públicas españolas y organizaciones reguladas que quieran usar modelos de IA con la residencia de datos bajo control. El acompañamiento incluye la categorización ENS, el DPA y la integración.

Solicitar acceso a la beta Crear cuenta y probar con claves de pruebas