How FGAC Works: The Policy Evaluation Flow

From User to Data and Back: Fine grained access control spans the entire request path. Understanding this flow is critical because policies must be enforced consistently across interactive queries, batch jobs, and even vector embeddings for generative AI applications. The journey starts with authentication. A user logs into a business intelligence tool like Looker. Authentication against an identity provider produces a token carrying not just user ID, but also attributes: team membership, regional scope, clearance level. For example, owns_customers_in_region=EU or clearance=finance_only. The Permission Table Pattern: Many implementations use a permission table to avoid massive OR predicates. Instead of generating WHERE customer_id IN (1, 2, 3...1000000), the engine joins with a small table mapping users to allowed rows. This permission table typically has millions of rows versus billions in fact tables, stays highly cached in memory, and gets updated by identity provisioning systems. The critical design goal is keeping policy evaluation cost under 1 millisecond so that latency remains dominated by actual data processing, not by security checks. At scale with 200,000 interactive queries daily, you cannot afford 10 milliseconds of policy overhead per query without violating Service Level Objectives (SLOs).