Row filtering and column masking are query-time data security controls that govern access within a table. Row filters restrict which records a person or workload can retrieve, while column masks transform sensitive values according to identity or attributes. Together, they provide finer-grained protection than table-level permissions without changing the underlying stored data.
These controls matter when people, applications, and AI agents need different views of the same dataset. They reduce reliance on separate tables, application-specific filters, and users remembering to constrain every query correctly. The video above walks through the core ideas.
What is the difference between row filtering and column masking?
Row filtering controls which records a requester can see, while column masking controls how particular field values appear. Both operate within a table and can adapt the result according to the identity or attributes of the requester.
Traditional table-level access is binary: a person can query the table or cannot. That works when everyone authorized for a table may see all its contents, but it cannot represent common distinctions within customer, financial, operational, or workforce data.
A customer table, for example, might support several access patterns:
- A global administrator can retrieve every customer record.
- A regional employee can retrieve only customers assigned to that region.
- A support user can retrieve relevant records but see masked account numbers.
- A highly authorized user can receive the original sensitive values.
Row filters and column masks create these different views at query time. They do not require duplicating the underlying data for each audience, and they are complementary rather than competing controls.
How does row-level filtering work?
Row-level filtering automatically adds a policy predicate to queries based on the requester’s identity, role, region, tenant, or other approved attributes. The requester submits a normal query but receives only authorized records.
For example, a sales representative might query a shared customer table without writing a territory condition. The data access layer evaluates the representative’s identity and applies the assigned-territory restriction automatically. The filter is effectively invisible to the user, but it remains part of the enforced query path.
This is safer than relying on every report, application, or agent to include the correct WHERE clause. A centrally enforced policy also helps keep direct SQL, business intelligence tools, and application requests consistent when they use the same governed access point.
Row policies should be explicit, testable, and tied to trustworthy identity attributes. Teams also need defined behavior for missing or conflicting attributes, usually denying access rather than broadening it unintentionally. This approach is closely related to attribute-based access control for data, where policy decisions use contextual attributes instead of roles alone.
How does dynamic column masking protect sensitive values?
Dynamic column masking transforms selected values before returning query results to a requester who lacks full clearance. An authorized requester can receive the original value, while another requester receives a redacted, partial, tokenized, or otherwise masked representation.
An account number might appear in full to an approved finance workflow and as only its final characters to a support user. The stored value does not change; the transformation affects what the query returns according to policy.
Masking differs from removing an entire column because it can preserve enough structure for an authorized task without disclosing the complete value. It also differs from encryption at rest, which protects stored media but does not determine what an authenticated query may reveal after decryption.
To remain effective, masking must be enforced at shared data access points rather than only in a reporting interface. Otherwise, a user could bypass the presentation layer and request the raw field through another tool. Masking should sit within a broader AI data governance program that covers classification, identity, policy, audit, and approved uses.
How should row and column policies apply to AI agents?
AI agents should receive data according to the effective permissions of the person or workload they represent, not simply the broad permissions of a shared agent service account. The same row filters and column masks should apply whether access comes from a person, application, agent, or direct query tool.
This requires an identity-aware request path. The system authenticates the requester, carries scoped user or workload identity into the data request, evaluates policy, and enforces the resulting filters and masks where the query reaches the data.
That distinction is critical because an agent may have system-level connectivity to several datasets while acting for users with very different permissions. Connectivity should not become authorization. A regional employee’s agent should not retrieve global customer records merely because the agent runtime can reach the customer table.
Enforcement should also produce logs that connect the request, represented identity, policy decision, and accessed resource. These records help teams investigate unexpected results and demonstrate that an agent did not bypass the reporting or application layer. For consequential operations, data access controls should work alongside tool permissions and human approval requirements.
Key takeaways
- Table-level permissions cannot express different record and field visibility within the same table.
- Row filtering automatically limits query results according to identity or approved attributes.
- Column masking changes returned sensitive values without modifying the underlying stored data.
- Shared query-time enforcement keeps policies consistent across applications, direct queries, and agents.
- AI agents should inherit scoped authorization from the people or workloads they represent.
How Hyperlake helps
Hyperlake supports governed access through OAuth/OIDC sign-in, validated JWT identity, OPA policy decisions, and enforcement and logging at integrated access points. Teams can assemble data services, models, applications, policies, secrets, and monitoring in infrastructure they or their clients control, with specific behavior depending on the selected engines and deployment. To discuss an identity-to-data architecture for users and agents, talk to our team.
Frequently asked questions
Can row filtering replace separate tables for each region or tenant?
Row filtering can reduce the need to duplicate a shared table solely to provide different record views. A policy can restrict results by region, tenant, business unit, or another trusted attribute. Separate storage may still be appropriate when legal, residency, operational, or isolation requirements demand a stronger boundary than query-time filtering.
Is column masking the same as encrypting a sensitive column?
No. Encryption protects data by making it unreadable without the required key, including while stored or transmitted depending on the encryption method. Dynamic masking assumes the query system can process the value, then changes what it returns according to the requester’s authorization; many systems use both controls together.
Do filters and masks still apply when someone uses direct SQL?
They do when policy enforcement is attached to the shared query or data access layer used by direct SQL and other clients. If controls exist only inside a dashboard or application, another access path may bypass them. Teams should identify every route to the data and ensure each route reaches an equivalent enforcement point.
Should an AI agent connect with a shared database account?
A shared account makes it difficult to apply each user’s permissions and attribute-based policies accurately. A stronger design carries scoped user or workload identity into the request so the data layer can evaluate the appropriate row filters and column masks. The agent’s technical ability to reach a dataset should not grant every represented user access to all of it.
