> **Can't find what you're looking for?** Use `search_docs` on the docs MCP server at `https://naturgy-comer-documentation-p5mde.vercel.app/api/mcp` to find what you need.

# Seguridad y acceso

La solución tiene dos planos que no deben mezclarse:

1. **Cliente residencial:** sesión, contenido, conversación y datos de negocio.
2. **Operación de plataforma:** usuarios que administran workflows, credenciales,
   Knowledge Bases, runs, Twin y configuración.

Una identidad técnica de la app o de un workflow no se convierte en el permiso
del cliente final por incluir su `user_id` en una petición.

## Separación de identidades

```mermaid
flowchart TD
    customer["Cliente residencial"] --> app["Super App"]
    app -->|"sesión"| omega["Omega / identidad de cliente"]
    app -->|"chat o voz"| channel["HappyRobot / Connect"]
    channel --> runtime["Workflow runtime"]
    runtime --> backends["APIs de negocio autorizadas"]

    operator["Operador de plataforma"] -->|"SSO + MFA"| console["Consola / Runs / Twin"]
    console --> rbac["RBAC, roles y scopes"]
    rbac --> resources["Workflows, credenciales y recursos"]
```

## Controles por superficie

| Superficie | Identidad | Control principal | Límite |
|---|---|---|---|
| Modo anónimo | Cliente sin sesión | Contenido y operaciones expresamente públicas | No autoriza ficha ni mutaciones de negocio. |
| Área de cliente | Token/sesión de Omega | Autorización del backend owner | La app no decide por sí sola qué contratos puede ver. |
| Chat y voz | Sesión técnica de canal y workflow | Tokens, scopes y contrato de integración | No demuestra aislamiento por conversación si se usa una credencial amplia. |
| APIs de negocio | Identidad técnica por tool/environment | API key, OAuth u otro mecanismo del owner | El modelo no recibe ni amplía credenciales. |
| Consola HappyRobot | Usuario operador | SSO/MFA, roles, Access Actions y scopes | El rol de consola no se propaga automáticamente al runtime. |
| Handoff humano | Agente de Connect o TeLeo | Cola, ticket y contexto mínimo | No debe recibir tokens, API keys ni PII innecesaria. |

## Riesgo de la credencial de la app

El material revisado identifica un riesgo residual: una credencial técnica de
HappyRobot embebida en la aplicación puede tener un alcance más amplio que una
conversación concreta. Si esa credencial permite abrir sesiones, leer mensajes o
consultar transcripts con alcance de organización, no equivale a una identidad
por usuario final.

RBAC v2 puede mejorar el acceso de operadores internos a recursos de la consola,
workflows, credenciales, Knowledge Bases, componentes, apps y Twin. La evidencia
revisada no demuestra que una API key de organización quede limitada por usuario,
cliente o conversación. Por tanto, RBAC v2 no debe presentarse como cierre de
este riesgo.

Las alternativas siguen siendo una decisión de owner:

* gateway o token broker que custodie la credencial y emita permisos acotados;
* permiso o token por conversación con scope comprobable;
* obtener el transcript de voz desde el sistema de voz autorizado;
* combinar intermediación de chat con una fuente de transcript de voz;
* aceptar formalmente el riesgo con controles de rotación y monitorización.

Hasta cerrar esa decisión no se debe ampliar el scope, copiar la credencial en
logs o prompts, ni enviar tokens al handoff.

## Datos sensibles y minimización

El Dispatcher debe recibir solo canal, intención, urgencia, sesión/correlación y
el contexto mínimo que necesita para enrutar. El especialista recibe los datos
adicionales únicamente cuando su backend y su política los exigen.

No deben entrar en prompts, logs, Twin, evaluaciones ni payloads de handoff:

* API keys, client secrets, cookies o tokens completos;
* DNI, NIF, IBAN o teléfono completo si no son necesarios;
* transcripts completos fuera del servicio que los necesita;
* datos de otro cliente o de otra conversación;
* valores de prueba que puedan confundirse con datos reales.

La app puede guardar tokens en almacenamiento seguro del dispositivo cuando el
contrato lo permita. Preferencias y caché ligera no son una base de datos de
negocio.

## Retención y borrado

La retención efectiva depende de cada servicio y de la configuración del tenant:
Omega, HappyRobot, Connect, TeLeo, Salesforce/Mulesoft, Twin, logs y analítica
pueden tener ciclos distintos. No se debe trasladar automáticamente una ventana
de retención de una referencia de arquitectura a este caso.

Antes de producción se deben confirmar finalidad, owner, periodo, borrado,
backups, exportaciones y acceso por entorno. Consulta [Datos, retención y
borrado](/use-cases/super-app/reference/data-retention).

## Decisiones de seguridad pendientes

* scope real de la credencial móvil y alternativa por conversación;
* aislamiento de transcripts y mensajes entre clientes;
* roles, tags, Access Actions y enforcement servidor del tenant;
* revocación, rotación y auditoría de identidades técnicas;
* autorización de Connect, Mulesoft, TeLeo, Omega y backends de negocio;
* retención y borrado verificable por canal;
* pruebas de acceso cruzado, replay, prompt injection, handoff sin autenticación
  y respuestas de backend malformadas.

Para revisar la evidencia y los gates, consulta [Evidencia, UAT y pendientes](/use-cases/super-app/reference/evidence).