Security teams should treat the semantic model as the real security boundary, not the report. Restrict who can access the underlying model, review default sharing settings, and remove Q&A features where users do not need free-form querying. If business-led development is unavoidable, map every report to its source model and validate that report-level restrictions still hold in practice.
Why shared semantic models become the security boundary
In Fabric, the report is often just a presentation layer. The shared semantic model carries the data relationships, measures, row-level logic, and query surface that users actually consume, so leakage usually happens when access is wider than intended at the model layer or when self-service features expose fields in ways report authors did not anticipate. The practical question is not whether a report looks locked down, but whether the model can still be queried safely by the people who can reach it.
That is why teams should review model permissions before they review report permissions. A user who can discover data through a shared semantic model, ask questions in natural language, or reuse the model in another report can bypass the assumptions embedded in a single report artifact. When business users are allowed to build on top of shared models, the model owner needs to define the data boundary explicitly and treat report-level controls as secondary enforcement, not the primary defense.
One useful check is whether a report can reveal more than its own visual filters suggest. If the underlying model exposes columns, measures, or relationships that are not intended for a given audience, the report may still surface them through drill, export, exploration, or free-form query paths. That is a governance problem as much as a usability problem, because the same model can serve many reports with different audiences and different expectations.
Controls that actually reduce leakage in shared-model reporting
The most effective controls are the ones that narrow what users can reach before they start composing their own analyses. Restrict access to the semantic model to the minimum audience that truly needs it, review default sharing and workspace settings, and remove or disable Q&A-style capabilities where users do not need open-ended querying. If business-led report building must continue, establish a source-model inventory so every report can be traced back to the model it depends on.
It also helps to validate the full path, not just the individual setting. A report may look properly restricted while the semantic model still permits broader discovery through direct connection, reuse in another artifact, or inherited permissions from a workspace or role assignment. Security teams should test the effective access pattern from the user’s point of view and confirm that restrictions still hold after publishing, sharing, and reusing the model in downstream reports.
For practitioners who need a reference point on shared-model governance, the NIST Cybersecurity Framework 2.0 is useful for organising governance, protection, detection, and recovery expectations around the model as a business control point. For stricter data-access design, the NIST SP 800-53 Rev 5 Security and Privacy Controls maps well to access control, auditability, and configuration management expectations. If the issue is broad data exposure through over-permissive analytics surfaces, the OWASP API Security Top 10 is a helpful reminder that broken authorization and excessive exposure patterns are often the root cause, even when the interface is not a classic API.
For teams already dealing with shared secrets, tokens, or service access behind the scenes, NHIMG’s Ultimate Guide to Non-Human Identities is relevant because model access often depends on the same governance discipline as other machine-facing identities: visibility, least privilege, and rotation. The broader lesson is that the model boundary and the access boundary must line up, or the most polished report layer will still leak data from the model underneath.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.1 — Cybersecurity Risk Management Strategy | Shared semantic models need explicit governance as a data access boundary. |
| PR.AC — Identity Management, Authentication, and Access Control | Restricting model access and validating effective permissions is an access-control issue. | |
| DE.CM — Continuous Monitoring | Teams must test whether report and model restrictions hold in practice after sharing. | |
| Recommendation — Define the semantic model as a governed access boundary and align report sharing to that boundary. Limit semantic model access to approved users and verify effective permissions before publishing. Monitor actual query and sharing behaviour to detect unintended exposure from shared models. | ||
| CIS Controls v8 | 6.3 — User Privileges | Least-privilege access is needed to prevent broad semantic-model disclosure. |
| 16.13 — Account Monitoring and Control | Effective access must be checked through the real reporting path, not assumed from configuration. | |
| Recommendation — Enforce least-privilege access to shared semantic models and remove unneeded sharing paths. Validate report-to-model access paths and monitor for unauthorized reuse or disclosure. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Overprivileged Identities | Shared-model access often fails when service and machine identities have broader rights than needed. |
| NHI-05 — Secrets Leakage and Exposure | Fabric report pipelines and model access often depend on credentials and tokens that can widen leakage. | |
| Recommendation — Reduce overprivileged model-access identities so report consumers cannot inherit excess access. Protect the credentials behind shared-model access and rotate any exposed secrets quickly. | ||
Practitioner Guidance
What to verify: Confirm which audience can access the semantic model directly, not just which audience can open the report. Then test whether those users can explore beyond the intended visual scope through Q&A, drill-through, export, or reuse in a new report.
Decision rule: If the report is meant to hide data that remains present in the shared model, treat the model as the control point and reduce model exposure first. If users genuinely need broad self-service exploration, accept that the model must be governed as a shared analytical asset and not as a curated dashboard back end.
What practitioners underestimate: Report-level restrictions often fail when permissions are inherited, duplicated, or re-applied in downstream artifacts. The safest design is the one where the source model already limits what can be seen, so later reporting choices cannot accidentally widen access.
Practitioner takeaway: If the same shared model feeds multiple reports, security should be enforced at the model boundary and continuously validated from the consumer’s perspective, because that is where unintended disclosure usually begins.
Related resources from NHI Mgmt Group
- How should security teams reduce data leakage risks when business users are building and using AI in low-code environments?
- How should security teams govern access to shared data so users can answer business questions without creating compliance risk?
- How should security teams handle data leakage risks in AI models?
- How should security teams handle data leakage when users move content into SaaS apps and AI tools?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
