Databricks shipped agent-aware ABAC masking on 21 August 2026 with 3 gaps

Summary. Databricks put context attributes for Unity Catalog attribute-based access control into Beta on 21 August 2026. Two new functions, has_context_attribute and has_context_attribute_value, let a policy mask a column or filter rows when a request arrives through an OAuth application acting on a user's behalf, while the same user querying directly sees everything. That is a genuine control for AI agent access, and Databricks' own documentation names three paths it does not cover: a personal access token never sets the attribute, Genie is explicitly excluded, and the built-in databricks-cli client shares one client ID with every human using the CLI. The quota ceiling is 10,000 policies per metastore and 50 per table, and any standard or dedicated compute below Databricks Runtime 16.4 cannot read an ABAC-protected table at all. The limitations page that ought to bound all of this was last updated on 17 August 2026, four days before the feature shipped, and the page comparing ABAC with table-level filters has not moved since 22 June 2026.

What shipped on 21 August 2026

The Databricks August 2026 release notes describe the change in four sentences. Policy conditions can now target the context of a request, specifically which OAuth application is calling and whether the request runs on behalf of a user. The stated use is to restrict what an agent reads on a user's behalf while the user keeps full access when querying directly in the workspace.

Two attributes carry that context. request.is_on_behalf_of returns the string 'true' or 'false'. request.client_id returns the OAuth client ID of the calling application, readable on the App connections page in the account console, on a Databricks App's authorization details page, or from the identity_metadata.acting_resource field in the audit logs.

Two functions read them. has_context_attribute('key') tests presence and has_context_attribute_value('key', 'value') tests a value. Both are listed for the WHEN clause of column mask and row filter policies. Attribute keys are case-insensitive; values are case-sensitive, which is a detail worth catching in review, because a policy testing 'True' instead of 'true' fails open and masks nothing.

The feature is Beta and gated. An account admin has to enable the UC ABAC Context Attributes preview from the account console Previews page before any of this evaluates.

The three paths the control does not cover

This is the part the release note does not carry, and it is all in the same documentation set.

Databricks states plainly that access authenticated with a personal access token does not set request.is_on_behalf_of, and that Genie access cannot be captured through this mechanism because it does not set the attribute to 'true'. The core concepts page puts it in one line: these attributes can be used to identify external agents, not Genie agents.

The documentation carries its own warning about the consequence. If a policy restricts access based on request.is_on_behalf_of, an agent that can authenticate with a personal access token walks straight past it. If a policy restricts on request.client_id, an agent that can reach the generic databricks-cli client is outside the condition. The control is only as strong as the authentication paths you have closed off around it, which makes token governance the actual prerequisite rather than a follow-up task.

The inverse failure is quieter and will hit first. Any OAuth-authenticated access sets request.is_on_behalf_of to 'true', including the Databricks CLI, the SDKs and the SQL Statement Execution API used by a human. A policy written to mask a column for agents also masks it for the analyst running a query from their laptop through the CLI. Only a personal access token avoids the attribute, so the practical effect of a naive on-behalf-of policy is to push analysts back onto long-lived tokens, which is the opposite of what a governance team wants.

To govern one application rather than a category, Databricks requires you to register a custom OAuth application in the account console, note its client ID, and connect the agent to the Databricks managed MCP through it. That is three admin steps before the first policy can be written, and two of them need account-level rather than workspace-level rights.

Where context attributes sit against identity attributes

Both attribute families are in Beta, both need a separate account preview enabled, and they do not have the same reach.

Row filtering is the meaningful difference. Identity attribute functions are documented only for the WHEN clause of column mask policies, so a rule such as "this agent sees only rows for its own region" was not expressible through identity attributes. Context attributes are listed for row filter WHEN clauses as well, which is what makes agent-scoped row filtering possible at all.

The gap in that table is the requirements page. Databricks' requirements, quotas and limitations page was last updated on 17 August 2026, four days before context attributes shipped, and its limitations section still discusses identity attribute functions only. The best practices page carries the same 17 August date and the comparison page between ABAC and table-level filters has not been touched since 22 June 2026. A team reading the limitations page today will not find a single sentence about the feature it needs bounded.

The limits that will actually bite

The 20-principal ceiling is the one that shapes design. Because TO and EXCEPT share it, an exemption list built from named service principals runs out quickly, and Databricks' best-practice guidance is to target groups rather than individual principals for exactly that reason.

