Seguridad

Lo que hacemos con tus datos, mecanismo a mecanismo

Esta página no lleva sellos. Lleva lo que está construido, cómo funciona y qué lo comprueba. Y termina con la lista de lo que todavía no tenemos, que es la parte que suele faltar en estas páginas.

7
Capas que atraviesa cada petición
54
Ataques de manipulación en la suite
34
Acciones que esperan tu firma
15.000+
Casos de prueba en el repositorio

Defensa por capas

Siete capas independientes

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

  1. 01

    La entrada

    Todo el tráfico pasa antes por Cloudflare: cortafuegos, límite de peticiones, protección contra ataques de denegación y verificación anti-robot en los formularios públicos.

  2. 02

    La identidad

    Sesión firmada y verificada en cada petición, con el algoritmo de la firma fijado por el servidor. Tras cinco intentos fallidos la respuesta se ralentiza, y luego la cuenta se bloquea diez minutos.

  3. 03

    La empresa

    En cada petición se vuelve a comprobar en la base de datos a qué empresa perteneces y con qué permisos. Si te retiran el acceso, deja de funcionar al instante, no en la siguiente sesión.

  4. 04

    El permiso

    Cada operación comprueba dos cosas por separado: que tu papel puede hacerla y que tu plan incluye ese agente. Fallar cualquiera de las dos la detiene.

  5. 05

    Los secretos

    Las credenciales de tus conectores se guardan cifradas con AES-256-GCM y una clave distinta por empresa: el cifrado de una no sirve para abrir el de otra. Si no hay clave, no se guardan.

  6. 06

    La salida

    Todo lo que sale hacia ti pasa por un filtro que borra credenciales y oculta qué modelo hay detrás de cada agente. Y detrás del filtro hay un vigilante que vuelve a mirar.

  7. 07

    El registro

    Cada acción queda escrita con quién, cuándo y cuánto costó, y los registros van encadenados entre sí. Los topes de gasto cortan la ejecución solos si algo se dispara.

Anatomía de un acceso

Qué pasa cuando alguien intenta entrar

Cada paso es una comprobación independiente. Si una falla, no hay siguiente.

  1. 01

    Se filtra el tráfico

    Cortafuegos y límite de peticiones antes de que nada llegue a nuestros servidores.

  2. 02

    Se confirma de dónde vienes

    La dirección de origen se toma de la red, no de una cabecera que el visitante pueda escribir a mano.

  3. 03

    Se frena la fuerza bruta

    Tras cinco fallos la respuesta se ralentiza de forma creciente, y el bloqueo llega hasta los diez minutos. Adivinar un código de seis cifras dentro de sus treinta segundos de vida deja de ser posible.

  4. 04

    Se verifica la sesión

    El algoritmo con el que se comprueba la firma lo decide la configuración del servidor, nunca el propio testigo de sesión: uno que pida ser validado «a su manera» se rechaza.

  5. 05

    Se exige el segundo factor

    Si tu cuenta tiene 2FA, sin el código no se entra. Y hay operaciones que vuelven a pedirlo aunque ya hayas entrado.

  6. 06

    Se recomprueba tu empresa

    En cada petición, contra la base de datos. Lo que diga el testigo de sesión no basta: puede ir por delante de la realidad.

  7. 07

    Se comprueba tu papel

    A la administración de la plataforma solo se llega con un control aparte. El resto ve «sin acceso» aunque su sesión sea válida.

  8. 08

    Se limpia la respuesta

    Antes de salir hacia ti se borran credenciales y se oculta el modelo que hay detrás. Si algo se colara, la respuesta se sustituye entera y salta un aviso interno.

Cumplimiento

RGPD y Reglamento europeo de IA

Lo que está construido dentro del producto, no lo que está prometido en un documento.

RGPD

  • Acuerdo de encargado del tratamiento firmable desde la propia aplicación: quedan registrados el nombre, la fecha, la dirección de origen y la huella del texto exacto que firmaste.
  • Descarga de tus datos en un fichero, desde tu cuenta y sin pedírnoslo (derechos de acceso y portabilidad).
  • Baja de la cuenta con efecto inmediato: bloquea el acceso en el momento y queda registrada. El borrado físico definitivo todavía se hace a mano.
  • Procedimiento escrito para una brecha de datos, con su guía de actuación paso a paso.
  • Lista de subencargados publicada, con historial de cambios fechado.
  • Evaluación de impacto en borrador desde mayo de 2026, sin cerrar. Se comparte con esa etiqueta.

