Roles and permissions

This document answers common questions about the roles Atlan creates or requires in Snowflake, why elevated permissions such as dq_admin are necessary, and how Snowflake’s built-in controls keep your data safe.

Why does the dq_admin role need table owner privileges?

Snowflake's security model maintains strict control over data metric functions (DMFs) used for data quality checks. According to Snowflake's documentation, only table owners can schedule and manage these functions on their tables.

The dq_admin role is granted these elevated permissions solely to enable data quality operations on your designated tables. This carefully designed architecture ensures that while the role has the necessary privileges to manage data quality checks, it operates within strict security boundaries that protect your data.

How does Atlan's security architecture protect my data when using the dq_admin role?

Atlan is never granted direct access to the dq_admin role or ownership of any tables. Instead, the security architecture works through controlled indirection:

Access control through stored procedure
Atlan can only access the dq_admin role indirectly through a secure stored procedure called MANAGE_DMF. This procedure:

• Exposes only limited, predefined data quality operations necessary for data quality execution—nothing more
• Executes all operations strictly within Snowflake's secure execution context
• Ensures that privileges can't be misused or escalated

Security boundaries remain intact
This architecture ensures that:

• Atlan can't assume the dq_admin role directly
• Atlan can't perform arbitrary actions with elevated privileges
• All elevated permissions remain strictly controlled within Snowflake
• Your existing data governance and access boundaries stay fully protected

This security-first design enables Atlan to orchestrate data quality workflows without compromising your control, visibility, or trust in your data platform