Seguridad de los datos en Archyl Cloud: qué protegemos, cómo, y qué no afirmamos

En algún lugar de tu cuestionario de proveedores hay una fila que dice «¿Se cifran en reposo los datos del cliente? Sí / No». Para Archyl Cloud, la respuesta exacta es «sí, y estos son exactamente los campos». El texto de tu arquitectura (nombres, descripciones, ADR, documentación) y tus credenciales los cifra nuestra aplicación antes de que la base de datos llegue a verlos. Los archivos subidos los cifra el proveedor de almacenamiento. Los identificadores, las marcas de tiempo, las posiciones en los diagramas y los correos electrónicos de las cuentas quedan en claro, porque la base de datos tiene que indexarlos y hacer joins con ellos. Un proveedor que marca «Sí» sin decir qué es qué te está pidiendo que te creas el resto del cuestionario a ciegas.

Este artículo es la respuesta larga. Cubre qué ciframos y cómo, cómo se mueven los datos, quién puede acceder a qué, qué recibe nuestro proveedor de IA, cómo hacemos pruebas y qué puedes hacer en virtud del RGPD. También dice con claridad dónde todavía no estamos: Archyl no tiene hoy ninguna certificación de seguridad.

Todo lo que aparece aquí es coherente con el Security Whitepaper (v3.0) y el Acuerdo de Tratamiento de Datos (DPA), ambos actualizados el 27 de septiembre de 2026 y ambos enlazados desde el Centro de confianza. Si alguna vez una frase de aquí y una de allí no coinciden, avísanos, porque una de las dos está mal.

La versión corta

Para quien esté rellenando un formulario ahora mismo:

El resto del artículo es el detalle que hay detrás de cada fila.

Cifrado en reposo, campo a campo

Archyl cifra los campos en la aplicación, antes de que se escriban en la base de datos. Cada modelo que contiene contenido de clientes lleva un hook de guardado que cifra sus campos de texto con AES-256-GCM a la entrada, y un hook correspondiente que los descifra a la salida. Cada cifrado usa un nonce aleatorio nuevo, así que el mismo valor almacenado dos veces produce dos textos cifrados distintos.

Eso abarca tu contenido de arquitectura, no solo tus secretos:

• Modelo C4: systems, containers, components y elementos de código (nombre, descripción, tags); relaciones (descripción, tags)
• Architecture Decision Records: título, contexto, decisión, consecuencias, tags
• Documentación: título, contenido, ruta de archivo, tags; los comentarios sobre ella
• Contratos de API: nombre, descripción, contenido, endpoint, versión
• Flows y whiteboards: nombres, descripciones, etiquetas de tecnología
• Además: overlays, canales de eventos, insights, releases, reglas de conformidad, historial de cambios y snapshots

Y todas las credenciales y secretos que Archyl almacena:

• Tokens OAuth de GitHub, GitLab y Bitbucket
• Claves de API
• Secretos de MFA y códigos de recuperación
• Credenciales de integraciones y del marketplace
• Tokens de acceso a repositorios
• Configuración de conexiones a la nube

Esto está siempre activo. La clave de cifrado se deriva con Argon2id a partir de un secreto configurado, y el servidor se detiene al arrancar si ese secreto falta o tiene menos de 32 caracteres. No existe ninguna configuración en la que Archyl se ejecute y escriba estos campos en texto plano.

La consecuencia práctica: una copia de la base de datos, por sí sola, muestra la forma de tus datos pero no sus palabras. Los nombres de tus servicios, el razonamiento de tus ADR, el cuerpo de tus docs, tu token de GitHub y tu secreto de MFA necesitan además la clave.

Las credenciales tampoco vuelven a salir nunca por la API. La configuración de las integraciones se oculta en cada lectura, así que, una vez que pegas una clave en Archyl, la interfaz puede decirte que hay una clave almacenada, pero no puede volver a mostrártela, y ninguna llamada a la API se la devuelve a nadie más de tu organización.

Lo que esto no cubre

Una base de datos tiene que poder encontrar, ordenar y hacer joins de filas, y no puede hacerlo sobre texto cifrado. Por eso algunos campos quedan en claro:

• Los identificadores y los vínculos entre elementos. La base de datos sabe que el elemento A pertenece al container B y tiene una relación con el elemento C. No sabe cómo se llama ninguno de ellos.
• Las marcas de tiempo y las posiciones en los diagramas.
• Las direcciones de correo electrónico, los nombres y los apellidos de las cuentas. El correo electrónico tiene un índice único, de modo que dos cuentas no pueden reclamar la misma dirección.

Estos campos están protegidos por los controles de acceso que se describen más abajo y por TLS en tránsito. Este artículo no afirma nada, ni en un sentido ni en otro, sobre el cifrado a nivel de disco de la base de datos.

Archivos subidos

Los archivos que adjuntas a la documentación (imágenes, PDF, otros documentos) no residen en la base de datos. Se almacenan en Google Cloud Storage, y:

