Anonymous Access in Microsoft Fabric Apps: How to Publish Data Without Exposing the Enterprise

Executive summary

Microsoft Fabric Apps can expose selected data operations to people who are not signed in . That is useful for public reference data, product information, schedules, and simple feedback collection. It also changes the security model: anyone who can reach the app URL can invoke the operations granted to the `anonymous` role. Microsoft explicitly warns against exposing personal, confidential, financial, or internal business data through that role.

The enterprise problem is therefore not how to switch anonymous access on. It is how to publish a deliberately small public capability without turning a governed analytics estate into an unauthenticated data API.

The safest pattern is a separate public publication plane:

• Keep governed source, Silver, Gold, and operational data outside the anonymous boundary.
• Materialize only an approved, minimal public projection in the Fabric App's app-owned data model.
• Scope the tenant setting to an authorized publisher group rather than enabling it for the whole organization.
• Grant one anonymous operation at a time, normally `read` for public reference data or `create` for submissions.
• Enforce field restrictions and authorization in the data model, not only in the user interface.
• Test forbidden GraphQL operations directly, because callers can bypass the frontend.
• Treat abuse resistance, rollback, capacity, monitoring, and preview limitations as production release criteria.

This is an architecture and operating-model decision, not a feature toggle. The business outcome should be measured as a useful public service with zero restricted-field exposure, predictable capacity demand, fast revocation, and accountable ownership.

The enterprise problem: public value creates a new trust boundary

Most Fabric programs begin with authenticated internal users. Microsoft Entra ID establishes who the user is, Fabric permissions determine what that identity can reach, and workload-specific controls restrict data further. Anonymous access removes identity from one intentionally public path.

Microsoft documents anonymous access as an authorization option rather than a replacement for authentication. A single Fabric App can expose public operations on some entities and require authenticated roles for others. The feature is disabled by default and depends on tenant authorization plus data-model permissions . Once granted, however, the `anonymous` role has no user claims with which to establish ownership, department, geography, purpose, or risk.

That distinction matters. A public visitor is not a limited employee. They are an unknown caller who may use the app exactly as intended, call the GraphQL endpoint without the interface, automate requests, enumerate data, send hostile input, or create unexpected load. Microsoft advises developers not to rely on the app UI for protection and to plan public write operations for spam, automation, and unexpected traffic.

The control objective should be stated plainly:

Publish only the data fields and operations that the enterprise has explicitly approved for unrestricted public use, while keeping internal data, administration, and publication workflows authenticated and separable.

This issue matters now because anonymous access for Fabric Apps was announced in August 2026 and remains part of the preview Fabric Apps workload . Preview status does not make the feature unsuitable for every enterprise use case, but it does require an explicit risk decision. Microsoft's current Fabric Apps FAQ lists important limitations, including no out-of-the-box multi-environment management or application lifecycle management, and no support at this time for tenant-level or workspace-level private links or workspace outbound access protection.

Representative scenario: a public service-status application

The following scenario is representative, not a YuniQ customer case.

A national service provider maintains service locations, opening hours, planned closures, and disruption notices in several operational systems. Customers need a fast, mobile-friendly public application that does not require a Microsoft account. Communications staff also need to publish corrections, while operations teams need to see internal notes, staffing constraints, and incident details.

The first design appears simple: reproduce the existing Gold service-location shape as an anonymously readable app entity. That shortcut creates several risks:

• The Gold model contains fields that were designed for employees, not the public.
• New internal fields could later be added and accidentally become queryable.
• A frontend that hides internal notes does not prevent direct API requests.
• If anonymous update or delete is granted for convenience, no identity exists to prove who changed a record.
• A traffic spike consumes the same Fabric capacity used by other workloads unless the organization isolates or governs it deliberately.
• Aggregate app metrics can show query errors and average duration, but they do not provide individual request traces or browser performance evidence.

The better design treats public service information as its own data product. Operations remain the system of record. A controlled publication process validates and copies only approved public fields into the Fabric App's app-owned data model. Anonymous callers receive read-only access to that narrow projection. Communications staff authenticate to manage publication, and internal incident data never enters the anonymous entity.

