Cómo está hecho Kirky para integrarlo con seguridad

La etiqueta del script lleva un identificador público del espacio de trabajo. Se puede publicar y por sí solo no prueba nada.

Tu backend, detrás de tu propio login, firma quién es el usuario: un token ES256 con el ID del usuario, sus roles, su idioma y la audiencia, válido cinco minutos como máximo. Verificamos la firma con la llave que registraste, la audiencia, la expiración y el origen de la página contra tu lista de orígenes permitidos.

Solo entonces emitimos nuestro propio token de sesión: de vida corta, ligado a ese origen y firmado con una llave resguardada en un servicio de llaves respaldado por hardware. Todas las APIs de Kirky aceptan únicamente ese token de sesión. El espacio de trabajo se deduce de la llave que verificó tu token, nunca de un dato dentro de él.

Los roles vienen de tu token y se detectan solos. Un rol que no habíamos visto empieza sin permisos hasta que tu administrador se los da en el portal.

Cada sesión recibe un manifiesto con las herramientas, documentos y endpoints que su rol puede usar. El servidor rechaza cualquier solicitud fuera de ese manifiesto, pida lo que pida el modelo.

En Starter, Business y Scale los espacios de trabajo comparten infraestructura y están separados en cada capa: cada dato guardado lleva la llave de su espacio de trabajo, las funciones que atienden una solicitud solo pueden llegar a las llaves y prefijos de almacenamiento de ese espacio, y cada espacio tiene su propio índice de búsqueda.

Antes de cada despliegue corre una batería de pruebas de aislamiento entre espacios de trabajo, y si falla, el despliegue se bloquea. Enterprise puede correr en un despliegue dedicado.

Para datos en vivo, el modelo pide una llamada a herramienta y el widget la ejecuta en el navegador del usuario contra tus endpoints de lectura, con la sesión que ese usuario ya tiene. Tus credenciales de API nunca nos llegan.

Cada llamada lleva un identificador firmado de un solo uso. El widget vuelve a validar la ruta antes de llamarla y rechaza separadores codificados, rutas hacia directorios superiores y URLs absolutas. El resultado regresa con un tamaño máximo, reducido a los campos que eligió tu administrador y tratado como entrada no confiable.

El acceso directo a la base de datos es opcional. El conector es un contenedor de código abierto que corres en tu red. Se conecta hacia nosotros por un WebSocket cifrado; nunca abrimos un puerto hacia tu red.

No arranca si su rol de base de datos puede hacer algo más que leer, ejecuta cada consulta dentro de una transacción de solo lectura con límite de tiempo y de costo, y firma sus resultados.

No guardamos tus llaves de API. Las que sí guardamos, como las llaves públicas que verifican tus tokens y el secreto de cada conector, se almacenan cifradas y limitadas a tu espacio de trabajo. Las llaves de firma nunca salen del servicio de llaves.

Todo el tráfico usa TLS. Los datos en reposo se cifran con llaves cuyo uso está ligado a tu espacio de trabajo; un plan de pago puede pasar a una llave dedicada, y Enterprise puede traer la suya.

Cada pregunta pasa primero por una revisión de tema, y hay filtros de contenido en la entrada y en los campos de texto libre que regresan las herramientas. Las respuestas de documentos corren en modo estricto, con cada cita verificada palabra por palabra contra su fuente, en código.

Para evitar que los datos salgan por una respuesta, la salida se depura: sin enlaces, sin imágenes y sin marcado activo, y Kirky no tiene acceso a la web. El proveedor de modelos está configurado para no retener solicitudes, y tus datos no entrenan modelos.

Las solicitudes tienen límites por espacio de trabajo y por usuario, con un tope diario por usuario. La actividad sospechosa se marca como evento de seguridad para tu administrador; bloqueamos la solicitud, y una persona decide si suspender a alguien.

Los inicios de sesión, preguntas, llamadas a herramientas, acciones, cambios de configuración y sesiones de soporte quedan en un registro de auditoría que tu administrador puede revisar y exportar. Los registros se escriben una vez y no se editan.

Nuestro personal solo puede actuar dentro de tu espacio de trabajo con una sesión de soporte limitada en tiempo, con inicio de sesión de varios factores y visible en tu registro de auditoría.

Hay alertas automáticas que vigilan los eventos de seguridad. Si un incidente afecta tus datos, avisamos al propietario de tu espacio de trabajo sin demora indebida, con qué pasó, qué datos estuvieron involucrados y qué estamos haciendo, y te mantenemos al tanto hasta cerrarlo. El Acuerdo de Tratamiento de Datos establece estas obligaciones.