Three older behaviours also survive into this release and matter more once agents are in the picture. Standard and dedicated compute on runtimes earlier than 16.4 cannot access ABAC-secured tables at all, so protecting a table can break an unrelated legacy job. Time travel queries fail on tables with active row filters or column masks, and deep and shallow clones are unsupported, with an exempted service principal in the EXCEPT clause as the documented workaround. And when a pipeline refreshes a materialized view or streaming table, policies evaluate against the pipeline owner or run-as identity, so if that identity is subject to a policy the materialized view permanently contains masked or filtered data. That last one is not recoverable by changing the policy afterwards; the masked values are what got written.

Who is affected, and how to tell

You are in scope if an agent, a Databricks App, or any MCP client reads Unity Catalog tables using a user's identity rather than a dedicated service principal with its own narrow grants. That pattern is now common wherever a chat interface is wired to a warehouse, and it is the pattern this feature exists to constrain.

Start in the audit logs. Query identity_metadata.acting_resource to enumerate which applications have been reading which tables, which also gives you the client IDs you will need for any request.client_id condition. Then inventory authentication: list the personal access tokens that can reach the catalogs you plan to protect, because every one of them is a bypass of an on-behalf-of policy. Check compute last. Any standard or dedicated cluster still on a runtime below 16.4 will lose access to a protected table rather than see masked data.

If the answer to all three is uncomfortable, the sequencing matters more than the policy syntax. Token cleanup first, custom OAuth application registration second, policy third. Writing the policy first produces a control that reports as enforced and is not.

The pattern here is familiar from other agent controls: the enforcement point is precise, and the perimeter around it is where the work is. It is the same shape as the allowlist problem in enterprise AI agent governance layers, and the same reason prompt injection guardrails fail when a second, unguarded tool path exists.

India-specific considerations

For Indian teams operating under the Digital Personal Data Protection Act 2023, the appeal of this feature is obvious: it lets a data fiduciary show that personal data was masked for automated processing while remaining available to the human who is accountable for it. The caveat is that the evidence has to cover the bypasses. A DPDP file that documents a column mask policy without documenting the personal access tokens that skip it is describing a control that was not actually in force.

Two practical notes. Governed tags, which every ABAC policy depends on, are account-level objects with their own permissions, so tag governance is where an Indian entity's data classification work has to land before any masking policy is meaningful. And because policy changes and tag changes are both captured in the audit log system table, that table, not a screenshot of Catalog Explorer, is the artefact worth retaining. Our AI agent security guardrails work usually starts by reconciling those two records against each other.

What is still unknown

Databricks has not published a general availability date for context attributes, and Beta features carry no forward compatibility promise. The requirements and limitations page does not yet state whether context attribute functions are supported in MATCH COLUMNS or in GRANT and DENY policies; the core concepts table lists only column mask and row filter WHEN clauses, which is suggestive but not a stated restriction. Nothing published says whether Genie will gain a context attribute of its own, which leaves Databricks' own analytics agent as the notable exclusion from an agent access control. Teams choosing between this and a protocol-level control should read the trade-offs in an enterprise agent protocol decision alongside the policy design, and treat both as partial until the perimeter is closed. Broader patterns for putting agents into production are covered in our guide to enterprise AI agents in production.

FAQ

How eCorpIT can help

Agent access to a warehouse usually breaks at the perimeter rather than at the policy, and that is the part teams tend to inventory last. We map which applications, tokens and clients can currently reach a catalog, close the paths a context-attribute policy cannot see, then write and test the policies against real audit-log evidence rather than a design document. eCorpIT is ISO 27001:2022 certified and designs applications aligned with DPDP requirements. If agents are already querying your Unity Catalog tables, request an agent data-access review and we will start with the audit log.

References

1. Databricks platform release notes, August 2026

1. Attribute-based access control in Unity Catalog, Databricks

1. Core concepts for attribute-based access control, Databricks

1. Common patterns for row filtering and column masking, Databricks

1. Requirements, quotas, and limitations for row filter and column mask policies, Databricks

1. Create and manage row filter and column mask policies, Databricks

1. Row filter and column mask policy evaluation and runtime behavior, Databricks

1. Performance considerations for row filter and column mask policies, Databricks

1. Best practices for ABAC policies, Databricks

1. When to use ABAC vs table-level row filters and column masks, Databricks

1. ABAC GRANT policies (Beta), Databricks

1. Manage Databricks previews

Last updated: 23 August 2026.