Security and Access
How Stackless controls user access, dashboard visibility, Agent data access, and safe analytical operations.
Access model
Stackless uses authentication, role-based permissions, dashboard visibility rules, and schema-level data access controls. The Agent follows the same access boundaries as the user who is chatting with it.
[picture 1. Users and Roles settings page with role permissions]
Users and roles
Administrators manage users and roles in Settings. Roles determine which product areas and actions a user can access, such as:
- Agent chat.
- Dashboard read or write.
- Data Catalog read.
- Source read.
- Transformation Model read or write.
- Semantic Model read or write.
- Monitor read.
- User and role administration.
If a user cannot see a page or action, first check the assigned role.
Dashboard access
Published dashboards can be restricted by role. A user may be able to use the Agent while only seeing a subset of dashboards. The Agent should not expose dashboard details that the user cannot access.
Published dashboards should be edited through the fork-and-publish workflow so production reporting is not changed accidentally.
Agent Data Access
Administrators can manage which schemas are available to the Agent in Settings > Agent Data Access.
This matters because the Agent can search the Catalog and run read-only warehouse analysis. Schema access controls keep the Agent from using data that a role should not see.
[picture 2. Agent Data Access settings with schemas assigned to roles]
Source and schema restrictions
When schema restrictions are active:
- Catalog search hides restricted assets.
- Semantic Models created by the Agent must reference a Catalog-visible source asset.
- Inline SQL against restricted schemas is blocked.
- Agent-created models should use catalog-backed tables or Stackless-managed Transformation Models.
Safe query behavior
The Agent's warehouse query path is read-only. It should use safe analytical queries and avoid write operations such as inserts, updates, deletes, grants, or destructive SQL.
For mutating platform actions such as publishing a model, refreshing a managed dataset, or changing a dashboard, Stackless uses explicit tools, permissions, and confirmation flows.
Sensitive data in artifacts
Table artifacts can mark columns as sensitive or masked. Masked values display as hidden unless a user explicitly reveals them in the UI.
When asking the Agent to create a table artifact, tell it if a column should be treated as sensitive:
- "Create a table artifact but mask email addresses."
- "Include customer IDs, but mark them sensitive."
- "Do not include direct contact information."
Shared conversations
Conversations can be shared read-only. A recipient may duplicate a shared conversation to create their own editable copy.
When a conversation contains artifacts or dashboards, access still depends on the recipient's permissions and artifact visibility. Do not use conversation sharing to bypass dashboard or data access rules.
Practical checklist
If access does not look right:
- Confirm the user can sign in.
- Check the assigned role.
- Check dashboard visibility.
- Check Agent Data Access schema settings.
- Check whether the asset is published or only a private draft.
- Ask the Agent to explain what it can see, then compare with the user's expected access.