In Looker, how do access_filter and user attributes limit rows an explore returns?

## The three pieces Row restriction in Looker is assembled from three separate things, and candidates usually know one of them. **User attributes** are key-value pairs Looker stores per user, defaulted per group, and optionally populated from SSO/SAML at login. `region = "EMEA"`, `brand_id = "7"`. They are just values; on their own they restrict nothing. **`access_filter`** is a parameter on an explore that binds a field to one of those attributes: ``` explore: orders { access_filter: { field: users.region user_attribute: region } } ``` Every query generated from this explore — ad-hoc, saved Look, dashboard tile, schedule — gets a filter on `users.region` derived from the requesting user's attribute value. It is not visible as a removable filter in the UI, and scheduled deliveries run under the identity that owns the schedule. **`sql_always_where:`** is the unconditioned sibling: a raw SQL predicate appended to every query from the explore, e.g. `sql_always_where: ${orders.is_test} = false ;;`. It does not vary per user, and unlike a normal filter it cannot be seen or removed by the user. Related parameters `always_filter:` and `conditionally_filter:` set defaults a user *can* change, which makes them performance guardrails rather than security controls — do not confuse the two groups. ## Field-level restriction Rows are not the only thing worth hiding. `access_grant` declares a named grant tied to an attribute and its allowed values; fields, explores or joins then list `required_access_grants:`: ``` access_grant: can_view_pii { user_attribute: pii_access allowed_values: ["yes"] } dimension: email { sql: ${TABLE}.email ;; required_access_grants: [can_view_pii] } ``` Users without the grant do not see the field at all — it is absent from the field picker, and content referencing it errors rather than leaking. ## Where it breaks This is where senior answers separate themselves. **It is model-layer, not database-layer.** The filter is added when Looker composes SQL. Anyone who can issue SQL against the same connection outside the model bypasses it — most obviously SQL Runner, and equally a developer who can edit LookML to delete the `access_filter`. If your threat model includes those users, enforcement has to be in the database (per-user credentials, database row-level security, or a separate connection), not in LookML. **Persisted derived tables contain everything.** A PDT is built once, by Looker, and stored in a scratch schema on the connection. It is not built per user, so a PDT built from a restricted explore still materializes every row. The `access_filter` applies to the query *against* the PDT, which is usually fine — but it means the sensitive rows exist in a table other people may be able to read, and it means you cannot use persistence to "pre-filter" for a user. **An empty or missing attribute value is a policy decision.** Do not assume a user with no value set gets everything or gets nothing — verify the behaviour in your Looker version and set an explicit default that fails closed. This detail has shifted across versions and is exactly the kind of thing to test rather than recall. **Multi-value attributes.** Attributes can hold comma-separated lists for a user who legitimately spans several regions, and the filter honours Looker's filter syntax — including negation and wildcards typed into the attribute value. That is powerful and also a foot-gun: an attribute populated from an upstream system with unescaped input is an injection surface into the filter expression. Constrain the values you write. **Joins matter.** The filter applies to the named field, which lives in a view that must be joined into the query. If a user selects only fields from an unrelated view, Looker still adds the join needed to enforce the filter — which can change fan-out behaviour and cost. Check the generated SQL when you add an access filter to a wide explore. ## Testing it Looker lets an admin impersonate another user, which is the practical way to verify: sudo as a user in each group, run the explore, read the generated SQL, and confirm the WHERE clause carries the expected value. Do this for the empty-attribute case too. Reviewing the SQL is the only way to be sure the filter reached the query rather than being dropped by a join path or an override.