Who is accountable when replayed tokens come from a compromised third-party integration?

The organisation remains accountable for the access it grants through its identity stack, even when the compromise starts with a vendor integration. Governance needs to cover token scope, storage, revocation, and offboarding for every external service that can hold credentials on the organisation’s behalf.

Why This Matters for Security Teams

When replayed tokens originate from a third-party integration, the incident often looks like a vendor failure, but the access path still runs through the organisation’s own trust decisions. That means the security team, platform owners, and business system owner all share accountability for what the token could do, how long it stayed valid, and whether it was scoped tightly enough to limit blast radius. The practical lesson is simple: external integrations are part of the identity perimeter, not outside it.

This is especially visible in breach patterns documented in The 52 NHI breaches Report and the Salesloft OAuth token breach, where token trust outlived the initial compromise. Current guidance from the OWASP Non-Human Identity Top 10 treats NHI lifecycle control as a first-class security obligation, not a back-office admin task. In practice, many security teams only discover this after a partner app has already replayed a valid token into a production API, rather than through intentional vendor risk management.

How It Works in Practice

Accountability should be defined by control, not blame. The organisation is accountable for deciding which third-party apps can hold secrets, what scopes they receive, where tokens are stored, how quickly they expire, and how revocation works when the integration is abused. The vendor may have triggered the compromise, but the organisation approved the linkage and benefited from the resulting access.

Operationally, that means every integration should have a named owner, explicit token inventory, and offboarding runbook. Tokens need short lifetimes, narrow scopes, and revocation hooks that are tested before an incident. Where possible, use workload identity and just-in-time issuance instead of long-lived static secrets so that access is proven at request time and can be removed without waiting for a manual cleanup cycle. This is aligned with the NHI hygiene issues highlighted in Guide to the Secret Sprawl Challenge and the exposure patterns in the 2025 State of NHIs and Secrets in Cybersecurity, which reports that 44% of NHI tokens are exposed in the wild and 91% of former employee tokens remain active after offboarding.

• Inventory every third-party integration that can mint, store, or replay tokens on your behalf.
• Bind each token to a business owner, expiry, scope, and revocation path.
• Prefer ephemeral credentials and automated rotation over standing access.
• Test offboarding, not just onboarding, so removed integrations actually lose access.
• Monitor for token use from unusual IPs, time windows, and API sequences.

For implementation guidance, Anthropic — first AI-orchestrated cyber espionage campaign report is useful for understanding how tool access and delegated authority can be chained once trust is established. These controls tend to break down when integrations are shared across business units because ownership becomes ambiguous and revocation is left to ticket queues.

Common Variations and Edge Cases

Tighter token control often increases integration overhead, requiring organisations to balance partner convenience against the risk of standing access. That tradeoff is real, especially where SaaS platforms do not support fine-grained revocation or per-workflow identity binding.

There is no universal standard for this yet, but current guidance suggests treating high-risk integrations differently from routine ones. Customer support tools, CI/CD plugins, data sync connectors, and automation bots often deserve separate approval tiers because their replay value is much higher than a low-risk reporting connector. If a vendor cannot support clear ownership, rapid token invalidation, and evidence of least privilege, the integration should be constrained or removed.

This also matters for agents and autonomous workflows: a compromised integration that can drive tool use behaves like a non-human identity with delegated authority, not like a passive API client. In that setting, accountability should also include policy design and runtime checks, which is why OWASP Non-Human Identity Top 10 and NIST-aligned governance are useful reference points, while LiteLLM PyPI package breach shows how supply-chain trust can become credential exposure. Current best practice is evolving, but the direction is clear: the organisation remains accountable for access it authorises, even when a third party is the point of failure.

Related resources from NHI Mgmt Group

• How should security teams think about a compromised integration like Drift?
• What should teams do first after a third-party integration is compromised?
• Who is accountable when a third-party integration is abused?
• Who is accountable when a third-party integration keeps an NHI active after the business need ends?