Seguridad

La revisión de seguridad más corta
que jamás realizará.

La mayoría de las revisiones de proveedores de IA giran en torno a qué ocurre con sus datos del lado del proveedor. Hedy Self-hosted termina esa conversación: no existe un «lado nuestro». Hedy Managed la reduce a exactamente una vía — el tráfico de modelos a través de nuestra pasarela — y la tabla de abajo dice con precisión qué significa eso. Cada control vive en código, y sus auditores pueden leerlo.

Dos modos de modelo, declarados sin rodeos

Hedy funciona en uno de dos modos de modelo, y varias afirmaciones de esta página dependen de cuál elija. Self-hosted / BYO es el modo insignia: todo el stack se ejecuta en su infraestructura, con sus propias claves de modelo o modelos locales. Managed existe por la rapidez sin configuración — y cambia los hechos de residencia de datos, así que los declaramos por modo en lugar de en letra pequeña.

Self-hosted / BYOManaged
Llamadas a modelosSus claves, directo a su proveedor — o vLLM / Ollama locales sin llamadas externasEnrutadas a través de la pasarela de modelos de Hedy hacia el proveedor de modelos
Subencargados (sub-processors)NingunoHedy (pasarela) y el proveedor de modelos subyacente — solo para el tráfico de modelos
Qué almacena el lado de HedyNada — no existe un lado de HedyMetadatos de medición (recuentos de tokens, costo, nombre del modelo, latencia) y su registro de créditos. Nunca el contenido de prompts o respuestas.
Base de conocimiento, memoria, registros de auditoríaSu PostgreSQL, en sus máquinasSu PostgreSQL, en sus máquinas — sin cambios
Air-gapSoportado, con modelos localesNo disponible — la pasarela necesita una ruta de red

Arquitectura

S-01

Single-tenant, su perímetro

Hedy se despliega como contenedores en su VPC vía Docker Compose o Helm — o totalmente air-gapped (aislado de red) con modelos locales. No hay nube multi-tenant ni base de datos compartida. En modo Self-hosted / BYO no hay backend operado por Hedy en absoluto; en modo Managed el único componente operado por Hedy es la pasarela de modelos descrita arriba.

S-01

Subencargados: depende de su modo

Self-hosted / BYO: ninguno — la lista está vacía porque no hay lista. Sus datos los procesan sus máquinas bajo sus acuerdos existentes, y las llamadas a modelos van a los proveedores que usted elige con sus claves, o a modelos locales sin ninguna llamada externa. Managed: dos, solo para el tráfico de modelos — la pasarela de Hedy y el proveedor de modelos detrás de ella. La pasarela registra metadatos de medición y su registro de créditos; nunca almacena contenido de prompts ni de respuestas.

S-01

Postura de red

Los servicios de aplicación se enlazan a loopback por defecto; solo su proxy inverso queda expuesto. Las imágenes tienen la versión fijada (semver, nunca latest).

Tratamiento de datos

S-02

Todo permanece local

La base de conocimiento, los embeddings, la memoria de conversación y los registros de auditoría viven en su PostgreSQL en ambos modos. Los backups son sus scripts escribiendo en su almacenamiento. En modo Self-hosted / BYO la medición de tokens también vive ahí; en modo Managed la pasarela guarda además un registro de medición — recuentos de tokens, costo, nombre del modelo, latencia — para facturar créditos. Ese registro no contiene contenido.

S-02

Los secrets solo van por entorno

Las credenciales entran mediante inyección de entorno en el despliegue, y punto. El repositorio incluye un archivo de ejemplo; el agente tiene como regla dura no almacenar nunca valores de credenciales en memoria, archivos ni logs.

S-02

Sin entrenamiento con sus datos

En modo Self-hosted / BYO nosotros no recopilamos nada, así que nada puede usarse para entrenar; si usted usa APIs de modelos externas, rige su propio acuerdo con el proveedor — y el modo air-gapped elimina incluso eso. En modo Managed la pasarela no almacena contenido de prompts ni de respuestas, así que no hay nada suyo en nuestro lado con lo que entrenar. El tráfico de modelos se enruta únicamente a proveedores cuyos términos comerciales de API excluyen por defecto el entrenamiento con entradas y salidas (los Términos Comerciales de Anthropic lo declaran textualmente; DPA del proveedor disponible bajo petición) — nunca a través de pasarelas de retransmisión opacas, y nunca a proveedores que entrenan con datos de API.

Control de acceso

S-03

Sin endpoints anónimos

Cada API — incluida la interna de servicio a servicio — requiere autenticación. El acceso a la consola es por roles (admin / aprobador / miembro).

S-03

ACLs de conocimiento, aplicadas en el servidor

La recuperación se filtra por las etiquetas de autorización de quien pregunta antes del ranking. Los documentos excluidos no se resumen, no se insinúan ni se cuentan en las respuestas.

S-03

Perfiles de egreso

Los empleados de cara al exterior están limitados en firme a la capa de conocimiento público y despojados de las herramientas de datos internos — aplicado en código, verificado en pruebas.

S-03

Acceso de solo lectura a la base de datos

Las consultas de datos del agente usan un rol de solo lectura a nivel de base de datos — no un flag de sesión que se pueda conmutar.

Gobernanza de acciones

S-04

Autonomía por niveles

Cada clase de acción sensible lleva un nivel almacenado en la base de datos: L0 automática, L1 requiere aprobación humana, L2 prohibida. Los prompts no pueden cambiar los niveles.

S-04

Listas de permitidos para escritura, denegación por defecto

Las escrituras en repositorios requieren proyectos listados explícitamente. El código sale como PRs en borrador; el merge está reservado a humanos.

S-04

Destinos de entrega explícitos

Las tareas programadas deben nombrar su destino. «Enviar a quien preguntó por última vez» es estructuralmente imposible.

Auditabilidad

S-05

Registro append-only

Cada acción se registra con actor, objeto y razonamiento. El esquema no tiene vía de actualización ni de borrado — ni para el agente ni para los administradores.

S-05

Vistas de cumplimiento

Las estadísticas de operaciones de escritura agregan qué hizo el empleado y dónde, de modo que «¿qué ha estado haciendo?» es un panel, no una investigación.

Riesgo específico de IA

S-06

Pruebas de conducta de línea roja

Las puertas de release incluyen sondeos adversariales: preguntas de salario desde solicitantes sin privilegios, solicitudes de credenciales, prompts de estilo inyección. Una fuga es un release fallido, no una nota al pie.

S-06

Respuestas con puerta de evidencia

Las respuestas de conocimiento deben citar textualmente su pasaje fuente; una comprobación automática verifica que la cita existe. Los jueces que alucinan quedan invalidados.

S-06

Sin degradación silenciosa de modelos

Las llamadas relevantes para la seguridad nunca recurren a modelos más débiles bajo presión de cuota — en su lugar, rechazan. Los modelos más débiles son más fáciles de inyectar.

S-06

Disciplina con contenido no confiable

Las páginas web descargadas, los correos y los documentos son datos, nunca instrucciones. El runtime trata los comandos incrustados como contenido que reportar, no como órdenes que seguir.

Integridad y divulgación

S-07

Licencias firmadas

Las licencias están firmadas con Ed25519 y se validan offline. Sin llamadas a casa a un servidor de licencias.

S-07

Divulgación responsable

¿Encontró algo? security@hedy.one. Respondemos rápido y damos crédito a los investigadores. Somos un producto joven: publicamos controles en lugar de insignias, y sus auditores pueden leer el código.

hedy.one

Traiga a su equipo de seguridad.
Nos gustan las preguntas difíciles.

Reserve una llamada de revisión de seguridad