• Los buckets son privados. Nada de lo que contienen se puede leer ni listar públicamente.
• Los archivos se cifran en reposo con AES-256 por parte de Google Cloud Storage, con claves gestionadas por el proveedor.
• Los archivos solo se sirven mediante URL firmadas de corta duración. Cada enlace da acceso a un único archivo y caduca poco después de generarse, así que un enlace copiado en un ticket o en un chat deja de funcionar en lugar de convertirse en una URL pública permanente.
• La región por defecto es la UE: Bélgica, europe-west1.

Cifrado en tránsito

El tráfico entre tu navegador, tus herramientas y Archyl Cloud usa TLS 1.3. La conexión de la aplicación con su base de datos PostgreSQL exige SSL, por lo que la aplicación no se comunica con la base de datos en texto plano.

Quién puede entrar

Personas

• La autenticación multifactor usa TOTP, los códigos de seis dígitos de una app de autenticación. Cada desafío MFA solo puede usarse una vez, y los códigos de recuperación se almacenan como hashes bcrypt, de modo que pueden comprobarse pero no leerse de vuelta.
• El single sign-on admite SAML 2.0 y OpenID Connect. El inicio de sesión siempre empieza en Archyl (solo SP-initiated), y el state que vincula la respuesta de tu proveedor de identidad con esa petición está ligado al navegador que la inició y solo es válido una vez. Nuestro artículo sobre SSO explica la configuración.
• El inicio de sesión con OAuth está disponible con GitHub, GitLab y Bitbucket.
• Cambiar la contraseña o quitar la MFA revoca todas las sesiones anteriores. Si crees que una contraseña se ha filtrado, cambiarla cierra la sesión en todos los demás dispositivos que la estaban usando.
• El restablecimiento de contraseña no revela si una cuenta existe, y un enlace de restablecimiento deja de funcionar una vez usado.
• El inicio de sesión, la MFA y el restablecimiento de contraseña tienen rate limiting, con límites en capas para que una misma IP, una misma cuenta o un mismo desafío solo puedan intentarse un número limitado de veces.

Máquinas: claves de API y agentes de IA

• Las claves de API son de solo lectura por defecto. El acceso de escritura tiene que concederse, y una clave puede restringirse a proyectos concretos, así que una clave entregada a un job de CI que solo lee el modelo de un proyecto puede hacer exactamente eso.
• El servidor MCP, que los agentes de IA usan para leer y actualizar tu arquitectura, se autentica con OAuth y PKCE obligatorio. Cada mutación requiere un scope de escritura, así que un agente que conectaste para responder preguntas sobre tu arquitectura no puede modificarla a menos que le hayas concedido acceso de escritura.

Aislamiento entre tenants

El fallo contra el que todo producto multi-tenant tiene que diseñarse es fácil de describir: el servidor comprueba que has iniciado sesión y perteneces a alguna organización, y después se fía de cualquier identificador que venga en la petición. Cambias el ID en la URL y estás leyendo los datos de otra persona.

Archyl autoriza cada petición contra el recurso al que accede. Pedir un diagrama, un documento o una clave implica comprobar que el proyecto o la organización propietaria de ese recurso concreto es uno al que tienes acceso, no solo que has iniciado sesión. La misma regla se aplica en la API HTTP y en el servidor MCP.

Dos propiedades hacen que esto se mantenga con el tiempo:

• La autorización falla en cerrado (fail closed). Si no se puede determinar a quién pertenece un recurso, la respuesta es no.
• Hay tests automatizados de tenancy que se ejecutan en CI y hacen fallar el build si se elimina una comprobación de autorización, en lugar de esperar a que alguien se dé cuenta.

Lo que ve la IA

Las funciones de IA de Archyl Cloud usan OpenAI, y ningún otro proveedor de IA, a menos que tu organización configure su propia clave.

Para el descubrimiento de arquitectura, que lee un repositorio y propone un modelo C4, enviamos firmas de código en lugar de código fuente. Este es un archivo tal como está en tu repositorio:

package billing

import (
	"context"
	"github.com/stripe/stripe-go/v82"
)

type InvoiceService struct {
	Repo InvoiceRepository
}

func (s *InvoiceService) Finalize(ctx context.Context, id string) error {
	inv, err := s.Repo.Get(ctx, id)
	if err != nil {
		return err
	}
	if inv.Total > approvalThreshold {
		return ErrNeedsApproval
	}
	return s.Repo.MarkFinal(ctx, id)
}

Y esta es la sección que el descubrimiento construye a partir de él, que es lo que entra en el prompt:

--- internal/billing/service.go [go] ---
Imports: context, github.com/stripe/stripe-go/v82
Types: struct InvoiceService,   InvoiceService.Repo InvoiceRepository
Functions: func (s *InvoiceService) Finalize(ctx context.Context, id string) error

La regla de aprobación, el umbral y el cuerpo de Finalize se quedan fuera. Lo que sí entra: el nombre del repositorio, la estructura de archivos y directorios, y estas firmas (imports, declaraciones de tipos y funciones, constantes exportadas). Eso basta para deducir que un component de facturación se comunica con Stripe. Aun así, no es irrelevante: los nombres de funciones y tipos describen tu sistema, así que trátalos como datos que estás compartiendo.

