You can check every number it gives you

No. Golden uses the semantic models you already have, and works without one. If you use Snowflake Semantic Views or Databricks Metric Views, Golden reads those definitions automatically and queries them directly, so metrics are calculated where your data team defined them, with nothing duplicated or rebuilt.

• Other semantic layers: Golden supports the Open Semantic Interchange (OSI) standard. If your tool can export to OSI, you can import those definitions into Golden.
• Context outside a semantic layer: business knowledge in documents, wikis or websites can be used too.
• No semantic layer at all: Golden can infer semantics from your data to get you started, and you review and refine those definitions as you go.

Either way, the AI doesn't invent SQL. Golden builds queries deterministically, grounded in your data and your semantic definitions. Read more in Semantics are essential. A semantic layer is optional.

Golden sends the AI only the context a feature needs: table and column names, column statistics (min, max, mean, cardinality), small samples of values (typically up to 5 rows, with values truncated), aggregated chart results (up to 50 rows) and your prompt. Features that work on text by design, such as text analytics and AI enrichment, send the values of the specific cells you select for processing. Full tables are never sent. Golden does not train or fine-tune models on customer data. Golden uses several major AI models and picks the right one for each task, so you don't manage model keys.

On Snowflake and Databricks with per-user sign-in (OAuth), the warehouse enforces each person's masking and row policies on every query Golden runs, exports included, and Golden can't get around them. Salary, health or other personal data stays hidden from anyone your warehouse policies hide it from.

Per-user sign-in

• Use per-user sign-in for sensitive data. Each person connects with their own Snowflake or Databricks identity. On Snowflake, their default role, masking policies and row-access policies apply; on Databricks, their group grants and Unity Catalog column masks and row filters apply. Per-user OAuth is the default on Databricks.
• It fails closed. If someone hasn't authorized, the query is refused rather than falling back to a shared credential.
• No elevated roles. Golden never requests an elevated role at sign-in, so each person runs under their default Snowflake role. There's no per-user role picker, so check that default roles (Snowflake) or group grants (Databricks) are set correctly.
• Shared accounts see one view. On a shared Snowflake service account (key pair or PAT) or Databricks service principal, everyone sees what that account sees, so we don't recommend them for sensitive data. On Snowflake, an admin can pin a role on the connection; if that role can't be activated, the query fails instead of quietly using a broader one.

Admins, exports and custom SQL

• Admins can't see masked values. On a per-user connection, the warehouse masks the value before it reaches Golden, so an admin sees only what their own role allows. There's no "log in as user" or impersonation feature, nobody can use another person's warehouse token, and Golden's internal admin console has no access to customer warehouse data.
• Exports don't bypass masking. CSV, Excel and Google Sheets exports, and "view underlying rows," re-run the query live through the same connection and credential as the chart, so the warehouse masks the export the same way. With per-user connections, a person's data also stays out of shared caches, thumbnails and saved column stats.
• Custom SQL stays bounded. People with edit rights on a connection can write their own SQL. On per-user OAuth it's still limited by their own warehouse access; on a shared connection it runs as the service account.

Semantic models and Golden permissions

• Semantic views: Golden queries through Snowflake semantic views, and Snowflake security on the tables underneath still holds. Golden doesn't import or enforce access rules defined inside a semantic model.
• Golden's own controls: Spaces and roles in Golden decide who can reach which dataset and dashboard. Hiding a column in Golden only removes it from field lists; to restrict sensitive columns, use masking policies in your warehouse.

• SOC 2: Golden Analytics is pursuing SOC 2 Type II certification.
• Encryption: credentials, OAuth tokens and warehouse connection settings are encrypted with AES-256 (GCM) inside the application before they're stored, for every warehouse and app connector. All traffic uses HTTPS/TLS, with no unencrypted fallback. Each customer's data is isolated at the database level with row-level security, so one account can never reach another's resources. Secrets are never sent back to the browser: when you edit a connection, passwords, keys and tokens stay hidden. Every request to Golden is verified, and deactivated or deleted users are rejected immediately.
• Private connectivity: Golden supports PrivateLink for Snowflake and Databricks, so traffic between Golden and your warehouse can stay on a private network instead of the public internet.
• Access control: role-based access control, plus Spaces that control who can view or edit shared work.
• Enterprise: granular security controls. Enterprise SSO (SAML/OIDC) and audit logging are on the roadmap.
• Responsible disclosure: report vulnerabilities to security@goldenanalytics.com; see our security policy.

1. Open the chart and inspect the query and calculations behind it.
2. Check the filters and the date range. They're part of the query, so what you see is what ran.
3. Compare one total against a number you already trust, such as a finance report or a warehouse query.
4. Edit anything that's off directly. You don't need to re-prompt.
5. Share once it checks out. Before you share, Golden reviews visualizations for clarity and flags what could mislead.