Identity & Access Management

governed access at every level security begins with knowing exactly who is accessing your system and what they are permitted to do tavio implements a hierarchical identity and access management (iam) model that enforces the principle of least privilege this ensures that users—whether they are developers, support staff, or end customers—have access only to the specific resources required for their role, and nothing more hierarchical rbac role based access control (rbac) is applied at two distinct levels the organization, which is primarily administrative; and the environment, which is more operational organization level these roles govern the business side of the platform organization owner & administrator users with these roles retain full control over the tenant they manage user provisioning, billing, and the creation of new environments organization support this role grants read only visibility into the organization’s management dashboard, allowing staff to view consolidated activity rates across environments without having the ability to modify users or settings environment level these roles govern the "technical" execution within a specific environment (e g , client a production) integration developer grants full access to the low code studio to build, edit, and test workflows this role is typically reserved for development environments and restricted in production implementation specialist designed for the team deploying the software users with this role can update configurations, input credentials, and deploy bundles, but they are technically restricted from altering the underlying workflow logic tier 1 support a read only role that allows staff to view execution logs and data health dashboards to troubleshoot issues, without the ability to modify configurations or code api authentication & token scoping programmatic access to the platform is secured through a hierarchical token system designed to strictly scope api access to specific contexts hierarchical tokens access is not "all or nothing " to perform operations, the api utilizes distinct token types orgauth (organization token) establishes the user's identity within the organization envauth (environment token) to act within a specific customer environment, the system requires an envauth token this token is scoped strictly to that single environment context isolation this architecture ensures that a token generated for a development environment cannot be used to trigger actions or read data in a production environment, nor can a token for client a ever access the resources of client b service authentication for automated backend services, the platform supports orgadminoauth (oauth 2 0 client credentials), allowing trusted systems to perform administrative tasks programmatically under strict governance