Eight layers, one decision
Roles, groups, permissions, tag views, and AI policy resolve into a single answer for every request, whether it arrives from the UI, REST, the CLI, or an AI agent.
Most data integration tools give you roles and call it a security model. Roles answer "what kind of user is this" and nothing about which flows this person sees, whether they can run but not edit, or whether they may point an AI agent at production.
Version 9.7.10 introduced a layered model that answers those separately, then resolves them into one decision.
The layers
Eight of them, broadest to narrowest, each defined independently: environment and license, tenant, role, user groups, applications, operational permissions, artifact access, and AI and API-key policy.
Role is always the ceiling. Groups, permissions, applications, tag views, and tenant restrictions can only narrow what a role allows.
One layer behaves differently from the rest. Applications is enforced in the UI only. Hiding the Agents application from someone's navigation does not stop them reaching it through REST, the CLI, agentic AI, or MCP. Blocking that takes an operational permission or a tenant application restriction. The documentation says so plainly, because "I hid it from the menu" is how incidents get written up.
How a decision resolves
Hard ceilings first: environment, license, tenant enablement and assignment, tenant application availability, tenant AI disablement. Any of these blocks the action and nothing below matters.
Then role, which sets the maximum. Then an explicit user permission, where a Deny always denies and an Allow can create a deliberate exception to a group Deny inside the role ceiling. Then groups, where a Deny beats another group's Allow. If nothing above decided, the role's existing behavior applies unchanged.
An empty permissions matrix therefore changes nothing. You can switch the system on, have every user behave exactly as before, and add rules one at a time.
When a result surprises you, the Effective access report names the rule that produced it. Administrators also get View as user, which renders the UI as that person sees it.
Rolling it out safely
Artifact permissions have three enforcement modes: enforce, shadow, and off.
Shadow mode is the one to plan around. It evaluates every artifact check and records what would have happened, denying nothing. Point it at a week of real traffic, find the service accounts nobody remembered, fix the model, switch to enforce.
Every organization that rolls out fine-grained permissions breaks a scheduled job doing it. Shadow mode moves that discovery into working hours.
Artifact access, no folder tree
Which flows a person sees is controlled with Tags and a Tag View, our tag-based artifact view, rather than a directory hierarchy. A Tag View defines a set of artifacts by tag; you grant a user or group visibility to it. Several combine as a union, and you can exclude someone explicitly.
Two behaviors surface immediately. Access is a closed group scope, so membership does not leak sideways. And there is no transitive dependency access: seeing a flow grants nothing on the connections and formats it references.
The AI layer
Three AI capabilities are configured independently, and none is the Etlworks authentication API key. Confusing those two is the most common mistake we see.
The personal OpenAI API key is the user's own credential for their usage, and a group never stores one. Agentic AI controls whether the user can invoke actions from Simba, our AI agent. AI transcript access controls who reads AI conversations, does not inherit from groups, and stays with the root account owner, because transcripts contain whatever anyone typed.
Tenant AI disablement is a hard ceiling. Turn AI off for a tenant and nothing runs for anyone in it.
The part most vendors skip
Authentication method does not bypass authorization. UI, REST, the CLI, agentic AI, and MCP all resolve the same user, role, tenant context, permissions, and artifact policy. A user denied Run/Use cannot run a flow from the CLI. A user denied Edit cannot update it with a direct API call. An API key authenticates a user; it does not create a second identity with its own rules.
That is why we let an agent create and modify every artifact type. The blast radius of the agent is the blast radius of the person driving it.
Full guide, including 24 worked recipes: Configure Access and Permissions.