An export creates another authorization boundary
A shared analytics destination can combine data from several customers while still requiring each customer's information to remain isolated. The source application's tenant controls do not automatically carry over to a file, warehouse table, dashboard or scheduled report. An export requirement must therefore cover source selection, transformation, destination access, downstream use and deletion. A correctly authenticated export worker can still disclose the wrong tenant's data if any of those decisions is wrong.
Azure's multitenant identity guidance separates authentication, authorization and entitlements and discusses tenant-specific federation risks. It supports asking precise questions about tenant binding, but it does not establish that EmailAuth implements any particular export control. This manuscript proposes requirements and fixture-based verification. No export was generated, customer data accessed, destination permission granted or analytics system configured.
Bind the source selection to the authorized tenant
Document the export requester, authenticated service or user identity, permitted tenant set, requested resources and approved business purpose. The source must determine authorized scope from a trusted relationship, not merely accept a customer identifier supplied by the caller. A request parameter can identify the desired tenant without proving that the caller may access it. The authorization decision should cover every resource included in the output, including related records joined during processing.
Specify how the application handles a requester who belongs to more than one tenant. Selecting a tenant in a user interface should not silently become an unrestricted cross-customer export. Record whether the export is single-tenant, an explicitly authorized multi-tenant administrative job or an aggregated dataset with a separately approved scope. These are proposed categories for the requirements document, not claims that a particular platform exposes them.
Preserve tenant context through transformations
A tenant boundary can be lost after an initially correct query. A join might use a domain string that is not unique across the intended historical model, a cached result might omit tenant context, or a later aggregation might combine rows beyond the approved scope. Requirements should state how tenant identity accompanies each record through extraction, transformation and output. Do not rely on the destination folder name as the only isolation mechanism.
Use stable internal identifiers where supported and retain their mapping provenance. A display name, email address or domain label can change and should not be assumed to be a globally unique customer key. If cross-tenant aggregation is explicitly authorized, define the permitted grouping, retained dimensions and disclosure risk. Removing a visible customer column does not necessarily anonymize the data; rare combinations and drill-downs can still reveal individual organizations or workflows.
Treat destination access as a separate decision
Record the destination system, storage location, permitted readers, administrators, service identities, retention policy and any onward sharing. A private source application cannot compensate for an export placed in a broadly accessible analytics workspace. Access to the destination should match the approved purpose and data scope. Do not assume that a shared dashboard's row-level filter also protects downloadable underlying data or every alternative query interface.
Require the destination owner to describe the actual enforcement controls and supported negative tests. These may differ between files, databases and analytics products. The manuscript does not invent a universal row-level security feature or assert that a dashboard control protects all export formats. A publishable implementation example must identify the real destination, its current configuration and the evidence showing that unauthorized readers cannot access another tenant's records.
Minimize and redact with diagnostic value in mind
Define the minimum fields needed for the analytics purpose. Authentication reporting may contain domains, sending infrastructure, message-related identifiers and operational context that customers regard as confidential. Remove unnecessary personal or sensitive fields before sharing, while preserving the dimensions needed to explain the metric. A redaction plan should document which relationships remain visible and which interpretations are no longer possible after redaction.
Use synthetic fixtures for the acceptance tests proposed here. Synthetic data should be distinguishable by tenant and include deliberate edge cases such as similar display names, shared provider labels and historical domain reassignment. Do not copy production rows into a test simply because the names will later be hidden. A redacted output is evidence of one transformation result, not proof that every future export will remain within scope.
An export-boundary worksheet
Create a worksheet with requester identity, source tenant binding, authorized resource set, query or job version, field list, transformation rules, destination, permitted readers and retention owner. Add evidence references for each boundary rather than a single “export secure” checkbox. Record the approval for any multi-tenant dataset separately from approval for ordinary tenant reporting. The intended audience and purpose should remain visible throughout the record.
The verification section should identify the fixture tenants, expected selected rows, excluded rows, redaction expectations and destination access tests. Include a case in which a caller supplies another tenant's identifier and a case in which a destination reader attempts an unauthorized drill-down or download. These are proposed tests to run only with authorization in a controlled environment. No cross-tenant request or destination access attempt was performed during this work.
Fictional diagnosis: a correct query and a broad workspace
A fictional team exports one customer's authentication summary using the correct source filter. The output is then placed in a shared analytics workspace whose viewers include staff assigned to other customers. The source query is correct, but the destination access does not match the intended audience. The team cannot declare the export safe by showing only the source filter.
The proposed review traces both boundaries and asks the destination owner to verify access using synthetic fixtures. It also checks whether underlying downloads and scheduled distribution follow the same restrictions as the visible dashboard. This scenario is fictional, not an observed disclosure or a claim about a named analytics service. No real customer data was exported or shared. The lesson is that source correctness and destination confidentiality are independent acceptance criteria.
Cover lifecycle changes and repeatable jobs
Scheduled exports need a current authorization decision, not just the approval that existed when the job was created. A customer may leave, an employee may change role or a destination audience may expand. Define how those changes affect the job and how stale access is detected. RFC 7643 describes user administrative status while leaving its definitive meaning to the service provider; a lifecycle update should not be assumed to revoke every scheduled export or destination entitlement automatically.
Record who owns periodic review and what triggers an immediate reassessment. Include changes to tenant mapping, query logic, destination permissions and redaction rules. Preserve job versions and evidence so a later reviewer can reconstruct what was selected and who could receive it. Do not promise that a single negative test proves isolation under every future configuration.
Release only with multi-tenant evidence
The catalogue requires multi-tenant fixtures verifying source selection, destination access and redacted output. That evidence remains open. This draft supplies the proposed worksheet and fictional example, not test fixtures, exported files or access results. It makes no claim that EmailAuth or a destination product already implements these requirements.
Human specialist review, source applicability, production routes, visual accessibility and owner release also remain open. A publishable implementation needs authorized synthetic fixtures, retained outputs, documented source and destination configurations and actual negative results. The resulting evidence should demonstrate the full path from approved scope to permitted audience without collecting real tenant secrets or exposing customer data.