They increase supply chain risk because a compromise in the external service can immediately inherit the scopes already granted by the organisation. The attacker does not need to defeat login controls if the token is still valid. That makes scope size, token lifetime, and vendor trust posture central to the risk decision.
Why This Matters for Security Teams
Overpermissioned third-party integrations turn a normal vendor dependency into an access pathway. If the integration token can read mailboxes, modify tickets, or write to code repositories, a compromise in the provider can inherit those scopes immediately. That is why security teams now evaluate third-party integrations as NHI risks, not just procurement risks. The issue is not whether the vendor is trusted today, but whether the granted access remains safe when the vendor is breached tomorrow.
Current guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both point toward tighter identity governance, but the practical challenge is that integrations are often approved once and then forgotten. NHIMG research shows how quickly that becomes dangerous: in the The 52 NHI breaches Report, compromised non-human access repeatedly served as the bridge from one environment to another. In practice, many security teams discover scope abuse only after a vendor incident has already expanded into their own tenant.
How It Works in Practice
The core problem is that third-party integrations are usually granted broad, long-lived scopes to reduce operational friction. That can be workable for low-risk automation, but it becomes fragile when the integration can act on behalf of users, repositories, or production systems. Best practice is evolving toward least privilege, short-lived tokens, and explicit approval boundaries for every integration path. For high-impact workflows, current guidance suggests treating the integration as a separate workload identity rather than as a generic service account.
Practitioners should evaluate three things together: scope, lifetime, and revocation. A token that can only read one dataset is safer than one that can read all customer records. A token with a short TTL limits blast radius if the vendor is compromised. Automated revocation matters because detection alone does not stop replay. NHIMG research in the The State of Secrets Sprawl 2026 shows why this matters operationally: 64% of valid secrets leaked in 2022 are still valid and exploitable today, which means forgotten credentials remain an active supply chain liability.
- Prefer narrowly scoped OAuth grants or equivalent delegated permissions.
- Use JIT access where the integration receives permissions only when a task begins.
- Require workload identity proof for service-to-service calls instead of static shared secrets.
- Review vendor telemetry and revoke access on inactivity, contract change, or incident.
The Reviewdog GitHub Action supply chain attack shows how quickly a trusted automation path can become a secrets exposure event once an integration is allowed into sensitive workflows. These controls tend to break down when organisations cannot map which integration tokens can reach production data, because ownership, scope review, and revocation are spread across different teams.
Common Variations and Edge Cases
Tighter integration controls often increase administrative overhead, requiring organisations to balance reduced blast radius against workflow speed and vendor convenience. That tradeoff becomes sharper when the integration is business-critical, because teams may tolerate broader access to avoid breaking revenue or support operations. There is no universal standard for this yet, so current guidance suggests risk-tiering integrations rather than applying one policy to all of them.
Some integrations only need read access, but even read-only scopes can expose secrets, customer data, or internal architecture details that support later compromise. Others use connector-style access through CI/CD, chatops, or ITSM platforms, where a single token may reach multiple systems. NHIMG coverage of the LiteLLM PyPI package breach and the Shai Hulud npm malware campaign underscores how supply chain compromise can immediately turn legitimate integration trust into credential theft.
For organisations with mature controls, the practical question is not whether to ban integrations. It is whether each integration has a narrowly defined purpose, short-lived access, and a clear off-ramp when risk changes. Where vendors cannot support those conditions, the safer answer is usually to redesign the workflow rather than widen the scope.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Overbroad integration scopes create the exact credential-risk pattern this control targets. |
| NIST CSF 2.0 | PR.AC-4 | Third-party access must be limited and reviewed to prevent inherited privilege abuse. |
| NIST AI RMF | Autonomous or AI-driven integrations need governance for trust, oversight, and misuse. |
Establish continuous monitoring and human accountability for all high-risk integration behavior.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
