Roles y permisos

Pathrule empieza como una herramienta individual y crece hasta convertirse en un producto para equipos. Cuando invitas a tus colegas, la pregunta pasa a ser quién puede ver y cambiar qué. Esta página explica los roles que asignas, cómo se restringe el acceso de la organización al espacio de trabajo y dónde se ejecuta realmente la verificación.

En resumen: los roles se asignan a nivel de organización, el acceso se puede restringir por espacio de trabajo y la base de datos verifica cada lectura y escritura en un espacio de trabajo de Pathrule Cloud contra tu usuario con sesión iniciada. La misma verificación se aplica tanto si la solicitud viene de la consola web en app.pathrule.io como de la CLI de Pathrule, de la extensión de VS Code o del servidor MCP con el que se comunica un cliente de IA.

Un espacio de trabajo local creado con --local no tiene cuenta y vive en una sola máquina, así que los roles no se le aplican hasta que lo muevas a la nube.

Los cuatro roles

Los roles se asignan por persona a nivel de organización. Un propietario o administrador invita a un colega por correo electrónico y elige su rol, Editor de forma predeterminada; el colega acepta la invitación para unirse. Puedes invitar desde Members en la consola web o desde la terminal:

pathrule invite colleague@example.com --role viewer

De esto se desprenden algunas salvaguardas:

• Los cambios de propiedad requieren autoridad de propietario, y la organización debe conservar un propietario.
• Los cambios de propiedad y de miembros se verifican en el servidor, incluido el requisito de conservar un propietario.

Los cambios de miembros requieren una sesión autorizada vigente. Las acciones sensibles de archivar y eliminar espacios de trabajo requieren, además, una autenticación reciente.

Puestos y planes

Cada persona de la organización ocupa un puesto, sin importar su rol.

• Solo y Pro son para una sola persona. No tienen invitaciones; para trabajar con otras personas, cambia a Team.
• Team se factura por puesto, con un mínimo de dos, incluido el propietario. Invitar a más personas que los puestos que pagas requiere otro puesto; si hay menos puestos que miembros, todos conservan el acceso y las nuevas invitaciones quedan en espera.
• Los puestos de Enterprise se acuerdan con ventas.

Los puestos y las facturas están en Billing en la consola web; pathrule billing lo abre desde la terminal. Consulta Pathrule Web.

Acceso al espacio de trabajo: de toda la organización o privado

Un rol define lo que una persona puede hacer. El modo de acceso de un espacio de trabajo define quién puede llegar a él. Cada espacio de trabajo tiene uno de dos modos.

• De toda la organización. Todos los miembros de la organización tienen acceso, con su rol en la organización.
• Privado. Solo tienen acceso las personas agregadas explícitamente al espacio de trabajo. Ser miembro de la organización no basta.

Los propietarios y administradores cambian el modo en la configuración de la consola web, en Workspace, Access. Cuando un espacio de trabajo pasa a ser privado, solo tienen acceso sus miembros explícitos. Revisa y agrega a las personas que lo necesiten; ser miembro de la organización ya no concede acceso por sí solo. Dentro de un espacio de trabajo privado, el rol de cada persona en ese espacio decide lo que puede hacer allí, así que puedes darle a alguien un nivel de acceso distinto del que tiene en otros lugares.

Perder el acceso no destruye nada

Los cambios de permisos nunca destruyen el trabajo y rara vez lo ocultan.

• Si pierdes el acceso de escritura (por ejemplo, pasas de Editor a Viewer), no desaparece nada. Puedes seguir leyendo todo lo que leías antes; se rechazan las escrituras que hagas tú o un asistente que trabaje en tu nombre.
• Si pierdes el acceso a un espacio de trabajo (te quitan de un espacio privado o de la organización), solo entonces su contenido deja de estar visible para ti. El contenido se queda con el equipo.

El mismo límite alcanza al asistente. Cuando un cliente de IA intenta escribir donde un miembro no puede escribir, la llamada a la herramienta MCP devuelve un resultado claro de permiso denegado que el asistente puede explicarte en lenguaje sencillo, en lugar de fallar en silencio o aparentar que funcionó. El contexto que recibe un asistente, y los archivos de instrucciones que Pathrule escribe para él, provienen siempre y únicamente de espacios de trabajo que ese miembro puede leer.

Dónde se ejecuta la verificación

Nada de esto se aplica en la aplicación que estés usando. Cada lectura y escritura en un espacio de trabajo de Cloud pasa por una verificación de acceso en la base de datos, resuelta contra tu usuario con sesión iniciada, tu pertenencia a la organización y el modo de acceso del espacio de trabajo. Las verificaciones de acceso forman parte de las operaciones de base de datos del servidor, no de un botón oculto en la interfaz.

• Una sola verificación para todas las superficies. La consola web, la CLI de Pathrule, la extensión de VS Code, el servidor MCP local y Remote MCP pasan por el mismo control de acceso aplicado por la base de datos. Un cambio desde la terminal y una escritura desde un cliente de IA quedan sujetos a las mismas reglas.
• Sin clave de administración compartida. Cada superficie usa un token de corta duración y por usuario, nunca una clave de servicio compartida que pudiera desbloquear los datos de otro equipo. Un cliente filtrado solo puede llegar a lo que ese usuario ya puede alcanzar.
• Resolución en el servidor. Los roles de miembro y de espacio de trabajo se resuelven en el servidor, sin confiar en lo que indique el cliente, así que una solicitud modificada no puede concederse un acceso que no se le dio.

Para ver el panorama completo de cómo se controla el acceso a la nube, consulta la descripción general de seguridad.

En la versión autoalojada

La edición Enterprise autoalojada ejecuta el mismo modelo de roles y permisos en tu propia cuenta de Cloudflare. Los roles y los modos de acceso a los espacios de trabajo se comportan igual; la diferencia es que los datos y la base de datos viven en tu cuenta. El inicio de sesión único a través de tu propio proveedor de identidad se acuerda dentro del contrato Enterprise y se asigna a los mismos roles de organización descritos aquí. Consulta Enterprise autoalojado para saber cómo funciona esa implementación.