{*}SecureCodeHQ
Security Whitepaper

Asi protegemos tus secretos

Transparencia total sobre como funciona nuestro cifrado, autenticacion, control de acceso e infraestructura. Aqui encontraras los detalles tecnicos de como SecureCodeHQ mantiene a salvo tus API keys, tokens y passwords.

Ultima actualizacion: Marzo 2026

Arquitectura General

Todos los secretos siguen el mismo camino seguro desde que se crean hasta que se consultan.

1

Crear Secreto

Desde el dashboard, importando .env (solo via web) o desde MCP/SDK (se cifra de inmediato)

2

Cifrar

AES-256-GCM con una clave unica (DEK), protegida por Google Cloud KMS

3

Almacenar

El texto cifrado y la clave envuelta se guardan en Firestore. El valor nunca queda en texto plano

4

Acceder

Autenticacion + verificacion de dispositivo + evaluacion de reglas + registro en audit log

Cifrado en Reposo

Utilizamos envelope encryption, el mismo estandar que usan AWS, Google Cloud y Azure. Cada secreto tiene su propia clave de cifrado, y esa clave esta protegida por Google Cloud KMS.

Como funciona el envelope encryption

Tu secreto: "sk_live_xxx"

→ Se cifra con una clave unica (DEK) usando AES-256-GCM

→ La DEK se envuelve con la clave maestra (KEK) en Google Cloud KMS

→ Se almacena: texto cifrado + DEK envuelta en Firestore (la KEK nunca sale de KMS)

Datos cifrados

  • Valores de los secretos (AES-256-GCM, clave unica por secreto)
  • API keys (hash SHA-256, jamas se almacenan en texto plano)
  • Todos los datos en transito (TLS 1.3)

Datos no cifrados (por diseno)

  • Nombres de secretos (necesarios para poder buscarlos)
  • Tags y descripciones (necesarios para filtrar y aplicar reglas MCP)
  • Registros de auditoria (necesarios para consultas y cumplimiento normativo)
Principio Fundamental

Acceso IA Zero-Knowledge

Nuestro principal diferenciador: cuando Claude Code utiliza tus secretos, el agente de IA nunca ve los valores reales. El secreto se inyecta en un archivo temporal que tu aplicacion lee. Nunca entra en la ventana de contexto del agente.

Flujo por defecto: modo inject

Claude Code solicita DATABASE_URL

→ El servidor MCP obtiene el valor cifrado desde la API

→ Lo escribe en ~/.securecode/.session/session.env

→ Responde: "Inyectado en /ruta. El valor NO esta en esta conversacion."

Modo Inject (Por Defecto)

Los secretos se escriben en un archivo temporal de sesion. El agente de IA solo recibe la ruta del archivo, nunca el valor. Tu aplicacion lee el archivo en tiempo de ejecucion.

Importacion Segura

Las importaciones masivas desde archivos .env siempre se realizan a traves del dashboard web. La herramienta MCP import-env redirige al navegador y nunca acepta contenido de secretos desde el agente.

SDK loadEnv()

En produccion, el SDK obtiene los secretos directamente de servidor a servidor (tu app hacia la API de SecureCode). Los valores van directo a process.env, sin ningun agente de IA de por medio.

Reveal Explicito (Auditado)

Si un agente necesita ver un valor (modo reveal), se trata de una accion explicita que queda registrada. El audit log guarda exactamente que agente accedio a que secreto en modo reveal.

Autenticacion en Dos Capas

Capa 1: API Key

Cada peticion al SDK o MCP incluye una API key (sc_xxx). Esta key identifica al usuario o equipo y determina los limites de su plan. Las keys se almacenan como hash SHA-256: nunca guardamos tu API key en texto plano.

Orden de busqueda: env var → .securecoderc → .mcp.json

Capa 2: Aprobacion de Dispositivo

Cada combinacion unica de agente + maquina + API key + IP se considera un "dispositivo". Los dispositivos nuevos quedan bloqueados por defecto y necesitan tu aprobacion explicita desde el dashboard para poder acceder a cualquier secreto.

Huella digital: usuario : hostname : agente : keyId : ip

Niveles de permiso por dispositivo

Solo Lectura

Puede listar y leer secretos. No puede crear, actualizar ni eliminar.

Lectura y Escritura

Puede listar, leer, crear y actualizar secretos. No puede eliminar.

Acceso Completo

Todas las operaciones, incluida la eliminacion. Usar solo en dispositivos de total confianza.

Politicas de Acceso (MCP Rules)

Reglas basadas en tags que se evaluan en el servidor antes de entregar cualquier secreto. Solo aplican al acceso via SDK, MCP o API. El acceso desde el dashboard nunca se restringe.

Bloquear Siempre

El secreto solo es accesible desde el dashboard. Cualquier acceso via SDK, MCP o API queda denegado.

Ejemplo: master passwords, credenciales de administrador

Requerir Sesion

El agente debe iniciar una sesion de forma explicita antes de poder acceder al secreto. Las sesiones tienen una duracion configurable (TTL).

Ejemplo: credenciales de base de datos en produccion

Bloquear Modelos

Restringe el acceso a modelos de IA concretos. El agente reporta su modelo mediante la cabecera X-AI-Model.

Ejemplo: permitir solo Claude, bloquear modelos no verificados

Requerir Confirmacion

