Who is accountable for the security of third-party integrations when business teams can adopt apps directly?

Why This Matters for Security Teams

When business teams can connect SaaS apps and automation tools directly, the real risk is not just tool sprawl. It is the creation of non-human identities, OAuth grants, API keys, and service accounts that bypass central review but still inherit production data access. That is why accountability cannot sit in one function alone. Security has to define the control plane, and the business has to justify the use case and data exposure.

NHIMG research shows why this matters: 92% of organisations expose NHIs to third parties, and only 5.7% have full visibility into service accounts in Ultimate Guide to NHIs. Once an app is approved informally, it can stay connected long after the business owner forgets why it was added. Attackers do not need to breach the core IAM stack if they can abuse a trusted integration. That pattern appears repeatedly in incidents such as Klue OAuth Supply Chain Breach and the GitHub Repo Breach, where third-party access became the path of least resistance.

Current guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls supports shared governance, but the operating model is still uneven across enterprises. In practice, many security teams discover risky third-party access only after a token has already been abused or a vendor relationship has ended.

How It Works in Practice

The workable model is shared accountability with clear control boundaries. Business owners own the need for the integration, the data it touches, and the ongoing business value. Security owns the standards for approval, the control requirements, and the monitoring and offboarding process. That means every app or integration should have an identified owner, a documented purpose, explicit data scopes, and a defined review cadence.

Security teams should require a repeatable intake process before any new app is connected. At minimum, that process should verify whether the app uses OAuth scopes, API keys, service accounts, or delegated admin rights; whether it can be constrained to least privilege; whether secrets are stored in a managed secrets system; and whether logging exists for token use and privilege changes. Where possible, access should be time-bounded and revoked automatically when the business need ends. These controls align closely with the lifecycle and visibility concerns in The State of Non-Human Identity Security, which found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps.

For governance, policy needs to be enforced at the integration layer, not just at procurement. That includes app allowlists, periodic access certification, monitored token inventory, and decommissioning workflows that revoke grants when an app is removed or a contract ends. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for mapping review, logging, and least-privilege expectations into formal control ownership. These controls tend to break down when business units can approve integrations inside SaaS marketplaces without any central inventory because security then loses the ability to see what has actually been granted.

Common Variations and Edge Cases

Tighter control often slows business adoption, requiring organisations to balance speed against review depth. That tradeoff becomes sharper in sales, marketing, and product teams that rely on fast-moving SaaS ecosystems. In those environments, the answer is usually not to block self-service entirely, but to define preapproved guardrails: sanctioned categories of apps, approved data classes, standard OAuth scopes, and mandatory review for anything touching sensitive systems.

There is no universal standard for this yet, but best practice is evolving toward tiered accountability. Low-risk integrations may be approved through a lightweight workflow, while apps that read mailboxes, repositories, CRM records, or cloud resources should require stronger review and continuous monitoring. Where the business claims ownership of the tool, security should still retain authority over the access grant, logging requirements, and emergency revocation. This is especially important for shadow AI and automation tools, which can chain access across services in ways the original business owner does not understand.

One useful rule is that ownership follows the risk, not just the spend. If an app can exfiltrate data, trigger workflows, or impersonate users, then it is part of the security boundary whether procurement saw it or not. Incidents documented in 52 NHI Breaches Analysis show that unmanaged grants and stale access are recurring failure points. The edge case most teams miss is internal champions leaving a business unit while their self-approved integrations remain active and still trusted.

Related resources from NHI Mgmt Group

• How should security teams limit blast radius when a third-party needs IAM permissions in AWS?
• How should security teams govern third-party app access to cloud accounts in a zero trust model?
• How should security teams make NHI best practices usable across the business?
• How should security teams govern third-party OAuth access for SaaS integrations?