Accountability usually sits with the organisation that approved or failed to govern the integration, not with the cloud platform itself. Security, IAM, and business owners should share responsibility for app review, privilege scoping, and ongoing access checks. Governance should define who can approve apps, who reviews risk, and who can revoke access quickly when anomalies appear.
Why This Matters for Security Teams
When a third-party app is granted broad access, the exposure is rarely just a vendor problem. It is usually a governance failure across app approval, scope review, and post-approval monitoring. That is why this question sits at the intersection of NHI governance and third-party risk. The issue is not whether the cloud platform was “secure enough”; it is whether the organisation allowed an integration to hold credentials or permissions that exceeded the task it needed to perform.
OWASP’s OWASP Non-Human Identity Top 10 frames over-permissioning as a core failure mode for machine identities, while NHI Mgmt Group’s Ultimate Guide to NHI Security Matters Now shows how widespread this risk is in practice. The operational question is simple: who had the authority to approve the access, who validated the scope, and who is responsible for revoking it when the app starts behaving outside expectations?
In practice, many security teams encounter this only after the app has already read too much data, rather than through intentional pre-approval review.
How It Works in Practice
Accountability should be treated as a control chain, not a single owner. The business owner defines the use case, security sets the guardrails, IAM enforces the permissions model, and the system owner or app steward monitors ongoing access. For third-party apps, that means approval should require a documented business need, explicit data scope, and a review of whether the app can operate with least privilege. If the app uses OAuth, API tokens, service accounts, or delegated permissions, those credentials should be bound to the smallest feasible scope and reviewed on a recurring schedule.
This is where NIST SP 800-53 Rev 5 Security and Privacy Controls helps translate governance into controls such as least privilege, access enforcement, and continuous monitoring. It also aligns with NHI-specific guidance in the 52 NHI Breaches Analysis, which repeatedly shows that weak machine-identity governance turns integrations into exposure paths. Practically, a mature process should include:
- named approvers for third-party app onboarding and privilege changes
- scope review before grant, not after an incident
- time-bound access where feasible, with fast revocation paths
- logging for every token grant, scope expansion, and unusual data access
- periodic recertification that checks whether the app still needs the same access
The cloud provider typically supplies the platform and control surface, but it does not own the organisation’s approval decisions or risk acceptance. These controls tend to break down when app ownership is informal and service-account sprawl makes it impossible to know which integration actually touched the exposed data.
Common Variations and Edge Cases
Tighter third-party app controls often increase friction for business teams, requiring organisations to balance speed of integration against the cost of review and revocation overhead. That tradeoff is real, especially in SaaS-heavy environments where many apps are installed by end users rather than central IT.
One common edge case is delegated access through a user’s own account. In that model, the app may not “own” the data, but the organisation still owns the policy decisions that allowed the delegation. Another is managed marketplaces, where teams assume the platform has already vetted the app. Current guidance suggests that platform review does not replace internal approval, because the app’s final permissions depend on the tenant’s own data, scopes, and admin settings. High-risk environments should also treat app secrets and refresh tokens as sensitive NHIs, not as ordinary configuration values.
For vendor risk and breach context, the Klue OAuth Supply Chain Breach and Reviewdog GitHub Action supply chain attack illustrate how third-party integrations can expose data when trust is granted too broadly. The lesson is not that every integration is unsafe. The lesson is that accountability must remain with the organisation that approved the access and failed to constrain it.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 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 | NHI-01 | Over-permissive app access is a classic NHI governance failure. |
| CSA MAESTRO | GRC-02 | Clarifies ownership, approval, and ongoing oversight for agent and app access. |
| NIST AI RMF | Accountability for automated or delegated access is a governance concern. | |
| NIST CSF 2.0 | GV.OV-01 | Governance oversight defines who accepts risk and controls access. |
| NIST Zero Trust (SP 800-207) | SC-4 | Zero Trust requires continuous verification and least-privilege access. |
Document accountability, approval, and monitoring for every AI-enabled integration.
