Security and Access

Access model

Every Stackless workspace is isolated: its own application, sign-in, warehouse, and settings. Within a workspace, access is controlled by roles. A user's access is the combination of all their roles, and the Agent, Monitors, and MCP clients act with the access of the user they work for.

Three things decide what a user can do:

1. Permissions on their roles decide which areas and actions are available, such as using the Agent, editing dashboards, or publishing models.
2. Schema Access on their roles decides which warehouse data they and the Agent can see.
3. Dashboard Access on their roles decides which published dashboards they can see.

Administrators manage all three in Settings > Users & Roles. See Administration for the steps and the full permission reference.

Data access

Warehouse visibility works in two layers:

1. Workspace inventory. In Settings > Agent Data Access, administrators choose which schemas Stackless indexes at all. Only enabled schemas appear in the Catalog or can be queried.
2. Role assignment. On each role, Schema Access either grants Unrestricted catalog access to every enabled schema, or assigns specific schemas.

Access is deny-by-default: a user whose roles assign no schemas and grant no unrestricted access sees no warehouse data. Administrators see all enabled schemas.

When schema restrictions apply:

• The Catalog hides assets in schemas the user cannot read.
• The Agent cannot query them, and its queries return an access error instead of data.
• Semantic Models can only be built on tables the author can access.
• Monitors run with their owner's access, so they can only read what the owner can read.

Dashboard access

• Private dashboards are visible only to their owner and the people they are privately shared with.
• Published dashboards are visible to the roles they are assigned to under Dashboard Access, and to administrators.
• A published dashboard assigned to no role is hidden from everyone except administrators.
• Publishing grants the publisher's own role automatically when the publisher is not an administrator. Publishing a replacement keeps the existing role assignments.

The Agent will not reveal details of dashboards the user cannot see.

Safe changes

• Read-only queries. The Agent's warehouse queries are restricted to SELECT and WITH statements, one statement at a time, returning at most 500 rows. Writes, multiple statements, and schemas outside the user's access are rejected before they run.
• Explicit publishing. Publishing a Transformation Model or Semantic Model requires typing the exact confirmation phrase from the publish review. Publishing a dashboard requires confirming the publish dialog, and a second confirmation when it affects live dashboards.
• Drafts first. New models and dashboards start as private drafts. Published dashboards are changed through a replacement fork, never in place.
• Approvals for outside actions. Source schema changes and support ticket updates are shown for approval before they are applied.
• No secrets in chat. Connector credentials are entered on the secure setup page, and Monitor webhooks are configured in the Monitor editor, not in a conversation.

Sensitive data in artifacts

Table artifacts can mark columns as sensitive. Sensitive values are masked on screen, and anyone viewing the artifact can reveal them with the eye icon. Masking prevents casual exposure in screenshots and screen shares; it does not restrict access. To keep data from a user, restrict it with Schema Access instead.

When asking for a table artifact, say which columns are sensitive:

• "Create a table artifact but mask email addresses."
• "Do not include direct contact information."

Shared conversations

Conversation owners can share a conversation read-only, and recipients can duplicate it. Sharing does not grant access: recipients still see only the data, artifacts, and dashboards their roles allow.

MCP connections

AI clients connected through the MCP server act as the user who authorized them, with the same permissions. Signing out of Stackless revokes your MCP sessions, and removing a user's role or deleting the user revokes theirs.

Practical checklist

If a user's access does not look right:

1. Confirm they can sign in and have the expected roles in Settings > Users & Roles.
2. Check the role's permissions for the area they are trying to use.
3. Check the role's Schema Access: unrestricted, or the needed schemas assigned.
4. Check that those schemas are enabled in Settings > Agent Data Access, and that Apply Changes was run after enabling them.
5. For a dashboard, check that it is published and assigned to one of their roles under Dashboard Access.
6. Ask the Agent, signed in as that user, "What data can you see?" and compare with what they expect.