Seguridad

Conectar el SII o un banco significa entregarle a Emisso una credencial real, y evaluar eso exige respuestas concretas: dónde queda la clave, quién puede leerla, qué pasa si algo se compromete. Esta página responde en ese orden. Cada afirmación describe comportamiento del sistema, no intención.

Preguntas frecuentes

¿Cómo funciona?

Emisso se conecta a los portales de forma automatizada, con la clave que tú entregas. Trae tus datos, los guarda y desde ahí los consultas por la API, por MCP o desde el panel.

¿Es seguro entregar la clave?

• La clave se escribe una sola vez, en una página de connect.emisso.ai, no en tu aplicación ni en la de quien integra.
• Queda cifrada con AES-256 bajo una llave propia de tu organización. Solo se descifra en el servidor en el momento de usarla.
• Nadie la ve: ni el equipo de Emisso en el panel, ni quien integra, ni un asistente de IA. Tampoco aparece en respuestas ni en registros.
• Puedes revocar el acceso cuando quieras, desde el panel y al instante.
• Cada consulta queda registrada en una bitácora que no se puede modificar: quién pidió qué, cuándo y con qué resultado.

¿Tienen certificaciones de seguridad?

Nuestra tecnología y nuestros procesos están alineados con SOC 2 e ISO 27001, y proyectamos certificarnos durante 2027. Hoy todavía no tenemos esas certificaciones.

¿Qué pasa si el banco o el SII cambian su sitio, o rechazan el acceso?

• Si el portal cambia, el equipo de Emisso ajusta la conexión. Mientras tanto, los datos que ya se guardaron siguen disponibles.
• Si la clave deja de funcionar, por ejemplo porque se cambió o el banco la bloqueó, la conexión se pausa para no insistir, y lo ves en el panel. La reconectas con un enlace, sin perder lo guardado.
• Ninguna institución garantiza que su sitio no cambie, así que no prometemos plazos. Sí te avisamos y lo resolvemos lo antes posible.

El resto de esta página explica cada punto en detalle.

La credencial nunca te toca

El diseño parte por sacar la credencial de tu camino. Con el enlace hosted, la persona que tiene la clave la escribe en una página de connect.emisso.ai, nunca en tu aplicación: tu producto emite el enlace y recibe el resultado (connection_id, estado), pero la clave no pasa por tu frontend ni por tu backend, y el contexto de tu agente tampoco la ve.

Del lado de Emisso, la credencial se cifra para la organización dueña de la conexión y queda en el vault. En tiempo de llamada se resuelve del lado del servidor, en el momento exacto en que un conector la necesita para consultar la fuente. De ahí no sale: no entra al contexto de un LLM ni aparece en un tool result, y ningún log la registra cruda. La misma regla cubre el material derivado de la credencial, como las sesiones de portal que algunos bancos exigen: se resuelven server-side y jamás viajan en una respuesta.

Cifrado

El modelo es envelope encryption por organización. Cada organización tiene su propia clave de datos (DEK); las credenciales se cifran con AES-256-GCM bajo esa DEK, y la DEK se guarda a su vez envuelta por una clave maestra (KEK) que no vive en la base de datos, sino en un vault administrado. El material cifrado lleva versión de clave, la costura que permite rotar sin re-cifrar a ciegas.

Hay una sola implementación de cifrado para todo el sistema: los campos sensibles del plano persistido y los secretos de webhook se sellan con el mismo tronco (la misma DEK por organización, el mismo sellado autenticado). Un secreto de webhook, igual que una credencial, solo se muestra al crearse o rotarse; ninguna lectura posterior lo devuelve.

Aislamiento multitenant

Toda fila de datos de negocio lleva su organization_id, y sobre eso corren dos guardias independientes:

1. La aplicación filtra siempre por organización. Es la guardia primaria: cada consulta lleva el filtro explícito.
2. La base impone Row Level Security como respaldo, con default deny. El contexto de organización se fija por transacción; si no se fijó, la política no calza con ninguna fila y la consulta devuelve cero resultados. Un filtro olvidado en el código degrada a «no ves nada», no a una fuga.

