Enterprise
Control de acceso basado en roles en workspaces y proyectos
Privilegio mínimo para una plataforma donde un prompt puede cambiar producción: roles de workspace, alcance de proyecto, y políticas de Guardrails que enrutan los cambios de riesgo a los revisores adecuados.
El control de acceso basado en roles de Ciao superpone roles de workspace, permisos a nivel de proyecto y gobernanza de Guardrails. A diferencia de las herramientas donde el acceso es todo o nada, el RBAC delimita qué puede administrar, construir y aprobar cada persona, y las políticas en lenguaje sencillo de Guardrails pueden enrutar los cambios de riesgo a revisores sénior designados, registrando la revisión humana tras cada merge en un registro de auditoría de solo adición.
Publicado 2026-07-03 · Última actualización 2026-07-03
Privilegio mínimo cuando un prompt puede cambiar producción
El control de acceso en una plataforma de desarrollo siempre ha importado; la IA eleva las apuestas porque la distancia entre la intención y el cambio de producción es más corta. Una persona con acceso amplio ya no es solo alguien que puede leer demasiado, es alguien cuya petición en lenguaje sencillo puede convertirse en código en ejecución. El privilegio mínimo deja de ser un detalle de cumplimiento y se convierte en el control principal sobre qué hará la plataforma en nombre de quién.
El modelo de Ciao responde tres preguntas distintas con tres capas distintas: quién puede administrar el workspace, quién puede trabajar en qué proyectos, y quién puede aprobar qué cambios. Los revisores deberían evaluar cada capa por separado, porque colapsar todo en un único interruptor «admin vs usuario» es exactamente la debilidad de diseño hacia la que tiende esta categoría.
La recompensa por acertar en las capas es velocidad además de seguridad. Cuando los cambios rutinarios fluyen con revisión ligera y solo las áreas protegidas exigen ojos sénior, la gobernanza deja de ser el cuello de botella que los equipos rodean, y los controles que la gente no rodea son los únicos controles que se sostienen.
Lo que ofrece Ciao
Cinco mecanismos, cada uno verificable de forma independiente durante la evaluación:
- Roles de workspace — La capacidad administrativa (configuración de identidad, membresía, ajustes del workspace) es un rol asignado deliberadamente, no un valor por defecto.
- Permisos a nivel de proyecto — El acceso se delimita a los proyectos en los que realmente trabaja una persona, así un contratista en un build no hereda visibilidad sobre el resto del portafolio.
- Políticas de Guardrails con antigüedad — Guardrails aplica políticas en lenguaje sencillo a los cambios de riesgo y registra la revisión humana, y las políticas pueden nombrar quién tiene la antigüedad suficiente para revisar cambios en áreas de negocio protegidas.
- Integración de identidad — El SSO vía SAML y OIDC con MFA opcional autentica a las personas; el mapeo de grupo a rol de SCIM mantiene los roles alineados con tu directorio.
- Administración registrada — Las concesiones de roles y los cambios de permisos son acciones de administración en el registro de auditoría de solo adición, así las revisiones de acceso citan registros, no memoria.
Niveles de antigüedad en Guardrails
No todo cambio merece el mismo revisor. Un ajuste de texto en una página de marketing y una modificación de la lógica de pagos son eventos distintos, y un modelo de gobernanza que los trate igual o ralentizará todo o no revisará nada bien. Guardrails mapea el código en áreas de negocio y detecta cambios de riesgo, lo que deja a la política distinguir entre los dos, en lenguaje sencillo, legible para el equipo de cumplimiento que tiene que aprobar la propia política. Ese mapeo es lo que hace significativa la antigüedad: la plataforma sabe qué área de negocio toca un cambio, así la política puede decir quién está cualificado para juzgarlo.
La antigüedad entra como política: los cambios que tocan áreas protegidas se pueden enrutar a revisores sénior designados, mientras los cambios rutinarios fluyen con revisión más ligera. La revisión que ocurre queda registrada, así el registro de auditoría muestra no solo que un cambio se aprobó sino que lo aprobó alguien que la política consideró cualificado. Y como las políticas están en lenguaje sencillo, las personas responsables del control (cumplimiento, riesgo, liderazgo de ingeniería) pueden leerlas y cuestionarlas directamente, sin capa de traducción entre la política que se aprobó y la regla que se ejecuta.
Desplegando RBAC
1. Mapea los roles a la realidad
Enumera quién administra, quién construye, quién revisa y quién solo observa, a partir de tu organigrama, no de los valores por defecto de la herramienta.
2. Conecta la identidad
Pon la autenticación detrás del SSO, y mapea los grupos del IdP a roles vía SCIM para que el directorio dirija el acceso.
3. Delimita los proyectos
Asigna permisos a nivel de proyecto para que el alcance de cada persona coincida con su trabajo, con contratistas y proveedores delimitados de forma más estricta.
4. Escribe políticas de Guardrails
Define, en lenguaje sencillo, qué áreas de negocio están protegidas y qué revisores tienen la antigüedad suficiente para aprobar cambios ahí.
5. Revisa con evidencia
Ejecuta tu primera revisión de acceso a partir del registro de auditoría: las concesiones de rol, los cambios de permisos y los merges registrados le dan a la revisión su base de evidencia.
Tres capas, tres preguntas
Cada capa responde a una pregunta distinta de revisor: puntúalas por separado:
| Capa de acceso | Pregunta que responde | Mecanismo |
|---|---|---|
| Roles de workspace | ¿Quién puede administrar el workspace? | Capacidad de administración asignada deliberadamente |
| Permisos de proyecto | ¿Quién puede trabajar dónde? | Delimitación de acceso por proyecto |
| Políticas de Guardrails | ¿Quién puede aprobar qué cambios? | Políticas en lenguaje sencillo con revisión humana registrada |
| Identidad | ¿Quién es realmente esta persona? | SSO vía SAML y OIDC, MFA opcional, mapeo de SCIM |
| Evidencia | ¿Qué pasó realmente? | Registro de auditoría de solo adición de acciones de administración y merges |
Notas de verificación
Las afirmaciones de RBAC se verifican mejor intentando cosas. Durante la evaluación, haz que un usuario delimitado intente alcanzar un proyecto fuera de su asignación, y haz que un revisor no sénior intente aprobar un cambio en un área protegida, luego lee ambos eventos en el registro de auditoría. El paquete de seguridad, disponible a petición vía la página de contacto, documenta el modelo de acceso por escrito, y los informes SOC 2 Tipo II bajo NDA cubren los controles auditados de gestión de acceso.
Lleva tu propio organigrama a la evaluación: nombra a un contratista real, un ingeniero júnior real y un sistema protegido real, y configura la prueba para que coincida. Las demos abstractas de RBAC siempre se ven bien; tu estructura es la prueba que importa.
Preguntas frecuentes
¿Puede un desarrollador júnior fusionar cambios en un área de negocio protegida?
Guardrails detecta cambios de riesgo y aplica las políticas en lenguaje sencillo que define tu workspace, incluido enrutar los cambios en áreas protegidas a revisores sénior designados, con la revisión humana registrada. Verifica el comportamiento contra tu propia política durante la evaluación en lugar de tomar un sí/no de una página web.
¿Podemos delimitar a los contratistas a un solo proyecto?
Los permisos a nivel de proyecto existen exactamente para esto: el acceso de un contratista se delimita a los proyectos en los que trabaja. Combínalo con SCIM para que el fin del contrato en tu directorio también termine el acceso.
¿Cómo se auditan los cambios a los propios roles y permisos?
Las concesiones de rol y los cambios de permisos son acciones de administración, registradas en el registro de auditoría de solo adición junto con prompts, merges y despliegues. Las revisiones de acceso pueden por tanto trazar quién cambió el acceso de quién, y cuándo.
¿El control de acceso aplica a lo que hace la IA, o solo a los humanos?
Los cambios generados por IA pasan por la misma vía gobernada que los humanos: Guardrails los mapea a áreas de negocio, detecta riesgo, aplica política y registra la revisión humana tras cada merge. Los controles que tu revisión evalúa para las personas son los controles que gobiernan el propio resultado de la plataforma.
¿Pueden los roles dirigirse por nuestros grupos de IdP?
Sí, el aprovisionamiento SCIM mapea los grupos del IdP a roles de Ciao, así la asignación de roles sigue el directorio que tu equipo ya gobierna. El mapeo se acuerda durante la incorporación y sus cambios se registran como acciones de administración.