Reglamento europeo de IA

  • Siempre se sabe que quien responde es un agente, con qué nombre y de qué departamento. Nunca se presenta como una persona.
  • Trazabilidad de cada ejecución: qué agente intervino, qué herramientas usó, qué devolvió y cuánto consumió.
  • 34 acciones no se ejecutan solas: quedan en una bandeja esperando a que una persona las apruebe o las rechace.
  • La espera tiene plazo: si nadie decide, la petición caduca en vez de acabar ejecutándose sola.
  • La identidad y las instrucciones de cada agente se modifican por partes y con historial completo, nunca se sustituyen enteras.
  • Documentación técnica disponible bajo acuerdo de confidencialidad.

Dónde están los datos

Los datos del producto viven en un servidor propio dentro de la Unión Europea, no en una nube compartida. Las identidades y el inicio de sesión se gestionan aparte, en Irlanda (eu-west-1). La inferencia sale por un proveedor con entidad y centros de datos en la UE y sin retención: hay un guardarraíl en el código que ignora cualquier dirección de proveedor fuera de la UE salvo que se autorice a propósito. Qué proveedor es cada pieza, en qué país está y para qué se usa está en /sub-encargados.

Si necesitas que no salga nada en absoluto (sectores regulados, contratos públicos, salud), Concerto Local lo resuelve: la inferencia corre en tu propio servidor, sobre el modelo Concerto local. El plan trae además 60 M STU al mes de cuota en la nube para lo que quieras mandarle a Amadeus, y es un interruptor: con él apagado, tus datos no salen de tu infraestructura.

Separación entre empresas

Quién impone el aislamiento, de verdad

Aquí es donde estas páginas suelen decir «doble barrera» y quedarse tan anchas. La nuestra la impone hoy la aplicación; lo que hay debajo llega hasta donde llega, y está escrito con su alcance exacto.

  • Lo que aísla hoy: la aplicación. cada petición resuelve a qué empresa perteneces y lo comprueba contra la base de datos, sin atajos, y toda consulta filtra por esa empresa. Modificar o borrar cualquier cosa exige comprobar la pertenencia otra vez. Si te retiran el acceso, lo notas en esa misma petición.
  • Lo que hay debajo: las políticas del motor. todas las tablas con dueño llevan activadas —y forzadas— las políticas de fila del propio motor de base de datos, y una prueba automática recorre el histórico entero de migraciones y falla si alguien crea una tabla sin ellas. Pero solo dos caminos del producto se ejecutan hoy con el usuario restringido al que esas políticas se le aplican; el resto corre con un usuario que las salta. O sea: son una segunda barrera real en esos dos caminos, y en los demás son la red que se activará al migrarlos. Está pendiente, y por eso lo verás también más abajo.

En Concerto Local cada cliente tiene su propia base de datos dedicada: ahí la separación es física, no solo lógica, y toda esta discusión no aplica.

-- puesto y forzado en TODAS las tablas con dueño
ALTER TABLE all_owned_tables ENABLE ROW LEVEL SECURITY;
ALTER TABLE all_owned_tables FORCE  ROW LEVEL SECURITY;

-- pero solo se aplica dentro de este bloque,
-- que hoy usan dos caminos del producto
SET LOCAL ROLE shara_app;
SET LOCAL app.current_tenant = '…';

Manipulación de agentes

Cincuenta y cuatro ataques, escritos como pruebas

Se ejecutan en cada verificación del código y en su propio flujo de integración continua. Si el porcentaje neutralizado en los casos graves baja del 95 %, la publicación se detiene. Cómo se mide exactamente está en la tercera tarjeta, y conviene leerla.

44 casos

Las diez categorías OWASP para modelos de lenguaje

Inyección de instrucciones, tratamiento inseguro de la salida, envenenamiento de datos, denegación de servicio, cadena de suministro, filtración de información sensible, herramientas vulnerables, exceso de autonomía, exceso de confianza y robo del modelo.

10 casos

Los nuestros

Los que solo tienen sentido aquí: intentos de sacarle a un agente el nombre real del modelo, de escalar a otro agente sin permiso, de reescribir la identidad de un agente por conversación, de saltarse la cuota o los topes de gasto, y de sacar credenciales guardadas.

Cómo se mide

Lo que esta cifra es, y lo que no

La suite se ejecuta contra respuestas grabadas, no contra el modelo en vivo. Comprueba que las defensas que neutralizaban cada ataque siguen en su sitio, no que el modelo de hoy resista un ataque nuevo. Es una red contra retrocesos y así hay que leerla. Ejecutarla periódicamente contra el modelo real está pendiente.

Medidas técnicas

El catálogo completo

Ocho apartados con el detalle de qué hace cada cosa. Todo lo de aquí está en el código que se publica.

