The customer remains accountable for the access model it approves, even when a third-party integration performs the work. Security teams must validate install-time permissions, domain restrictions, and ongoing project governance before relying on the tool. The vendor can implement controls, but the organisation owns the decision to grant access and the configuration that bounds it.
Why This Matters for Security Teams
When a third-party integration is misconfigured, the failure is usually not the vendor’s code alone. The organisation approved the access boundary, allowed the integration into its projects, and accepted the operational risk of that trust relationship. That is why accountability stays with the customer, even when the tool executes the access path. The lesson is consistent with patterns seen across the 52 NHI Breaches Analysis and broader guidance from the OWASP Non-Human Identity Top 10: identity trust is often granted faster than it is governed.
This matters because third-party access integrations frequently operate with broad project scope, inherited permissions, and weak review discipline after installation. A misconfiguration can expose cloud projects, bypass expected approval paths, or create persistent access long after the original use case changed. The practical question is not whether the vendor can authenticate the integration, but whether the organisation can prove the access is bounded, reviewable, and revocable. In practice, many security teams only discover the gap after a project has already been overexposed through a trusted integration.
How It Works in Practice
Accountability should be mapped to the control plane that granted the access, not the party that merely executed it. Security teams need to review install-time permissions, project-level inheritance, token scope, domain restrictions, and whether the integration can enumerate or modify resources outside the intended tenant or workspace. The operational model should treat the integration as a non-human identity, with explicit ownership, expiry, and review cadence. NHIMG’s Ultimate Guide to NHIs and the Klue OAuth Supply Chain Breach both reinforce the same operational point: connected apps can become blast-radius multipliers when governance is weak.
Good practice is to separate vendor capability from customer responsibility. That means:
- Grant only the minimum scopes needed for the stated use case.
- Bind access to specific projects, domains, or resource groups rather than the whole environment.
- Review whether the integration can create new tokens, new principals, or hidden inheritance paths.
- Require periodic re-approval for privileged or cross-project access.
- Revoke access immediately when ownership, purpose, or tenant context changes.
Security teams should also verify whether the integration supports short-lived credentials, audit logging, and admin-visible policy enforcement. Static approvals and indefinite tokens are especially risky because they outlive the human decision that created them. These controls tend to break down in large multi-project cloud environments because inheritance, delegated admin rights, and stale app approvals make it difficult to see where effective privilege actually begins and ends.
Common Variations and Edge Cases
Tighter third-party access control often increases administrative overhead, requiring organisations to balance rapid onboarding against stronger review and revocation discipline. That tradeoff becomes most visible when teams want broad integration utility with minimal friction. Current guidance suggests there is no universal standard for this yet, but the best operational pattern is to classify integrations by sensitivity, then apply stronger controls where the integration can read, write, or move laterally across cloud projects.
Edge cases usually involve shared tenants, delegated administration, and automated project provisioning. In those environments, a single mis-scoped consent can expand into multiple projects before anyone notices. The Vercel Context.ai OAuth Supply Chain Breach shows how shadow integrations can outgrow the original approval model, while the GitHub Repo Breach — Heroku and Travis CI OAuth Tokens illustrates how trusted automation can become a long-lived exposure path.
Where the question becomes legal or contractual, accountability may be shared across procurement, platform, and application owners, but operational responsibility still sits with the organisation that enabled the access. Vendor assurances do not replace internal governance, and they do not eliminate the need to prove least privilege, revocation, and scope control.
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 | Third-party integrations are non-human identities that must be scoped and governed. |
| CSA MAESTRO | IAM-03 | Agent and integration access must be continuously validated against intended scope. |
| NIST AI RMF | GOVERN | Accountability for autonomous or delegated access starts with governance and oversight. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions and authorisation boundaries are central to this misconfiguration risk. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires explicit verification and continuous authorization of every access path. |
Enforce least privilege, approval workflows, and periodic entitlement reviews for integrations.
Related resources from NHI Mgmt Group
- Who is accountable when a financial institution fails to meet cybersecurity requirements for access control and third-party oversight?
- How should security teams control third-party access in cloud environments without breaking operations?
- Who should be accountable for third-party non-human identity risk when business tools request elevated access?
- Who is accountable when cloud access policies allow risky privileges to spread across projects?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