El agente debe confirmar la regla antes de obtener acceso. La confirmacion caduca a los 5 minutos.

Ejemplo: API keys de alto valor (Stripe, AWS)

Notificar

Envia un email de notificacion cada vez que se accede al secreto. No bloquea el acceso, que se concede de inmediato.

Ejemplo: seguimiento de accesos en secretos compartidos del equipo

Las reglas se evaluan en orden de prioridad: block_always > require_session > block_models > require_confirmation > notify

Registro de Auditoria Completo

Cada acceso a un secreto queda registrado con todo su contexto. Siempre sabras exactamente quien accedio, a que, cuando, como y desde donde, incluyendo que modelo de IA se utilizo.

Ejemplo de registro de auditoria

{
"action": "read",
"secretName": "DATABASE_URL",
"source": "mcp",
"accessMode": "inject",
"agentName": "claude-code",
"machineUser": "juani",
"ipAddress": "84.125.***.**",
"timestamp": "2026-03-19T09:14:00Z"
}

Quien

Usuario + agente + maquina

Que

Secreto + accion realizada

Como

SDK / MCP / dashboard

Cuando

Fecha y hora exacta

Donde

Direccion IP + plataforma

Seguridad de las API Keys

Las API keys estan pensadas para rotarse de forma segura, sin tiempo de inactividad ni reinicios.

Hashing SHA-256

Las API keys se almacenan como hash, nunca en texto plano. Aunque nuestra base de datos se viera comprometida, tus API keys no podrian recuperarse.

Rotacion sin Cortes

Al rotar una key, la anterior sigue siendo valida durante 48 horas (periodo de gracia). Las aprobaciones de dispositivos se transfieren automaticamente a la nueva key. Cero tiempo de inactividad.

Reintento Automatico en 401

Cuando el SDK recibe un error 401, vuelve a leer la API key desde su origen. Si la has rotado, la aplicacion empieza a usar la nueva key sin necesidad de reiniciar.

Seguridad de la Extension para Chrome

La extension de SecureCodeHQ para Chrome sigue los mismos principios de seguridad que el SDK y el servidor MCP.

Sin Almacenamiento Local de Secretos

La extension nunca guarda valores de secretos en local. Genera valores en el navegador o los consulta a la API bajo demanda. Nada se persiste en chrome.storage.

Autenticacion via API

Todas las llamadas a la API se autentican con tokens de Firebase Auth. La extension incluye la cabecera X-Client: extension para identificar el origen en la auditoria.

Origen Identificado en Auditoria

Cada accion realizada desde la extension queda registrada con source: 'extension', para que puedas distinguirla del acceso via SDK, MCP o dashboard.

Guardado Solo con Expiracion (TTL)

Al guardar valores generados en el vault, la extension siempre exige un tiempo de vida (TTL). Los secretos creados desde la extension expiran automaticamente.

Infraestructura y Dependencias

Google Cloud KMS

La proteccion de claves (KEK) la gestiona Google Cloud KMS. La clave maestra nunca abandona la infraestructura HSM de Google. No implementamos criptografia propia.

Cloud Firestore

Los metadatos, el texto cifrado y los registros de auditoria se almacenan en Firestore, con reglas de seguridad que garantizan el aislamiento entre usuarios y equipos. Google se encarga de la replicacion y los backups.

Vercel Edge Network

El dashboard y las rutas de API se despliegan en la red edge de Vercel. Todo el trafico viaja por HTTPS con TLS 1.3. Incluye proteccion automatica contra DDoS y cache CDN para los assets estaticos.

SDK y MCP de Codigo Abierto

El SDK (@securecode/sdk) y el servidor MCP (@securecode/mcp-server) se publican en npm con licencia MIT. Puedes revisar cada linea del codigo que se ejecuta en tu maquina.

Somos honestos contigo

Creemos que la transparencia genera mas confianza que cualquier sello de marketing. Esto es lo que tenemos hoy y hacia donde vamos.

Todavia no tenemos SOC 2. Somos un producto nuevo. La certificacion SOC 2 Type II cuesta entre $30-50K al ano y requiere de 3 a 12 meses de observacion. La buscaremos cuando nuestra base de clientes lo justifique. Mientras tanto, esta pagina es nuestro compromiso con la transparencia.
Todavia no tenemos un pentest formal. Tenemos previsto encargar una auditoria de seguridad independiente cuando alcancemos ingresos que lo justifiquen. Publicaremos los resultados de forma publica.
No inventamos nuestra propia criptografia. Usamos AES-256-GCM a traves de Google Cloud KMS. El envoltorio de claves se realiza en los HSMs de Cloud KMS. Trabajamos con librerias probadas y auditadas, no con implementaciones propias.
Nuestro codigo del lado del cliente es open source. El SDK y el servidor MCP tienen licencia MIT en npm. Puedes auditar exactamente lo que se ejecuta en tu maquina. El codigo del servidor es propietario, pero sigue la arquitectura que describimos en esta pagina.
La seguridad es un proceso continuo. Construimos de forma publica. A medida que crezcamos, incorporaremos tests de penetracion, certificacion SOC 2 y auditorias externas. Esta pagina siempre reflejara nuestro estado real, no aspiraciones.

¿Tienes preguntas sobre nuestra seguridad?

Consulta la documentacion, revisa el codigo fuente o escribenos directamente. Estaremos encantados de hablar sobre nuestro modelo de seguridad en detalle.