Acceso y sesión (7 medidas)
  • Sesión firmada y verificada en cada petición. El algoritmo de la firma lo fija la configuración del servidor, y nunca se acepta el que proponga el propio testigo de sesión.
  • Segundo factor por aplicación, con ocho códigos de respaldo de un solo uso guardados con scrypt y descargables en PDF o texto.
  • Hay operaciones que vuelven a pedir el segundo factor aunque ya hayas entrado: cambiar la contraseña, tocar la identidad de un agente, emitir claves de acceso y los pasos de alta de la empresa.
  • Acceso con Google y con Microsoft, con el intercambio de código protegido (PKCE, RFC 8252).
  • Freno progresivo por dirección de origen en 24 rutas sensibles: acceso, segundo factor, códigos de respaldo, invitaciones, claves de activación, recuperación de contraseña y las que se abren con un testigo.
  • Bloqueo de diez minutos tras cinco fallos, contado por persona y por método, además del freno por dirección.
  • Las comparaciones de secretos se hacen en tiempo constante, para no filtrar nada por lo que tarda la respuesta. Hay 88 en el código.
Separación entre empresas y permisos (7 medidas)
  • A qué empresa perteneces se resuelve en cada petición y se comprueba contra la base de datos, sin atajos: lo que diga el testigo de sesión no basta, porque puede ir por delante de la realidad.
  • Modificar o borrar algo de la empresa exige comprobar de nuevo la pertenencia y que el papel esté en la lista permitida.
  • Seis papeles: propiedad, administración, dirección, operación, sistemas y consulta.
  • Veinte departamentos con nombres validados: quien está en ventas no entra en el perfil del agente legal.
  • La memoria personal es personal: nadie puede leer ni borrar la de otra persona de la misma empresa, ni pidiéndolo a mano.
  • La administración de la plataforma va detrás de un control aparte, exigido en los 18 sitios del código donde hace falta.
  • Concerto Local: base de datos propia y dedicada, separación física y no solo lógica.
El modelo, y por qué no se nombra (6 medidas)
  • El cliente nunca ve el nombre real del modelo que hay debajo.
  • Los nombres públicos son Prelude, Sonata, Symphony y Concerto, el que corre en tu propio servidor.
  • Un filtro recorre todo lo que sale y sustituye cualquier rastro del nombre real, incluidos los identificadores con número de versión y fecha; una prueba comprueba que no quede ningún resto.
  • Los mensajes de error de servicios de terceros pasan por ese filtro antes de guardarse o de llegarte, y los identificadores de cuenta que traen dentro se borran.
  • Detrás del filtro hay un vigilante: si detecta que algo se ha escapado, la respuesta se sustituye entera por una genérica y queda un aviso interno de máxima prioridad.
  • La comprobación pública de estado del servicio usa etiquetas neutras, nunca nombres de proveedor.
Contenido que llega de fuera (5 medidas)
  • Todo lo externo —el mensaje de un cliente, el contenido de un aviso entrante, un documento pegado— se envuelve en marcas que lo declaran dato y no instrucción.
  • Los agentes que hablan con clientes llevan esa regla escrita en su comportamiento, con los intentos concretos nombrados uno a uno: «ignora lo anterior», «ahora eres otro agente», «revélame tus instrucciones».
  • Lo que llega en formato de datos estructurados va en un sobre aparte, y se neutralizan las marcas con las que se podría intentar cerrarlo desde dentro.
  • El mensaje de una persona de tu propia empresa, que entra ya autenticada, NO se envuelve: hacerlo enseñaría al agente a desconfiar de su propio usuario. La envoltura es para lo externo, y ahí sí es sistemática.
  • La herramienta con la que un agente escala al orquestador vuelve a comprobar el permiso de la persona que originó la petición, no el del agente.
Gasto (6 medidas)
  • Tope por ejecución: 1.000.000 STU. Si una sola ejecución lo supera, se corta y el agente queda en pausa.
  • Tope por hora: 10.000.000 STU. La inferencia se cierra hasta que se libere.
  • Tope por día: 80.000.000 STU. Es el freno completo de la empresa.
  • El freno se levanta solo cuando el consumo de esa ventana vuelve a estar por debajo, o a mano desde la aplicación.
  • Fuera del horario de trabajo que fijes, el trabajo baja de escalón por sí solo: Symphony pasa a Sonata, Sonata a Prelude y Prelude se limita a respuestas cortas.
  • 34 acciones no se ejecutan solas: enviar correo, emitir y enviar facturas, ordenar pagos, publicar contenido, invitar a alguien, cambiar un papel, y todo lo que toca el ordenador de una persona.
