Your data-agent security review needs two maps—not one

Enterprise data agents increasingly expose useful controls in prompts, Git, workspace sharing and notebook settings. The recurring mistake is to read those controls as the security boundary. Across current documentation from Databricks, Microsoft Fabric and Google Cloud, the safer model is to maintain two separate maps: one for assistant behavior and configuration, and another for enforced authorization and data movement.

Personalization is not permission

Databricks’ October 15 release notes say Genie One can use a person’s group memberships to tailor responses through workspace instructions and table descriptions. That can change terminology, defaults or the context shown to different audiences. Databricks’ account-only access guide separately says Unity Catalog privileges determine which data those users can access, with workspace bindings adding another boundary for workspace-bound data. Group-aware prose belongs on the behavior map; Unity Catalog grants and bindings belong on the authorization map.

Microsoft documents a similar separation for Fabric data agents. A user can query a Power BI semantic model through an agent with Read permission alone, without Build permission or membership in the model’s workspace. Row- and column-level security still apply. An access review based only on workspace membership therefore misses direct item-level readers who can receive answers through the agent.

Version control is not field-level enforcement

Fabric’s source-control format gives reviewers a strong configuration record: agent instructions, data-source instructions, few-shot examples and schema selections can all appear in Git. But Microsoft says column-level selection is not supported even though serialized column entries contain is_selected. Once a table is selected, all its columns are included regardless of those column flags. The Git diff is evidence of intent; curated views, semantic models and source permissions enforce the sensitive-field boundary.

Remote execution is not a data-residency guarantee

Google Cloud’s Data Agent Kit makes the same distinction in a different layer. Its remote Spark kernel runs notebook code entirely on Managed Service for Apache Spark, with no local execution. The transformation documentation also permits small results to be exported to Arrow or Pandas for local work. Kernel placement and result destination are therefore separate controls: “runs remotely” does not by itself mean “results cannot move locally.”

Build the review around both maps

A practical deployment review should pair every friendly product control with the mechanism that actually enforces it:

• group-aware instructions with catalog grants and workspace bindings;
• agent sharing with source-level Read, SELECT, row and column policies;
• Git-visible schema scope with curated tables or views;
• remote kernels with explicit export and approved-destination policy.

The pattern is not that product configuration is cosmetic. It is operationally valuable because it makes behavior reviewable and repeatable. The risk appears when teams ask it to do a second job that the underlying platform reserves for IAM, catalog policy, source permissions or output controls. Two maps make that distinction visible before an access review approves the wrong boundary.