# Cuentas y acceso

Una cuenta reúne tus proyectos, tus compañeros de equipo y un modelo de acceso.

Canonical page: https://beeuni.ai/docs/es/accounts

Una cuenta reúne tus [proyectos](/docs/es/project) y a las personas que trabajan en ellos. Cuando te registras, Beeuni crea una cuenta personal para ti. Invita a un compañero de equipo y se convierte en una cuenta de equipo. Las cuentas personales y de equipo usan los mismos roles, facturación y límites.

<a id="one-access-model"></a>

## Un único modelo de acceso

Beeuni tiene un único registro de concesión: una **asignación**. Cada asignación vincula a un principal con un rol, en un ámbito.

| Término | Significado |
|---|---|
| **Principal** | Quién tiene el acceso. Un `user`, un `group`, un `service_account` (la identidad de un agente) o el correo electrónico de un invitado `pending`. |
| **Rol** | Un conjunto de permisos con nombre. Beeuni incluye los roles integrados que se indican a continuación. Una cuenta puede añadir roles personalizados. |
| **Permiso** | Una acción, por ejemplo `project.secret.read` o `member.update`. |
| **Ámbito** | Dónde se aplica el rol: en toda la `account` o en un solo `project`. |
| **Objeto** | Opcional. Restringe la asignación a un solo `agent`, `skill`, `secret`, `app` o `trigger` dentro del ámbito. |
| **Caducidad** | Opcional. La asignación deja de conceder acceso en `expires_at`. |

No existe un segundo almacén de concesiones. El acceso de un grupo, una concesión por recurso y la vinculación de un rol personalizado son asignaciones. Solo se diferencian por el principal, el objeto y el rol.

<a id="account-roles"></a>

## Roles de cuenta

Cada persona de una cuenta tiene un rol de cuenta:

- **Propietario** — control total, incluidos los miembros y la facturación.
- **Administrador** — gestiona proyectos, miembros, grupos, roles y tokens.
- **Miembro** — trabaja solo en los proyectos a los que tiene una asignación de proyecto.

Los propietarios y administradores tienen acceso equivalente al de un administrador en todos los proyectos de la cuenta. Una asignación de proyecto no puede reducirlo. Para limitar a un propietario o administrador en un proyecto, primero cambia su rol de cuenta a miembro.