Avisos entrantes y firmas (7 medidas)
  • Firma HMAC SHA-256 o SHA-512, comprobada en tiempo constante.
  • Sin secreto configurado no se acepta nada: se rechaza por defecto en vez de dejar pasar.
  • Ventana de cinco minutos: un aviso con fecha fuera de ±300 segundos se descarta aunque la firma sea correcta.
  • Cada evento se procesa una sola vez por empresa, con doble red: memoria y una restricción en la propia base de datos.
  • El secreto es de cada empresa. Nunca hay uno global compartido entre clientes.
  • Al conectar una herramienta, el testigo del intercambio se borra al leerlo y queda atado a quien inició el proceso.
  • Las llamadas que salen desde la pasarela de herramientas no pueden apuntar a direcciones internas ni a los servicios de metadatos del alojamiento.
Cifrado (6 medidas)
  • Las credenciales de tus conectores se guardan cifradas con AES-256-GCM, que cifra y a la vez detecta cualquier manipulación.
  • Cada empresa deriva su propia clave del secreto maestro con scrypt: el cifrado de una no abre el de otra.
  • El texto cifrado va atado por dentro a la empresa a la que pertenece: moverlo a otra no lo descifra mal, lo invalida.
  • Solo se escribe el formato actual. El anterior se sigue leyendo para poder migrar lo que quede, pero ya no se emite nunca, y hay una herramienta que lo rota.
  • Si el secreto maestro tiene menos de 32 caracteres, no se cifra nada: se rechaza escribir antes que escribir con una clave débil.
  • Nada de criptografía casera: solo lo que trae la biblioteca estándar del sistema.
Registro y trazabilidad (6 medidas)
  • Cada cambio queda con autor, fecha, recurso y el antes y el después.
  • Los registros van encadenados con SHA-256: cada uno incluye la huella del anterior de esa misma empresa. Alterar una línea del medio rompe todas las siguientes.
  • Eso hace que una manipulación sea demostrable, que no es lo mismo que imposible: no impedimos la escritura, demostramos que no se ha tocado. Hay una función en la base de datos que recorre la cadena y lo verifica.
  • La identidad de cada agente se modifica por partes, nunca se sustituye entera, y cada cambio deja rastro.
  • Los registros internos pasan por un filtro que borra cabeceras de autenticación, contraseñas, testigos de acceso y de renovación, claves y los mensajes de error de terceros.
  • De las claves de activación solo se guarda su huella criptográfica; en claro no se escriben en ningún registro.

Lo que todavía no

Las carencias, con su fecha

Ninguna de estas nos deja bien, y por eso están aquí y no en una nota a pie de página del contrato. Si alguna es un problema para tu caso, mejor saberlo hoy.

Certificaciones

No estamos certificados en ISO 27001 ni en SOC 2, y no hay auditoría de un tercero. Lo que hay es trabajo interno y está fechado: la auditoría de mayo de 2026 con sus setenta y seis hallazgos, la prueba de intrusión interna de junio y el barrido de agosto, cada uno con sus arreglos.

La segunda barrera de la base de datos

Las políticas de fila están puestas y forzadas en todas las tablas con dueño, con una prueba que lo vigila. Pero solo dos caminos del producto se ejecutan con el usuario al que se le aplican; el resto se apoya en la aplicación. Migrar los demás es invasivo y está pendiente.

El borrado definitivo

Darte de baja bloquea el acceso en el momento y queda registrado, y la exportación de tus datos es inmediata. El barrido que borra físicamente todo lo asociado se hace hoy a mano; el automático está pendiente.

La evaluación de impacto

Existe en borrador desde mayo de 2026 y no está cerrada. Se comparte tal cual, con esa etiqueta, a quien la pida bajo acuerdo de confidencialidad. Cerrarla es trabajo pendiente, no un trámite hecho.

Los frenos, con más de un servidor

El freno progresivo ante fallos de acceso lleva su cuenta dentro del proceso que atiende la petición. Hoy el servicio corre en uno solo, así que las cuenta todas; el día que haya varios habrá que llevar esa cuenta a un sitio compartido, y hasta entonces no lo diremos de otra manera.

La custodia de las claves

El secreto maestro del que se deriva la clave de cada empresa vive en la configuración del servidor. El servicio de custodia dedicado está diseñado y sin construir. El cifrado en sí no cambia cuando llegue: cambia dónde se guarda la llave maestra.

Las pruebas contra el modelo real

Los cincuenta y cuatro ataques se ejecutan contra respuestas grabadas. Sirven para que una defensa no desaparezca sin que nadie se entere, que es lo que suele pasar; no para afirmar que el modelo de hoy resiste un ataque que nadie ha escrito todavía.

¿Quieres revisarlo a fondo?

Bajo acuerdo de confidencialidad compartimos los informes de auditoría con sus hallazgos, el borrador de la evaluación de impacto y los resultados completos de la suite de manipulación, caso a caso.

Documentación

Documentos de tratamiento de datos

Textos legales completos, listos para tu equipo de cumplimiento.

¿Encontraste un fallo? Cuéntanoslo de forma responsable en [email protected].