Who is accountable when a third-party integration exposes corporate secrets?

Why This Matters for Security Teams

When a third-party integration exposes corporate secrets, the immediate technical failure is only part of the issue. The larger problem is governance: who approved the connection, who accepted the risk, and who owned continuous review after go-live. The OWASP Non-Human Identity Top 10 treats secret handling and access lifecycle as first-order controls, not one-time setup tasks. NHI Management Group’s Guide to the Secret Sprawl Challenge shows how quickly exposed credentials become a systemic problem once integrations multiply across SaaS, CI/CD, and automation layers.

Accountability also depends on whether the enterprise used a defensible control model. If an integration retained broad access, used long-lived secrets, or lacked review triggers, the enterprise cannot shift responsibility entirely to the vendor. In practice, third parties can introduce the path, but the enterprise owns the decision to keep that path open. Many security teams discover this only after a secret has already been reused, duplicated, or embedded in multiple systems, rather than through a deliberate access review.

How It Works in Practice

Practitioner guidance starts with ownership mapping. Every integration should have an internal business owner, a technical custodian, and a review cadence that can revoke access without waiting for a vendor response. That matters because integrations often use service accounts, API keys, OAuth grants, or webhook tokens that behave like persistent identity rather than a temporary connection. Once those credentials exist, they should be treated as Non-Human Identities with explicit lifecycle controls.

Best practice is evolving toward short-lived, context-bound access. Instead of granting a partner system broad standing permissions, teams should prefer:

• Just-in-time access for narrowly defined tasks
• Scoped secrets with rotation and revocation tied to contract or workflow changes
• Workload identity where possible, so the integration proves what it is rather than relying only on a static key
• Policy checks at request time, not just at onboarding

This aligns with Zero Trust thinking: trust is never permanent, and access must be continuously verified. It also matches the operational lessons in the 52 NHI Breaches Analysis, where secret exposure often became severe because credentials outlived the business need that created them. The same pattern appears in the Reviewdog GitHub Action supply chain attack, where a trusted automation path became a secret-exposure vector.

Operationally, accountability means documented approval, continuous inventory, and a removal process that works even when the third party is unresponsive. These controls tend to break down in fast-moving CI/CD and SaaS ecosystems because integrations are added through convenience channels faster than governance teams can review them.

Common Variations and Edge Cases

Tighter integration control often increases friction for developers and partners, requiring organisations to balance speed against containment. That tradeoff is real, especially when a third-party service is embedded deep in customer-facing workflows or when a legacy vendor cannot support modern workload identity.

There is no universal standard for this yet, but current guidance suggests three common exceptions deserve extra scrutiny. First, shared platform integrations may blur ownership, so contract language must specify who rotates secrets, who monitors use, and who responds to compromise. Second, emergency access paths may be justified during incidents, but they should be time-bound and reviewed afterward. Third, federated identity does not remove accountability; it only changes how the trust relationship is enforced.

NHI Management Group’s The 2025 State of NHIs and Secrets in Cybersecurity reports that 44% of NHI tokens are exposed in the wild, underscoring how often secret handling fails after deployment rather than at issuance. The practical answer is not to assume the vendor will police the integration, but to prove that every standing permission can be justified, observed, and removed.

In environments with many unmanaged connectors, accountability often becomes clear only after a secrets incident has already crossed business, vendor, and cloud boundaries.

Related resources from NHI Mgmt Group

• Who is accountable when third-party access stays active too long?
• Who is accountable when an unauthenticated workspace identity flaw exposes secrets?
• Who is accountable when an AI agent in CI/CD exposes secrets or pushes unauthorized code?
• Who is accountable when a third-party integration is abused?