Root causes and consequences

Internal models are reused as public contracts

An enterprise semantic model or Gold table optimizes trusted reuse inside the organization. It may contain hidden columns, operational keys, internal classifications, fine-grained history, or future fields that are harmless within an authenticated boundary. A public contract has a different standard: every exposed field must be safe for anyone on the internet to retrieve and retain.

Reusing an internal model makes public exposure an accidental property of internal schema evolution. The immediate consequence may be data leakage; the longer-term consequence is release paralysis because internal teams cannot change the model without considering an external API contract.

Authentication and authorization are conflated

Authentication establishes identity. Authorization determines permitted actions. Fabric Apps requires authentication to be enabled for deployment, but an entity can still authorize specific operations for the built-in `anonymous` role. The coexistence of authenticated and anonymous paths is powerful, but teams can mistakenly assume that the presence of Fabric SSO protects all app data.

It does not protect operations deliberately assigned to the anonymous role. Those operations must be safe without identity.

The interface is treated as the security boundary

Removing a button or field from the frontend is a usability choice, not an authorization control. Fabric Apps exposes a backend endpoint with a GraphQL path. Microsoft states that permissions must be defined on the data model because callers can send requests without using the frontend.

If controls exist only in the browser, a caller can construct a direct request. The result can be unauthorized reads, writes, or enumeration even though the visible application looks appropriately restricted.

Anonymous write access is designed like authenticated self-service

For an authenticated workflow, a policy can compare a user's claims with an owner field. The anonymous role has no identity claims. An anonymous feedback entity can safely be configured as `create`-only, but it cannot use identity to prove ownership of later reads, updates, or deletes.

Granting anonymous create, read, and update to the same shared entity can therefore expose all submissions and allow any caller to change them. It also introduces spam, automated submissions, malicious payloads, and unplanned capacity demand.

Preview and capacity risk are left to the application team

Fabric Apps runs on assigned Fabric capacity. Microsoft documents CU consumption across its SQL database, GraphQL API, User Data Functions, and OneLake-hosted static content . A public workload can be bursty and is not naturally bounded by the number of licensed employees.

Without a named capacity owner, a public launch can degrade other analytics workloads or create pressure to scale before inefficient queries, over-broad result sets, and abusive patterns are understood. Without a preview acceptance decision, the application team also inherits unresolved questions about regional availability, lifecycle controls, network limitations, and supportability.

Why common approaches fall short

"Enable the tenant setting and let each team decide"

The tenant setting is an organizational boundary. Enabling it for the whole tenant expands the number of people who can create public exposure. Microsoft allows the setting to be scoped to selected security groups. Enterprises should use that scope as a publisher allow-list backed by approval, ownership, and periodic review.

"The source is already certified, so it is safe to publish"

Certification means an internal asset is trusted for its intended use. It does not mean every row and column is approved for unrestricted public access. Public release needs a separate classification and approval decision.

"We excluded sensitive fields in the React page"

Client code can be inspected and bypassed. Authorization belongs in `@role` declarations and their field-level `include` or `exclude` rules. A release test must call the API directly and prove that forbidden operations and fields are denied.

"Give anonymous users CRUD now and tighten it later"

Anonymous users do not carry identity claims. Broad CRUD permissions remove the ability to distinguish a legitimate owner from any other caller. Start with a single action. Public reference data normally needs `read`; a feedback form normally needs `create`. Microsoft recommends granting `update` or `delete` only when the public workflow requires them.

"Monitor HTTP status codes and capacity after launch"

Fabric App Metrics counts GraphQL responses containing errors even when HTTP returns `200 OK`, so status-code-only monitoring can miss application failures. App Metrics is also aggregate: it does not provide individual error samples, custom application logs, request traces, or browser performance. Capacity Metrics is a separate source for CU usage. A production service needs both operational and capacity views, plus any application-specific evidence required by its support model.

A Microsoft Fabric solution: build a governed public publication plane

Architecture principles

