Looker PII
You manage looker pii by setting field rules in your semantic data model. These rules check user attributes before showing sensitive columns like emails or card numbers. Most data teams start by sharing one database login across the whole analytics app. Then they try to hide private data inside the dashboard views. When roles get too broad, users can still run raw queries and read everything. How native looker pii controls work in the semantic model The platform sits on top of your SQL databa
PII in Logs Prevention: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You manage looker pii by setting field rules in your semantic data model. These rules check user attributes before showing sensitive columns like emails or card numbers. Most data teams start by sharing one database login across the whole analytics app. Then they try to hide private data inside the dashboard views. When roles get too broad, users can still run raw queries and read everything.
How native looker pii controls work in the semantic model
The platform sits on top of your SQL database and generates queries on demand. Data teams write semantic model files that define every table, join, and column. To protect looker pii, engineers tag sensitive fields inside these model definitions. They assign user attributes to each person or group in the company.
When an analyst opens a chart, the app checks their assigned group attribute. If the attribute matches the rule, the app asks the database for that column. If the attribute does not match, the app rewrites the SQL expression. It can return a static string instead of a real phone number or email. Admins can also hide the field from the chart builder menu right away.
Teams also use row filters in the model to limit what records appear. A support manager might only see rows for their own region. All of these checks happen inside the business intelligence tool before the query runs.
Where model rules work and what gaps remain
Native model rules work well for standard business users who view preset dashboards. These users only click through approved charts and cannot write custom SQL statements. For this group, semantic layer rules keep phone numbers and national IDs out of reports.
The gap appears when engineers, data scientists, or developers need deeper permissions. Anyone who uses the built-in SQL runner bypasses the semantic model files. That tool sends raw queries straight to the database using the shared service account. If the service account can read the base tables, the developer can read them too.
PII in Logs Prevention: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Model rules also need constant manual updates across every single project file. When a new table lands in the warehouse, someone must tag every sensitive column. If a developer misses one email field in a new view, it stays exposed. Native setup controls who sees a dashboard widget, not what raw queries return in flight.
Why database role splits add operational toil
To fix the SQL runner gap, teams often split their database service accounts. They create one restricted database role for standard dashboards and another for developers. Some teams also build separate masked views inside the data warehouse itself.
Maintaining two sets of rules across the warehouse and the app takes heavy work. Every schema change requires updates in the database views and the semantic model files. Teams end up managing dozens of roles just to mask card numbers and emails.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does the semantic layer stop SQL runner users from reading sensitive rows?
No, the built-in SQL runner skips the semantic model and queries the database directly. Users with SQL runner permissions can read any table the database login can read.
Which fields should teams treat as sensitive in analytics dashboards?
Teams should protect direct identifiers like emails, phone numbers, card numbers, and national IDs. Masking rewrites matched fields in results so analysts can still group and count rows.
Can user attributes filter both rows and columns in reports?
Yes, admins can link user attributes to both column tags and table filter rules. This setup hides specific fields and limits rows based on the viewer's group.