How should security teams structure third-party access when a partner product needs to read tenant data without seeing the data itself?

Separate data access from operator access

The cleanest pattern is to let the partner product process tenant data without handing over direct read access to the underlying dataset. That means the workload runs inside the tenant boundary, produces a constrained output, and the customer controls where that output lands and who can retrieve it.

This is the difference between delegating a service function and delegating data custody. If the partner can browse, query, or export the raw data stream, the access model has already crossed the line from controlled processing to shared visibility.

For tenant-facing platforms, the design goal is not to make every integration equally powerful. It is to ensure the partner receives only the minimum inputs needed for processing, while the customer retains authority over the app registration, the storage target, and any downstream use of the result.

Control the output path, not just the input path

A partner integration is safer when the sensitive result is written to a customer-controlled workspace rather than pushed back through a partner-owned interface. That keeps the customer in charge of retention, sharing, and deletion, and it reduces the chance that the partner can copy out more than the intended output.

This pattern is especially important when the partner product is doing aggregation, scoring, enrichment, or analysis over tenant records. The service can still function, but the access scope should end at the processing boundary. When the output is the only artifact that leaves the tenant, it becomes much easier to review, revoke, and audit.

Separate operator permissions from data permissions as well. A vendor administrator may need to manage the integration, but that does not mean they should be able to read the tenant’s business data, support content, or analysis output. Distinct roles, distinct approvals, and distinct audit trails reduce the chance that a convenience login becomes a data-exfiltration path.

Make revocation and scope limits part of the design

Time-bound access is not optional in this pattern. The integration should be grantable for a specific purpose, visible to the customer, and removable without depending on the partner’s cooperation. If an access path cannot be revoked cleanly, it is too durable for third-party use.

That also means permissions should be narrow enough to survive a compromise of the partner side. The safest third-party pattern is one where the partner can only perform the intended function, cannot enumerate unrelated tenant assets, and cannot silently expand its own access through reused credentials or broad tenant consent.

Good design also assumes the partner relationship will change. Mergers, staff turnover, product replacement, and contractual disputes all create offboarding risk. A third-party model that is secure only while everyone behaves well is not a secure model.

Risk and Threat Considerations

Third-party access becomes dangerous when a partner integration is allowed to see more than it needs, especially in multi-tenant environments where one trust mistake can expose many customers. The main risk is not just accidental overexposure, but abuse of a valid integration path for data collection, lateral access, or unauthorized export.

Failure mechanism: The partner receives standing permissions, broad token scope, or direct read access to tenant records, then uses that access to retrieve data outside the intended processing flow or to persist access after the business need has ended.

Impact: Sensitive tenant data can be copied, retained, or shared beyond customer intent, and the organisation may lose both containment and evidence of who accessed what, when, and for what purpose.

Practitioner Guidance

What to verify: Confirm that the integration boundary is defined around a processing workload, not around a general-purpose partner login. The customer should be able to show where the data is ingested, where results are written, and how access is withdrawn if the partner relationship ends.

Decision rule: If the partner needs to manage the integration but not read the underlying tenant data, split those functions into separate permissions and separate identities. If the same credential can both administer and inspect data, the design is too permissive.

What good looks like: The partner can complete its task, the customer controls the app registration and result location, and every access path is narrow, time limited, and auditable. That is the point where third-party enablement and tenant control are both preserved.

Practitioner takeaway: Treat the partner as a processor of customer-controlled data, not as a co-owner of the tenant boundary. If the integration can see raw data, the architecture has already failed the separation test.

Related resources from NHI Mgmt Group

• Guide: Third-Party, B2B and Contractor Access Guide
• How should security teams grant third-party contractors access to sensitive data without exposing the wider environment?
• How should banks and fintech teams evaluate third-party access to customer banking data without weakening security or privacy controls?
• What should security teams do after a third-party partner leaves or no longer needs access?
• How should security teams govern third-party remote access without creating standing privilege?