An organization-scoped provider is a supported integration that can vary by customer organization. It allows a tenant to control whether the provider is enabled, which scopes are requested, and which credentials are used, which is essential when the provider must authenticate against each customer’s own account.
Expanded Definition
An organization-scoped provider is a tenant-specific integration pattern in which provider enablement, requested scopes, and credentials are controlled at the organisation level rather than globally. In identity and platform operations, this matters when the provider must connect to each customer’s own account, such as a separate SaaS tenant, cloud subscription, or external API domain.
The practical distinction is between a shared provider configuration and a per-organisation configuration. Shared settings may be acceptable for generic integrations, but organisation-scoped providers are used when access must reflect customer-specific trust boundaries, consent, and credential ownership. That makes the model especially relevant in multi-tenant products, delegated administration, and Non-Human Identity governance, where service identities should not be treated as interchangeable across tenants. For related NHI risk patterns, NHI teams often map these integrations against the OWASP Non-Human Identity Top 10.
Usage in the industry is still evolving, and some vendors use the phrase loosely to describe any tenant-configurable connector. At NHI Management Group, the stricter interpretation is more useful: the provider is scoped by organisation because the credentials, grants, and operational controls are materially different for each tenant. The most common misapplication is treating a tenant-specific connector as a global provider, which occurs when one shared credential set is reused across customer organisations.
Examples and Use Cases
Implementing organisation-scoped providers rigorously often introduces configuration and lifecycle overhead, requiring teams to balance tenant isolation against support complexity and rollout speed.
- A multi-tenant platform lets each customer enable a payment or messaging provider only for their own organisation, with separate OAuth consent and token storage.
- An enterprise integration links to each customer’s cloud account using customer-owned credentials, so the platform cannot assume a single shared service principal.
- A B2B SaaS application requests different scopes per tenant because one customer allows read-only access while another approves write actions.
- An NHI platform tracks provider instances per organisation so secret rotation, revocation, and audit evidence are tied to the correct tenant boundary.
- A workflow agent uses customer-specific API credentials to interact with external systems, rather than a platform-wide credential that could overextend access.
For teams designing these controls, the operational question is not only whether the provider works, but whether its trust relationship is isolated per organisation and can be revoked without affecting other tenants. That distinction is often central to safe delegated access and clean offboarding.
Why It Matters for Security Teams
Organisation-scoped providers reduce the risk that one tenant’s configuration, approval, or credential set can be reused elsewhere. That matters for access containment, auditability, consent management, and incident response. When a provider is enabled per organisation, security teams can verify which tenant approved it, which scopes were granted, and which credentials are currently in use. This is especially important where integrations rely on secrets, tokens, or certificates that can be copied too easily across environments.
From an identity governance perspective, the model aligns with least privilege and clearer accountability. It also helps distinguish customer-managed access from platform-managed access, which is a recurring control issue in NHI and agentic AI deployments. If an autonomous agent uses an organisation-scoped provider, the organisation must be able to constrain what that agent can reach, how long the credentials remain valid, and how the integration is revoked when risk changes. NHI teams commonly see the consequences only after a tenant asks why an integration had broader reach than expected, at which point organisation-scoped control becomes operationally unavoidable.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | Covers NHI governance patterns where tenant-scoped credentials and integrations must be isolated. | |
| NIST CSF 2.0 | PR.AC-4 | Supports least-privilege access management for tenant-specific provider permissions and grants. |
| NIST SP 800-63 | Informs assurance and authentication considerations when providers use customer-specific credentials. | |
| NIST Zero Trust (SP 800-207) | SC-3 | Zero trust isolation principles support segmenting trust by organisation and workload. |
| OWASP Agentic AI Top 10 | Agentic systems often rely on scoped integrations that must be constrained per organisation. |
Treat each organisation-scoped provider as a distinct NHI boundary with separate ownership, rotation, and revocation.