El acceso equivalente al de un administrador no incluye las sesiones privadas de los miembros. El propietario de una cuenta puede habilitarlo para propietarios y administradores con **Los administradores pueden abrir todas las sesiones** en **Settings → Security**. Solo un propietario puede cambiar esta opción y cada uso queda registrado en la auditoría. Consulta [Acceso a las sesiones](/docs/es/work/sessions#admins-can-open-every-session).

Invita a un compañero de equipo por correo electrónico desde la página de miembros de la cuenta. La invitación es una asignación a un principal `pending`. Cuando la acepta, se convierte en una asignación `user`.

<a id="project-roles"></a>

## Roles de proyecto

Dentro de un proyecto, un principal tiene uno de dos roles:

- **Miembro** — lee el proyecto, inicia y detiene sus sesiones y activa sus desencadenadores. No puede editar ni configurar.
- **Administrador** — tiene todos los permisos del proyecto: lo edita, gestiona desencadenadores, conectores, habilidades, secretos y acceso, tiene las claves de la puerta de enlace y elimina el proyecto.

No hay un tercer rol de proyecto.

El rol de administrador incluye el conjunto completo de permisos del proyecto. Un rol personalizado solo añade permisos, así que ningún rol puede retirar uno a un administrador. Las [asignaciones de objetos](#object-assignments) son el mecanismo independiente que restringe *a qué objetos* llega un permiso.

Configura el acceso al proyecto desde sus ajustes de acceso o con `beeuni access` — consulta [CLI](/docs/es/cli#access).

<a id="groups"></a>

## Grupos

Un grupo es un principal, igual que una persona. Asigna un rol a un grupo en un ámbito y todos sus miembros lo obtendrán. Un grupo añade acceso. Nunca elimina el acceso que una persona ya tiene. Un grupo aprovisionado mediante SCIM es del mismo tipo de principal que uno creado manualmente.

<a id="object-assignments"></a>

## Asignaciones de objetos

Una asignación puede especificar un objeto dentro de un proyecto: un `agent`, un `skill`, un `secret`, un `app` o un `trigger`. Actualmente, Beeuni aplica las asignaciones de objetos a agentes y habilidades.

- **Los agentes están cerrados de forma predeterminada.** Un miembro solo puede acceder a un agente si una asignación lo nombra a él, a uno de sus grupos o a todos los miembros del proyecto.
- **Todos los demás tipos de objetos están abiertos de forma predeterminada.** Si el objeto no tiene asignaciones, un miembro puede acceder a él. Una cuenta de conector compartida con una asignación solo puede ser utilizada por las personas que esta nombra — consulta [Elegir quién puede usar una cuenta compartida](/docs/es/connect/connectors#choose-who-can-use-a-shared-account).
- **Todos los miembros del proyecto también forman un principal.** En el cuadro de diálogo **Grant access**, selecciona **Everyone in** seguido del nombre del proyecto para dar acceso a un agente a todos los miembros a la vez (`principal_type: "project"`, `principal_id` = el ID del proyecto). Solo admite asignaciones de objetos, nunca un rol, por lo que cada persona conserva su propio rol de proyecto.
- **Una asignación de objeto también restringe a un administrador de proyecto.** Así, «restringir este agente al grupo de finanzas» tiene sentido. Lo que otorga el rol de administrador es el acceso predeterminado sin restricciones de ámbito, no una exención.
- **Las asignaciones de objetos nunca restringen a los propietarios ni a los administradores de la cuenta**, ni a una cuenta de servicio que actúe sobre sus propias asignaciones.

Una asignación de objeto no concede permisos por sí misma. Responde a «¿a qué objetos?», no a «¿qué acciones?».

<a id="expiry"></a>

## Caducidad

Añade una `expires_at` a una asignación y dejará de conceder acceso en ese instante. El motor ignora las asignaciones caducadas. El registro se conserva para el historial de auditoría.

<a id="one-vocabulary-two-bindings"></a>

## Un vocabulario, dos vinculaciones

Una persona, un grupo o un agente obtiene acceso de Beeuni mediante **roles**: las asignaciones descritas anteriormente. Un agente tiene una **segunda vinculación independiente**: los permisos de Beeuni que declara su manifiesto en `beeuni.yaml` dentro de `agents.<name>.beeuni_permissions`. Una sesión solo puede hacer lo que permiten ambos. Ninguno amplía los permisos del otro. Si el manifiesto de un agente incluye `project.secret.read`, aun así no podrá leer nada cuando la evaluación del rol lo deniegue. Y si un propietario inicia un agente, este tampoco podrá leer nada si su manifiesto no incluye la acción. Los roles son estado de la cuenta; los permisos de Beeuni son estado del repositorio en el manifiesto. Consulta [Referencia del manifiesto](/docs/es/project/manifest#agents).

El rol que cuenta para una sesión de agente es el vinculado a la propia cuenta de servicio del agente —su **límite máximo**— o el límite predeterminado del agente si no hay ninguno vinculado. No se aplica el rol de la persona que inició la sesión. Un permiso, `project.credentials.issue`, es exclusivo para personas y nunca se aplica a un agente. Un agente solo concede los permisos que tiene. Los administradores eligen un agente como principal de un rol de proyecto en el Centro de acceso, en **Agents**. Consulta [Permisos de agentes](/docs/es/project/permissions).

<a id="custom-roles"></a>

## Roles personalizados

Un rol personalizado es un rol propiedad de la cuenta, con los permisos que elijas. Al asignarlo, se crea una única asignación: no hay una fila de referencia integrada por debajo. Un rol personalizado puede conceder acceso al proyecto sin ningún rol de proyecto integrado, que es la forma de crear un rol propio de un departamento.

Un rol personalizado solo añade permisos. Beeuni no tiene reglas de denegación.

Los roles personalizados requieren la suscripción `rbac` de Enterprise. Sin ella, al asignar uno se responde `402` con `code: "entitlement_required"`.

<a id="super-admin"></a>

## Superadministrador

Superadministrador no es un rol. Es una marca en una pertenencia a una cuenta. Omite todas las comprobaciones de permisos y cada omisión queda registrada en el registro de auditoría. Los roles son el mecanismo habitual para controlar el acceso; el superadministrador es la vía de escape auditada.

El creador de la cuenta empieza como propietario y superadministrador. Cuando se degrada a un propietario, el rol de propietario y la marca de superadministrador van juntos: el cambio elimina la marca y registra `iam.member.super_admin.revoke`. Si se concede la marca de superadministrador a alguien que no es propietario, permanece hasta que un propietario la revoque.

<a id="single-sign-on-domain"></a>

## Dominio de inicio de sesión único

Un proveedor de identidad SAML afirma la dirección de correo electrónico de cada persona. Beeuni confía en esa dirección fuera de tu cuenta solo para un dominio que tu cuenta haya verificado. Hasta entonces:

- una persona que inicie sesión mediante tu proveedor de identidad se une a tu cuenta y obtiene sus grupos;
- su identidad SSO no coincide con ninguna invitación de otra cuenta, y la opción «añadir miembro por correo electrónico» de otra cuenta no la encuentra;
- el inicio de sesión SSO nunca combina una identidad existente con la identidad SSO;
- **Enforce SSO** no tiene efecto y el inicio de sesión con contraseña sigue funcionando para el dominio.

Para verificar el dominio, abre **Identity** en los ajustes de la cuenta. La tarjeta SSO muestra un registro DNS TXT: nombre `_beeuni-verification.<your-domain>`, valor `beeuni-verification=<token>`. Publícalo en tu proveedor de DNS y selecciona **Verify domain** (`POST /v1/accounts/:accountId/iam/sso/provider/verify-domain`). Cada dominio pertenece a una sola cuenta: un dominio que otra cuenta ya haya verificado no se puede volver a verificar. Al cambiar el dominio principal, se inicia una nueva solicitud de verificación.

Cuando el dominio está verificado y **Enforce SSO** está activado, el formulario web de inicio de sesión, `/v1/access/check-email` y las rutas sin interfaz `/v1/auth/sign-in/password`, `/v1/auth/sign-in/magic-link` y `/v1/auth/verify-otp` rechazan las opciones de contraseña y código de correo electrónico para ese dominio (`403 sso_required`).

El inicio de sesión SSO nunca combina a un propietario o superadministrador con una identidad SSO, ni siquiera en un dominio verificado. Conservan su identidad actual y la identidad SSO se une como miembro independiente.

<a id="per-feature-access-settings"></a>

## Ajustes de acceso por función

Algunas funciones tienen sus propios ajustes de visibilidad, además del modelo de roles:

| Ajuste | Determina |
|---|---|
| [Modo de acceso a la aplicación](/docs/es/feature-flags/apps#access-modes) | Quién puede abrir una aplicación implementada |
| [Acceso a las sesiones de desencadenadores](/docs/es/connect/triggers#session-access) | Quién puede abrir las sesiones que crea un desencadenador |
| [Política de canales de Slack](/docs/es/connect/slack) | Quién puede iniciar una sesión desde un canal |
| [Capacidades de Computer](/docs/es/connect/computers#what-the-computer-allows) | Qué llamadas al sistema de archivos, al shell y al escritorio acepta un ordenador conectado |

Cada ajuste limita el acceso a un recurso. Ninguno concede un permiso que la evaluación del rol deniegue.

<a id="the-access-api"></a>

## La API de acceso

| Método + ruta | Función |
|---|---|
| `GET /v1/accounts/{accountId}/iam/assignments` | Enumera las asignaciones. Filtra por principal, ámbito, objeto o rol. |
| `POST /v1/accounts/{accountId}/iam/assignments` | Crea una asignación. |
| `DELETE /v1/accounts/{accountId}/iam/assignments/{assignmentId}` | Revoca una asignación. |
| `GET /v1/accounts/{accountId}/iam/permissions` | El catálogo de permisos, como datos. |
| `GET /v1/accounts/{accountId}/iam/roles` | Roles integrados y personalizados. |
| `GET /v1/accounts/{accountId}/iam/roles/{roleId}/permissions` | Los permisos de un rol. |

El catálogo son datos, no una lista codificada. Cada permiso incluye sus indicadores `action`, `scope_type`, `resource_type`, `delegable`, `description`, `area`, `level` y `implies`. Léelo en lugar de codificar cadenas de acciones.

Las rutas de escritura determinan el permiso necesario según lo que estés concediendo: `project.members.manage` para un rol de proyecto o una asignación de objeto, `project.connector.connections.manage` para una asignación `connection`, `member.update` para un rol de cuenta y `policy.create` para un rol personalizado. No puedes eludir un límite máximo eligiendo otra ruta.

<a id="branding"></a>

## Marca

Una cuenta Enterprise puede personalizar la marca de la aplicación para todos sus miembros: un logotipo apaisado, un icono cuadrado y un favicon, cada uno con una variante opcional para el modo oscuro, además del nombre del producto, que reemplaza a «Beeuni» en el título de la pestaña del navegador. Abre **Account → Branding** (`/accounts/{accountId}?tab=branding`). Se aceptan archivos PNG, JPEG, WebP, SVG e ICO de hasta 1 MB. Si falta el logotipo, se usa el icono; si falta el favicon, se usa el icono; y si falta la variante oscura, se usa la imagen clara. Los elementos de marca de la aplicación siguen el tema de la aplicación; el favicon sigue el esquema de color del sistema operativo.

La marca depende de la cuenta, no del navegador: dentro de un proyecto, los miembros ven la marca de la cuenta propietaria del proyecto. Las páginas de inicio de sesión, los correos electrónicos y las páginas públicas para compartir conservan la marca Beeuni, porque no hay una cuenta que personalizar hasta que alguien inicia sesión. Cuando caduca la suscripción Enterprise, los miembros vuelven a ver Beeuni. No se elimina nada y la cuenta puede quitar en cualquier momento lo que haya subido.

| Método + ruta | Función |
|---|---|
| `GET /v1/accounts/{accountId}/branding` | El registro almacenado y si el plan lo permite. |
| `PUT /v1/accounts/{accountId}/branding` | Establece o borra `app_name`. Requiere `account.write` y la suscripción `branding` (de lo contrario, `402 entitlement_required`). |
| `POST /v1/accounts/{accountId}/branding/assets/{kind}` | Sube una imagen como `file` multiparte. `kind` puede ser `logo`, `icon`, `favicon` o sus variantes `_dark`. Tiene los mismos requisitos que `PUT`. |
| `DELETE /v1/accounts/{accountId}/branding/assets/{kind}` | Quita una imagen. Solo `account.write`. |
| `DELETE /v1/accounts/{accountId}/branding` | Restablece todo a Beeuni. Solo `account.write`. |

`GET /v1/accounts` incluye `branding` efectivo de cada cuenta: el registro mientras la suscripción está activa, `null` en caso contrario, para que el cliente muestre la marca con una sola solicitud que ya realiza. En el SDK: `beeuni.accounts.branding.{get, update, uploadAsset, removeAsset, reset}`.

<a id="switching-accounts"></a>

## Cambiar de cuenta

Si perteneces a más de una cuenta, puedes cambiar entre ellas desde el selector de cuentas. Cada cuenta conserva sus propios proyectos, miembros y ajustes.

<a id="signed-in-devices"></a>

## Dispositivos con sesión iniciada

**Settings → Security → Devices** muestra todos los lugares donde tienes una sesión iniciada: navegadores, la aplicación de escritorio y la aplicación móvil.

- **Sign out** en un dispositivo cierra esa sesión de inmediato. No se puede renovar, su token deja de funcionar en las rutas de la cuenta y el teléfono deja de recibir notificaciones push.
- **Sign out other devices** cierra todas las demás sesiones. Ninguna se puede renovar y sus teléfonos dejan de recibir notificaciones push de inmediato.

Si se vuelve a iniciar sesión en un teléfono, este volverá a recibir notificaciones push.

## Tokens

Beeuni te identifica mediante un token de acceso personal (`beeuni_pat_...`). Actúa como el usuario que lo creó y tiene exactamente las asignaciones de ese usuario. Una cuenta de servicio (`beeuni_sa_...`) es un principal independiente, no la credencial de una persona, y no tiene acceso a proyectos hasta que una asignación se lo concede.

Los dos tipos aparecen en secciones distintas porque pertenecen a propietarios distintos. Tus propias claves de API están en tus ajustes, en **Settings → API keys** (`/settings/tokens`): solo tú puedes verlas y dejan de funcionar cuando termina tu pertenencia a la cuenta. Los tokens de cuenta de servicio forman parte de la configuración de la cuenta, en **Account → Tokens**, junto a las reglas de claves que rigen su caducidad.

Consulta Autenticación del SDK para obtener información completa sobre los tokens.

<a id="audit-log"></a>

## Registro de auditoría

El registro de auditoría registra todas las solicitudes que llegan a la API, tanto si identifican a quien las llama como si no. El servidor escribe una fila por cada solicitud HTTP, actualización de WebSocket, solicitud de vista previa, transferencia Git y llamada SCIM. La cobertura no depende de la ruta.

Cada fila indica a quién identificó la solicitud:

| `actor_type` | Quién realiza la llamada |
| --- | --- |
| `human` | Una persona con sesión iniciada o el token de una persona (`source: api_key`). |
| `agent` | La credencial de agente de una sesión. La fila también indica en nombre de qué persona actúa el agente. |
| `service_account` | Un token de cuenta de servicio. |
| `system` | Una clave de API de cuenta, un token de directorio SCIM, un webhook de integración con firma verificada o una tarea en segundo plano de Beeuni (`source: worker`). |
| `anonymous` | Una solicitud sin credenciales o con credenciales no válidas o falsificadas. |

Cada fila también registra la credencial que autenticó la API, en `credential_kind` y `credential_id`. El ID identifica la credencial, nunca el secreto. La aplicación web lo muestra como **Via**, con el nombre del token o de la aplicación cuando lo hay.

| `credential_kind` | Credencial | `credential_id` |
| --- | --- | --- |
| `browser_session` | Una sesión de inicio de sesión de Beeuni (la aplicación web o un cliente con un JWT de inicio de sesión). | El id de la sesión de inicio de sesión. |
| `personal_access_token` | Un token de acceso personal, como el de la CLI. | El id del token. |
| `oauth_app` | El token `beeuni_oat_` de una aplicación conectada, como un cliente MCP. | El id del cliente OAuth. |
| `session_token` | El token propio de una sesión de agente. | El id de la sesión. |
| `api_key` | Una clave de API de cuenta. | El id de la clave. |
| `service_account` | Un token de cuenta de servicio. | El id de la cuenta de servicio. |
| `scim_token` | Un token de directorio SCIM. | El id del token. |

La API nunca lee `X-Beeuni-Client`. La CLI, el servidor MCP y la aplicación web llaman a la misma API, y cualquier cliente puede enviar cualquier valor de encabezado, así que el registro refleja lo que la API puede demostrar. Las filas escritas antes del 2026-09-30 pueden incluir un `client_reported_source` declarado por el propio cliente. Las filas nuevas lo dejan vacío. Filtra por credencial con `?credential_kind=oauth_app` en `GET /v1/accounts/:accountId/audit`, o `beeuni audit ls --credential-kind oauth_app`.

Las filas escritas antes de 2026-10 incluyen `session_sequence`, `integrity_previous_hash` y `integrity_hash`: un contador por sesión y una cadena de hash. Las filas nuevas dejan vacíos los tres campos, que están obsoletos. Nadie verificaba la cadena y mantenerla serializaba todas las escrituras de una sesión. El registro de una sesión se ordena por hora de creación: primero aparecen las filas con `session_sequence`, en ese orden, y luego las filas más nuevas, en el orden en que las creó la API.

Una solicitud rechazada es una fila con `outcome: denied`. `metadata.auth` registra cómo se autenticó el cliente: el id del token, nunca el secreto. Un clon de Git es la acción `git.clone`. Una inserción es `git.push`, y `metadata.refs` enumera cada referencia que creó, actualizó o eliminó.

<a id="retention"></a>

### Retención

| Antigüedad del evento | Dónde se almacena | Cómo leerlo |
| --- | --- | --- |
| De 0 a 90 días | PostgreSQL, una partición por semana | El registro de auditoría en la aplicación web, `GET /v1/accounts/:accountId/audit`, `beeuni audit ls`, los webhooks de auditoría y la exportación |
| De 90 a 365 días | Un archivo de S3 con Object Lock (modo de cumplimiento) | Solo mediante exportación: `GET /v1/accounts/:accountId/audit/export` o `beeuni audit export` |
| Más de 365 días | Eliminado | No disponible |

Las semanas van del lunes a las 00:00 UTC al lunes siguiente a las 00:00 UTC. Una semana pasa al archivo cuando su último instante tiene 90 días de antigüedad, así que un evento pasa a estar disponible solo mediante exportación entre 90 y 97 días después de ocurrir. El archivo conserva un evento hasta 365 días después del final de su semana, por lo que se conserva entre 365 y 372 días en total. El bloqueo de retención impide que cualquier persona, incluido el personal de Beeuni, acorte ese plazo o lo elimine antes. La política de privacidad establece el mismo límite: los registros de la aplicación se conservan hasta 365 días.

La exportación devuelve el archivo y PostgreSQL como una sola lista, del más antiguo al más reciente, con los mismos filtros, los mismos campos y la misma paginación `X-Audit-Next-Cursor`. Ambas vías de lectura requieren el derecho `auditAccess`. Los eventos archivados incluyen los mismos campos que los actuales; `session_sequence` y los hashes de integridad están vacíos en los eventos escritos desde 2026-10 (consulta más arriba).

<a id="actions"></a>

### Acciones

Cada fila tiene un `action` llamado `domain.resource.verb` y un título que muestran la aplicación web y `beeuni audit ls`:

| Acción | Título | Registrado por |
| --- | --- | --- |
| `gateway.key.revoke` | Clave de la pasarela LLM revocada | Una solicitud a `DELETE /v1/projects/:projectId/gateway/keys/:keyId`. |
| `iam.group.create` | Grupo creado | La solicitud que creó el grupo. La fila incluye el nuevo grupo en `after`. |
| `secret.consumer.used` | Secreto utilizado | Un entorno aislado que leyó un secreto. |
| `api.rate_limit.exceeded` | Límite de solicitudes de la API alcanzado | Un limitador que rechazó una solicitud. `metadata.limiter` lo identifica. |

Cada ruta de la API tiene exactamente una acción. La fila de una solicitud conserva la plantilla de ruta en `metadata.http`, nunca la ruta sin procesar, que puede contener un token. Si un controlador registra su propio evento para la solicitud, con el estado anterior y posterior, ese evento es la única fila de la solicitud. Una solicitud que no coincide con ninguna ruta es `api.route.unmatched`.

Filtra por un prefijo de acción: `?action=iam.` en `GET /v1/accounts/:accountId/audit`, `beeuni audit ls --action iam.` o `--action-prefix` de un webhook de auditoría. [Acciones del registro de auditoría](/docs/es/audit-actions) enumera todas las acciones y sus títulos. Las filas escritas antes del 2026-09-24 tienen `METHOD /template` como acción y muestran los mismos títulos.

Los trabajos en segundo plano de Beeuni actúan sin una solicitud: vencen concesiones y permisos de túnel, eliminan ramas de sesión vencidas, activan implementaciones de App y mueven proyectos entre proveedores de entornos aislados. Sus filas tienen `source: worker`, y `metadata.auth.worker` identifica el trabajo, por ejemplo `tunnel-cleanup` o `app-deployments`. La fila de una implementación de App también identifica como iniciador al miembro que la inició.

Las solicitudes anónimas que mencionan uno de tus proyectos se registran en tu registro. Selecciona estas filas con `actor_type=anonymous`. Las filas anónimas tienen un límite de frecuencia en cada proceso de la API, así que una avalancha de ellas no puede desplazar las filas atribuidas. No se registran las comprobaciones de estado, las solicitudes previas de CORS ni el tráfico anónimo a una App implementada.

<a id="billing"></a>

## Facturación

Free incluye un proyecto y 20 $ en créditos iniciales, válidos durante 30 días desde su recepción. Desde el siguiente período recibes 2 $ al mes, sin acumulación. Los créditos cubren el funcionamiento del ordenador y los modelos oficiales.

La oferta inicial se concede una sola vez por cuenta personal. Quienes recibieron los antiguos 2 $ obtienen la diferencia de 18 $; quienes nunca los recibieron obtienen 20 $. Crear otro equipo o proyecto no concede la oferta de nuevo. Los créditos comprados se guardan por separado y no se eliminan al caducar o renovarse los créditos gratuitos.

La facturación se aplica a nivel de cuenta y cubre todos los proyectos de la cuenta. Beeuni ofrece un plan gratuito, un plan Pro y un plan Team por asiento, cada uno con acceso a modelos y créditos propios. Usar tu propia clave de modelo no hace que el uso sea gratuito: Beeuni sigue cobrando una tarifa de plataforma, salvo en el plan gratuito.

> **Enterprise**
>
> El inicio de sesión único (`sso`), el aprovisionamiento SCIM (`scim`), los roles personalizados (`rbac`) y el acceso de auditoría (`auditAccess`) son prestaciones del plan Enterprise. Una prestación es independiente de un rol: determina si la función está disponible para la cuenta, mientras que el rol sigue determinando quién puede usarla. Contacta con el equipo de ventas para habilitarlas.