1. Separate public data from governed internal data. The anonymous entity should contain only fields approved for public release. Do not depend on a growing exclusion list over a broad internal entity when a small inclusion-based public model can express the contract.
2. Separate publishing from consumption. Authenticated owners or controlled automation publish approved records. Anonymous users consume only the allowed action.
3. Enforce at the data model. Treat the frontend as presentation. The generated data access layer must enforce entity, action, row, and field rules.
4. Keep administrative paths authenticated. Publication, moderation, correction, deletion, and audit access require identity and least privilege.
5. Assume direct and automated calls. Test the GraphQL endpoint, not just journeys through the page.
6. Make disablement a designed operation. Removing the anonymous role and redeploying, or disabling the tenant setting, must be rehearsed before launch.

Reference architecture

INTERNAL TRUST BOUNDARY

Operational systems
        |
        v
Bronze -> validated Silver -> governed Gold data products
                                  |
                                  | approved public projection only
                                  v
                     Publication validation and approval
                                  |
                                  v
PUBLICATION BOUNDARY

Fabric App app-owned data model
  - PublicServiceNotice: anonymous READ, explicit included fields
  - PublicFeedback: anonymous CREATE only, constrained input fields
  - PublicationAdmin: authenticated operations only
        |
        v
Generated GraphQL data access layer
        |
        +--> Public static experience (no sign-in for approved paths)
        |
        +--> Authenticated publisher/moderator experience (Fabric SSO)

CONTROL PLANE

Scoped tenant setting | publisher group | source control and deployment
negative authorization tests | app metrics | capacity metrics | kill switch

The arrow from Gold to the app-owned model is a publication process, not unrestricted pass-through access. Its implementation should be proven for the selected use case and use supported interfaces. The important architectural property is that only the approved public projection crosses the boundary.

This separation also respects the current connector model. Microsoft's Fabric Apps connector guidance describes delegated authentication and querying connected Fabric data after the user signs in. The anonymous path should not be designed as a way around those source permissions.

Define a public data contract before writing the app

Create a contract for every anonymous entity:

For public reads, favor a purpose-built entity with only publishable fields. For public submissions, use a separate create-only inbox. Do not return submissions to anonymous callers unless the content is intentionally public and separately moderated.

Scope platform enablement to approved publishers

Fabric administrators can enable the Fabric Apps workload and anonymous access for selected security groups. Use separate groups for developers who may build Fabric Apps and publishers who may deploy apps with anonymous entities. Keep membership small, owned, and reviewable.

The approval record should identify the app, owner, public URL, anonymous entities, permitted actions, data classification, capacity, go-live date, expiry or review date, and disablement procedure. This turns an otherwise invisible code-level decision into an accountable enterprise release.

Implement least privilege in the data model

Fabric Apps uses `@role` decorators that compile into runtime data-access policies. A public read entity should use the smallest possible action and an explicit field allow-list. Conceptually:

@entity()
@role('anonymous', 'read', {
  include: ['id', 'locationName', 'publicStatus', 'effectiveFrom'],
})
export class PublicServiceNotice {
  // Public fields only; internal notes do not belong on this entity.
}

An anonymous submission pattern should grant `create` without granting `read`, `update`, or `delete`:

@entity()
@role('anonymous', 'create', {
  include: ['category', 'comment'],
})
export class PublicFeedback {
  // Validate lengths, formats, and allowed values in the model/application.
}

These snippets illustrate the control pattern; the precise model must be implemented and tested against the current SDK. Keep authenticated administrative entities and fields separate. Avoid `*` for anonymous actions.

Treat public input as hostile until validated

Microsoft's guidance calls out spam, automation, and unexpected traffic. A public write design should therefore define:

• accepted field types, formats, lengths, and values;
• maximum useful payload and result sizes;
• duplicate and replay handling;
• content moderation and quarantine where submissions can be displayed or actioned;
• retention and deletion rules;
• safe failure behavior that does not reveal internal details;
• a tested response to abnormal volume.

Do not assume a control exists merely because it is common on other application platforms. During the proof of value, verify the current Fabric Apps capabilities and document any required compensating controls. If the organization cannot meet its abuse-prevention standard with supported controls, keep the workflow authenticated or use a more suitable application architecture.

Build deployment as a security control

