Looker Masking
You set up looker masking by tying user attributes to conditional rules in your model. When a user runs a report, the tool rewrites sensitive columns based on their role. Data teams use this method to hide emails and phone numbers from general staff. Still, broad permissions or shared accounts can still expose raw values to the wrong people. How looker masking works in the semantic layer Looker does not store your business data inside its own servers. Instead, it sits on top of your data ware
Data Masking (Static): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up looker masking by tying user attributes to conditional rules in your model. When a user runs a report, the tool rewrites sensitive columns based on their role. Data teams use this method to hide emails and phone numbers from general staff. Still, broad permissions or shared accounts can still expose raw values to the wrong people.
How looker masking works in the semantic layer
Looker does not store your business data inside its own servers. Instead, it sits on top of your data warehouse and builds queries on the fly. You define your tables, joins, and fields inside a central modeling layer. To mask a field, developers write a conditional rule inside that field definition.
First, an admin creates a user attribute that holds a role or clearance level. Next, the admin assigns specific values for this attribute to different user groups. For example, finance staff get a high clearance value while contractors get a default value. Then, the developer updates the dimension in the model to check this attribute at runtime.
When someone opens a dashboard, the platform reads their attribute value and writes the query. If the user lacks clearance, the generated query replaces card numbers with a fixed string. If the user has clearance, the query pulls the real column from the database. Masking rewrites matched fields in results before the browser renders the chart.
Some teams also push this logic down into the database itself. In that setup, the reporting tool passes the user identity into the warehouse session. The database then applies its own column rules based on that session variable. Both methods rely on keeping user attributes and group mappings accurate over time.
What native model rules solve and what they miss
Native model rules solve the problem of sharing one dashboard across many departments. You do not need to build separate reports for support agents and executives. One chart can serve both groups while rewriting national IDs for unauthorized viewers. This cuts down on duplicate views and keeps chart logic in one place.
Still, model rules only work inside the standard reporting views. They decide how the semantic layer builds a query for a saved explore. They do not inspect what individual SQL statements do in flight outside that model. Many platforms include a built-in SQL runner for analysts and developers.
Data Masking (Static): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
If an analyst opens that runner, they bypass the semantic layer and its field rules. The database sees the single service account that the reporting tool uses to log in. Because the service account needs full read rights, the raw query returns unmasked phone numbers. The same gap appears when engineers query the warehouse from local scripts or notebooks.
Maintaining conditional logic across hundreds of dimensions also creates heavy work for data teams. Every new table requires manual updates to the model files before anyone can use it. If a developer forgets to add the rule to a new view, raw emails leak. Relying on model files alone leaves direct database queries and ad-hoc tools unguarded.
Why service accounts complicate data privacy
Most business intelligence tools talk to the database through one shared login key. This single database user must read every table that any dashboard might need. As a result, the database cannot tell which human actually clicked the run button. It only sees the shared service role asking for rows of data.
When you rely on app-level rules, you trust the app to filter every request. This works for locked dashboards, but it breaks down during data exploration and debugging. Admins often grant SQL runner access so analysts can test new metrics or fix broken joins. Once a user has that permission, app-level field rules no longer apply to their queries.
True protection requires checking the query result right before it reaches the user or app. When rules apply at the wire level, it does not matter which tool sends the query. Both dashboard loads and raw SQL runner tests get the exact same field rewrites. Teams can then let analysts explore tables without risking bulk exposure of card numbers.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Does looker masking protect queries run in the SQL runner?
No, semantic layer rules only apply to explores, looks, and dashboards built on the model. Queries in the SQL runner go straight to the database using the shared connection role.
Which fields should teams mask in their reporting views?
Teams typically mask high-risk identifiers like emails, phone numbers, card numbers, and national IDs. Masking rewrites matched fields in results while leaving aggregate counts and dates intact for analysis.
Can users bypass attribute-based masking through filters or exports?
If you only mask the display format, users can still guess values using filter conditions. To stop this, you must write the conditional rule directly into the underlying SQL definition.