El runtime se conecta con un rol propio, sin privilegio de saltarse RLS y sin permiso de DELETE sobre las tablas; los roles administrativos con bypass no participan del camino de ejecución. En el dominio del SII y los bancos, el diseño trata una fuga entre organizaciones como un riesgo existencial; por eso las guardias son dos.

Redacción y auditoría

Toda llamada a una tool deja exactamente una fila en la bitácora, con actor, conexión, resultado y latencia. Del input, la fila guarda solo un input_digest: el hash SHA-256 del input ya redactado, donde los campos con forma de secreto (token, password, credential y similares) se reemplazan antes de calcular el hash. El input crudo no se almacena.

La bitácora es append-only: no existe camino de UPDATE ni de DELETE sobre ella, ni siquiera para los roles del sistema. Los fallos de autenticación ocurren antes de conocer la organización, así que van a un registro de eventos de seguridad separado, nunca a la bitácora de un tenant. Y los webhooks siguen la misma disciplina de redacción: sus payloads se limitan a códigos del catálogo y conteos.

Aplicaciones con consentimiento de Google (Gmail)

Gmail no entrega una clave: la persona autoriza en Google, y el token lo custodia Composio, un subencargado de Emisso. Emisso no recibe ni guarda ese token. Guarda una referencia a la cuenta autorizada, la dirección del buzón, los permisos concedidos y la constancia del consentimiento: versión del aviso, destinatario y fecha.

Emisso no guarda correos. Cada llamada consulta Gmail en vivo. La bitácora registra el input_digest, no el contenido. Un envío guarda solo los ids del correo enviado, cifrados con la clave de la organización. Un adjunto se transmite cuando abres su enlace de cinco minutos, sin pasar por disco. El custodio sí conserva registros: por defecto, Composio guarda los argumentos y las respuestas de cada ejecución hasta un año, y los adjuntos preparados 24 horas.

En la beta, Google pide para Composio acceso total a Gmail, porque es el único permiso de Gmail que ofrece su aplicación. Emisso expone cuatro operaciones (buscar, leer, descargar un adjunto y enviar), y ninguna borra ni modifica correos. Los permisos gmail:readonly y gmail:send no entran en el acceso total de una clave: hay que nombrarlos.

Para quitar el acceso, elimina la conexión: Emisso la cierra y pide a Composio que borre la cuenta. Con la aplicación de Composio, el consentimiento en Google se retira desde la cuenta de Google de la persona.

Revocación

Cuando algo se compromete, lo que importa es cuánto tarda en dejar de funcionar:

• Una API key se revoca al instante desde el dashboard y deja de autenticar en la siguiente petición. Es el freno de emergencia: a propósito, cualquier miembro de la organización puede accionarlo, sin esperar a un admin.
• El acceso de un agente MCP se revoca desde Agentes y deja de autenticar en la siguiente petición: la revocación cierra todas las sesiones que esa persona abrió con ese cliente, incluido el refresh token, así que el agente no puede volver solo. Como con una API key, cualquier miembro de la organización puede accionarlo.
• Un enlace de conexión se revoca desde el dashboard; desde ese momento responde el mismo 404 que cualquier enlace inválido.
• Una conexión se deshabilita completa: sus tools dejan de resolver (connection_disabled) y la sincronización programada se detiene con ella.
• Rotar la credencial de una conexión invalida además todo acceso derivado de la clave anterior en el acto, así que no queda material capaz de verificar en verde una credencial que ya no existe.
• El secreto de un webhook se rota con una ventana de 24 horas en que conviven ambos, para no coordinar despliegues bajo presión.

En todos los casos la revocación es un cambio de estado, nunca un borrado: el rastro de lo que esa pieza hizo queda íntegro en la auditoría.

El modelo de amenaza del enlace

El enlace hosted es la superficie más expuesta del sistema (una URL que recolecta claves bancarias), y por eso tiene su análisis propio. El resumen:

La tabla completa, con el ciclo de vida y la semántica de cada estado, está en enlace hosted.

Próximos pasos

• El flujo que mantiene la clave fuera de tu aplicación, paso a paso: enlace hosted.
• Qué guarda exactamente cada fila de auditoría: la bitácora.
• Qué es una conexión y cómo se administra su ciclo de vida: conexiones.
• Los topes que protegen la superficie: límites.