Dos límites a esa afirmación, para que no leas en ella más de lo que dice:

• Describe cómo trata el descubrimiento el código fuente. Si el descubrimiento encuentra en el repositorio Architecture Decision Records escritos en Markdown, envía su texto para poder convertirlos en decisiones estructuradas, y envía las primeras líneas de los archivos de documentación para darles título.
• Otras funciones de IA envían lo que su tarea necesita. Un agente de código, por ejemplo, trabaja sobre los archivos que está modificando, así que los ve.

Si tu política dice que el código solo puede ir a un proveedor con el que tengas un contrato, las organizaciones pueden traer su propia clave de IA. Las peticiones de IA van entonces a ese proveedor, bajo tu contrato. Si no puede salir absolutamente nada de tu red, un Archyl autoalojado puede ejecutar modelos con Ollama en tu propio hardware.

Cómo lo probamos

En el pipeline

Nuestro pipeline de CI ejecuta cuatro escáneres de seguridad:

• govulncheck para vulnerabilidades conocidas en las dependencias de Go que realmente llamamos
• CodeQL para el análisis estático de nuestro propio código
• gitleaks para secretos commiteados por error
• Trivy para vulnerabilidades en imágenes de containers y en la configuración de infraestructura

En la plataforma

• Las peticiones salientes se comprueban. Cada integración que llama a una URL que tú proporcionas (un servidor Git autoalojado, un webhook, un endpoint de IA) está protegida contra server-side request forgery, de modo que esa URL no puede usarse para hacer que Archyl alcance su propia red interna.
• El navegador solo ejecuta los scripts que publicamos. Una Content-Security-Policy estricta enumera cada script inline por su hash, y los scripts cargados desde un CDN llevan hashes de Subresource Integrity, así que una copia modificada se rechaza.
• Los containers están blindados. Se ejecutan con un usuario no root, sobre un sistema de archivos de solo lectura y sin las capabilities de Linux.
• Los eventos de seguridad se registran, incluidos los inicios de sesión fallidos, los intentos de MFA fallidos y los tokens rechazados.

Pruebas de penetración

Entre julio y septiembre de 2026 realizamos diez rondas de pruebas de penetración internas. Cada hallazgo se corrigió y se cubrió con un test de regresión, de modo que el mismo problema se detecte si vuelve a aparecer.

«Internas» significa exactamente eso: hicimos estas pruebas nosotros mismos y no intervino ninguna empresa independiente. Hay prevista una prueba de penetración independiente como parte de la auditoría SOC 2.

Tus derechos en virtud del RGPD

• Exportación. Puedes exportar tus datos en JSON.
• Eliminación. Eliminar tu cuenta elimina todo lo que le pertenece, en cascada por tus datos e incluidos los adjuntos subidos al almacenamiento de objetos.
• Un DPA para cada cliente. El Acuerdo de Tratamiento de Datos está disponible para todos los clientes.
• Notificación de brechas en un plazo de 72 horas.
• 30 días de preaviso antes de cualquier cambio en nuestros subencargados del tratamiento, para que puedas oponerte antes de que el cambio se produzca.

Estos son los subencargados actuales:

El DPA indica la ubicación y las garantías legales de cada uno.

Lo que todavía no afirmamos

Una página de seguridad que solo enumera puntos fuertes te deja a ti la tarea de encontrar las carencias. Aquí están:

• Ninguna certificación. Archyl no tiene la certificación SOC 2 ni la certificación ISO 27001. Para SOC 2 Type I, la evaluación de preparación (readiness assessment) está completada y la auditoría independiente está pendiente. ISO 27001 está prevista. Cuando exista un informe de auditoría, el Centro de confianza lo dirá; hasta entonces, nada de lo que publiquemos debería dar a entender lo contrario.
• Todavía no hay prueba de penetración independiente. Las diez rondas descritas arriba fueron internas. La prueba independiente llega con la auditoría SOC 2.
• No todas las columnas están cifradas. Los identificadores, las marcas de tiempo, las posiciones en los diagramas, los correos electrónicos y los nombres quedan en claro, como se describe arriba.

Si tu proceso exige una certificación que Archyl todavía no tiene, es una restricción real, y preferimos que lo sepas ahora y no en la sexta semana de una revisión de compras.

Adónde ir ahora

• El Centro de confianza reúne los documentos en un solo lugar.
• El Security Whitepaper profundiza en cada control, incluidos los rate limits y los eventos de seguridad que registramos.
• El Acuerdo de Tratamiento de Datos es la versión contractual de la sección sobre el RGPD de arriba.
• Para preguntas sobre protección de datos, o puntos del cuestionario que este artículo no responde, escribe a privacy@archyl.com.
• Para informar de una vulnerabilidad, escribe a security@archyl.com. Acusamos recibo en 24 horas.

Si eres la persona que tiene que dar el visto bueno a Archyl, preferimos que encuentres una respuesta precisa a cada pregunta antes que una respuesta segura a la mayoría. Donde algo de aquí no sea lo bastante preciso para tu revisión, pregunta, y lo haremos preciso.