Microsoft documents GitHub Actions deployment with a service principal and notes that `rayfin up` applies application code, database schema, and static content. Destructive schema changes are blocked by default unless `--force` is explicitly used.

An enterprise pipeline should add release gates around that mechanism:

• isolated development, test, and production workspaces;
• a non-person deployment identity with only the required workspace permission;
• secret values stored outside source code and frontend assets;
• review of every new or changed anonymous role;
• schema-diff review, with destructive changes requiring manual approval;
• direct API authorization tests after deployment;
• content and data reconciliation against the approved public contract;
• a rollback artifact and rehearsed anonymous-access removal.

Fabric Apps does not currently provide out-of-the-box multi-environment management or ALM according to Microsoft's FAQ, so the operating model must supply those controls deliberately. Redeploying a prior source revision is the documented rollback approach, but data compatibility and public-contract rollback still require testing.

Test what must fail

Positive testing proves the service works. Negative testing proves the boundary works.

For every release, run unauthenticated tests that attempt to:

• read an entity that is create-only;
• create, update, or delete an entity that is read-only;
• request every excluded or non-included field;
• query authenticated-only entities;
• retrieve another submission;
• submit missing, oversized, malformed, unexpected, or repeated values;
• enumerate records beyond the intended page size;
• use the API without the frontend;
• continue access after the anonymous role is removed and the app is redeployed;
• continue access after the tenant setting is disabled.

A failed denial test is a release blocker. Store the result with the release evidence, including the deployed version and target workspace.

Operate service health and capacity together

Fabric App Metrics provides server-side counts for sign-ins, app loads, GraphQL queries, query errors, error rate, and average duration. Use it for adoption and service-health trends, while recognizing its documented limitations: no unique-user count, browser measurements, custom logs, individual error drill-down, or request traces.

The Fabric Capacity Metrics app separately shows CU use per item and operation. Track at least:

• requests and query error rate;
• average server-side query duration;
• CU consumption by the app's SQL, GraphQL, function, and OneLake operations;
• public-result size and pagination behavior;
• freshness of the published projection;
• moderation or validation backlog for submissions;
• denied-operation test results;
• time to disable public access in a drill.

Public traffic should have a capacity envelope and an owner. Where the business impact warrants it, isolate the app from critical internal analytics so a demand spike has a bounded blast radius. Capacity placement and scale are design decisions to validate under production-shaped load, not assumptions to make from a quiet pilot.

Phased implementation roadmap

Phase 1: Discover and classify

Inventory the proposed public journeys, source fields, data owners, legal and compliance constraints, freshness needs, expected volume, and operational dependencies. Confirm that anonymous access is necessary; use authentication whenever the workflow needs identity, ownership, personalization, or sensitive data.

Exit gate: every anonymous operation has a named owner, purpose, field list, classification decision, and alternative considered.

Phase 2: Design the publication contract

Define purpose-built public entities, separate read and submission paths, publishing approvals, freshness objectives, retention, rollback, workspace topology, deployment identity, and capacity envelope. Record Fabric Apps preview constraints and obtain the required risk acceptance.

Exit gate: architecture, threat model, data contract, and disablement runbook are approved.

Phase 3: Prove the boundary

Build a narrow proof of value with synthetic or non-sensitive data. Scope tenant enablement to the delivery group. Implement model-level roles and field allow-lists. Test direct GraphQL calls, malformed input, pagination, concurrency, capacity consumption, and disablement.

Exit gate: all forbidden paths fail, approved paths work, and no restricted field is present in the public entity.

Phase 4: Productionize delivery and operations

Establish dev/test/prod workspaces, source-controlled deployment, non-person identities, secret handling, manual approval for destructive changes, reconciliation, service and capacity dashboards, support ownership, incident routing, and release evidence.

Exit gate: a production-shaped load test, rollback drill, access-revocation drill, and operational handover pass.

Phase 5: Launch in a bounded ring

Start with one low-risk public dataset or create-only workflow. Monitor error rate, latency, CU demand, publication freshness, input quality, and support cases. Keep the launch reversible and do not add new entities or operations during the observation period.

Exit gate: service objectives hold under real demand and there is no unexplained exposure, error, or cost pattern.

