Cuentas y acceso

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

Una cuenta reúne tus proyectos 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.

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.

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.

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.

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.

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 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.

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.

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.
• 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?».

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.

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.

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.

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".

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.

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.

Ajustes de acceso por función

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

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

La API de acceso

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.

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.

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}.

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.

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.

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:

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.

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ó.

Retención

Las semanas van del lunes a las 00 UTC al lunes siguiente a las 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).

Acciones

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

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 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.

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.