Fabric adoption often begins with ingestion, lakehouses, Power BI reports, and executive dashboards. Security tends to arrive later, when more teams ask for access and the platform owner realises that workspace permissions alone are not enough. That sequence is risky. Once sensitive data is already copied, modelled, and consumed by many reports, retrofitting governance becomes difficult.

OneLake security becoming generally available is important because it pushes Fabric closer to an enterprise-grade security model. Row-level and column-level controls at the data layer make it easier to expose shared data products without giving every consumer the same broad access. That matters even more now that data agents and AI workflows can sit on top of Fabric.

The main point for architects is simple: do not design Fabric security only for human report readers. Design it for analysts, engineers, applications, notebooks, semantic models, and AI agents from the beginning.

Why workspace permissions are not enough

Workspace-level access is useful for collaboration, but it is too coarse for many enterprise data domains. A finance workspace may contain revenue, margin, payroll allocation, customer credit terms, and forecast data. A sales manager may need customer revenue for her region, but not payroll data. A data scientist may need aggregated patterns, but not personally identifiable customer details. An agent may need to answer questions about trends, but not reveal confidential rows to a user who is not allowed to see them.

If the only control is workspace membership, platform teams often respond by creating many duplicated workspaces and datasets. That fragments ownership and creates inconsistent definitions. Fine-grained controls are a better answer.

A mature model combines several layers:

Tenant and capacity controls
    -> domain workspaces
        -> lakehouse / warehouse permissions
            -> OneLake roles
                -> row-level and column-level policies
                    -> semantic model security
                        -> application or agent access controls

No single layer is enough. The goal is defence in depth.

Row-level and column-level thinking

Row-level security answers: which records can this identity see? Examples include region, business unit, legal entity, customer portfolio, project, or data residency boundary.

Column-level security answers: which attributes can this identity see? Examples include salary, national ID, email address, margin, bank account, medical notes, or contract pricing.

Object-level controls answer: which tables, files, folders, or data products can this identity use at all?

These controls should map to business policy, not only technical convenience. If the business cannot explain who should see a field and why, the platform team cannot reliably secure it.

Reference design for Fabric domains

For Malaysian enterprises, I normally recommend a domain-oriented pattern. Each major domain has a clear workspace boundary, data owner, classification, and consumption model.

Fabric Domain: Customer
- Raw/source-aligned zone: restricted to data engineering
- Curated data product: governed access for analytics
- Semantic model: approved business metrics
- Agent-safe view: reduced fields, evidence references, policy checks

The raw zone should be tightly restricted. Most users and agents should not need it. The curated zone should expose business-ready tables with consistent naming, data quality checks, and documented ownership. The semantic model should define metrics. Agent-safe views should remove unnecessary sensitive columns and include only the data needed for the use case.

This pattern reduces two common risks: analysts accidentally using raw data, and agents being granted broad access because nobody built a safer surface.

Agent-safe access is different

AI agents change the security discussion. A human analyst usually asks for access to a dataset or report. An agent may receive a natural-language question, decide which tool to call, query data, summarise results, and possibly trigger an action. That creates a wider path for accidental disclosure.

A user should not be able to bypass permissions by asking an agent. If the user cannot see customer margin in a report, the agent should not reveal it in a generated answer. This means agent access must consider both the agent identity and the end-user identity.

A safer pattern is:

User
  -> Agent Gateway
      -> user identity and policy check
      -> approved Fabric tool
          -> agent-safe view / semantic model
              -> answer with source references

Do not give the agent a superuser identity and rely on prompt instructions to hide data. Prompts are not access controls. Use Entra ID, Fabric permissions, data-layer policies, logging, and approval gates.

Practical design steps

Start with classification. Identify confidential, regulated, personal, commercial, and public fields. Do this before broad onboarding. Sensitive data that is not identified cannot be protected consistently.

Next, define access personas. For example: data engineer, domain analyst, executive reader, regional manager, external auditor, data scientist, application service, and AI agent. Each persona needs a clear reason to access each data product.

Then build policy tables or attributes for row-level filtering. Common examples include region, branch, department, tenant, legal entity, and customer ownership. Avoid hardcoding security filters in many reports. Centralise the mapping where possible.

For column controls, create safe views where needed. Even when column-level security exists, safe views make consumption easier and reduce mistakes.

Finally, instrument access. Log who queried what, through which tool, and from which workload. For agent workloads, log user identity, agent identity, requested operation, data source, and generated response metadata.

Example policy model

A simple policy mapping could look like this:

{
  "principal": "sales-manager-my-north",
  "allowed_regions": ["MY-North"],
  "allowed_columns": ["customer_id", "customer_name", "revenue", "case_count", "renewal_date"],
  "restricted_columns": ["gross_margin", "credit_limit", "national_id"],
  "agent_allowed": true,
  "write_actions_allowed": false
}

The exact implementation may use Entra groups, Fabric roles, security tables, semantic model rules, or application policy. The architecture principle is more important than the file format: policy must be explicit, reviewable, and testable.

Verification and testing

Security configuration is not complete until it is tested. Create test identities for each persona and validate expected access. Use negative tests: confirm that a regional user cannot see another region, that sensitive columns are masked or blocked, and that an agent cannot reveal restricted fields indirectly.

Test through every consumption path. A policy that works in a report but fails in a notebook or Spark job is incomplete. A policy that works for direct users but fails for service principals is also incomplete.

A practical checklist:

- Test direct lakehouse or warehouse access.
- Test Power BI semantic model access.
- Test notebook or Spark access where used.
- Test API/application access.
- Test agent access with allowed and restricted prompts.
- Review audit logs after each test.

Pitfalls to avoid

The first pitfall is overusing workspace duplication. It may feel simple at first, but it creates long-term data sprawl.

The second pitfall is granting agents broad read access. Build agent-specific views and tools instead.

The third pitfall is ignoring service identities. Pipelines, notebooks, applications, and agents often use service principals or managed identities. They need the same review as human users.

The fourth pitfall is failing to document business ownership. Security teams can enforce controls, but the business must decide who is allowed to see sensitive data.

Key takeaways

  • OneLake security makes fine-grained Fabric governance more practical, but it does not replace architecture discipline.
  • Use workspace, object, row, column, semantic model, and application controls together.
  • Design agent-safe access surfaces instead of giving agents raw or privileged data access.
  • Test security through every consumption path, not only Power BI reports.
  • Treat data ownership and classification as production prerequisites, not later documentation.