Phase 6: Review and scale deliberately

Review publisher-group membership, anonymous roles, public schema, data classification, source lineage, capacity attribution, preview status, platform limitations, and business value on a fixed cadence. Treat every new field or action as a public-contract change requiring approval and negative testing.

Governance, security, adoption, and cost considerations

Governance

Assign two owners: a data owner who approves public content and a service owner who operates the app. Maintain a register of public Fabric Apps and their anonymous entities. Public classification must be explicit; absence of a sensitivity label is not evidence that data is public.

Security

Apply Zero Trust principles to the authenticated control plane: verify publishers explicitly, use least privilege, and assume the public endpoint will be probed. Anonymous data itself cannot be protected by identity claims, so minimize it by design. Keep secrets out of source code and frontend assets. Microsoft documents a Fabric Apps secret mechanism for Functions; use environment-specific secret configuration where Functions require credentials.

Network and preview risk

Fabric Apps is in preview, is not available in all regions, and currently has documented network and lifecycle limitations. Evaluate regional availability, support expectations, private connectivity requirements, outbound access requirements, recovery, and compliance before production approval. A use case that requires private-link-only access is not an anonymous public use case and should use a different pattern.

Adoption

Anonymous access can remove customer friction, but that benefit depends on content accuracy, mobile usability, accessibility, and clear support ownership. A polished interface cannot compensate for stale or ambiguous public data. Measure successful task completion and publication freshness, not page loads alone.

Cost

Fabric Apps consumes the workspace's Fabric capacity through the app-owned SQL database, GraphQL queries and mutations, User Data Functions, and OneLake storage and operations for static content. Bound queries, select only necessary fields, paginate results, avoid chatty request patterns, and test peak traffic. Attribute the app's consumption separately so public demand is visible in capacity decisions.

Success metrics

Use a compact scorecard that connects public value to control effectiveness:

The numeric thresholds beyond zero exposure and complete release testing should be set from a proof of value and business criticality. Avoid borrowing generic targets that have not been validated on the organization's capacity and traffic profile.

How YuniQ can help

YuniQ's published Microsoft Fabric services align with the work required to make this pattern operational:

• Fabric Strategy & Readiness: current-state diagnostics, use-case prioritization, capacity planning, workspace topology, and security, governance, and operating-model design can determine whether anonymous Fabric Apps fit the use case and risk posture.
• OneLake & Data Architecture: domain boundaries, medallion layers, workload selection, and reusable business models can separate the governed internal source from the minimal public publication product.
• Governance, Security & DevOps: YuniQ describes least-privilege Entra role design, Purview integration, dev/test/prod separation, Git CI/CD, auditable logging, monitoring, and capacity alerts. Those controls map directly to publisher governance, deployment assurance, and public-service operations.
• Proof of Value: YuniQ offers focused validation with real enterprise data and capacity sizing. For this scenario, the proof should validate the public data contract, denial tests, publication path, preview limitations, peak demand, and rollback before a production commitment.
• Optimize & Scale: YuniQ's service page covers capacity monitoring, query optimization, DevOps release management, and continuous roadmap work, which are relevant once public demand introduces a new capacity and support profile.

These are service alignments grounded in YuniQ's published capabilities. The exact engagement should begin with the public business journey, data classification, and acceptance criteria rather than a predetermined feature rollout.

Practical next steps

1. Choose one public journey that needs no identity and creates clear customer or operational value.
2. List every field and operation it requires; mark everything else prohibited.
3. Confirm the data owner, service owner, capacity owner, and incident owner.
4. Decide whether Fabric Apps preview status and current limitations meet the organization's production standard.
5. Create a separate public entity and a create-only submission entity where needed; do not expose an internal Gold model directly.
6. Scope Fabric Apps and anonymous-access tenant settings to an approved delivery group.
7. Build a proof of value that calls the GraphQL API directly and treats every denial test as a release gate.
8. Baseline service metrics and CU consumption under expected and adverse traffic patterns.
9. Rehearse removal of the anonymous role, redeployment, tenant-level disablement, and verification that access has stopped.
10. Launch narrowly, review evidence, and expand only through controlled public-contract changes.