An integration is a trusted connection between systems that allows data exchange or automated actions. In identity security, integrations often depend on credentials or tokens that can outlive their original purpose. They must be inventoried and reviewed like any other access path because they can widen the attack surface quickly.
Expanded Definition
In NHI security, an integration is more than a technical connector. It is an access relationship between systems, usually backed by a secret, token, certificate, or delegated grant that enables one workload, agent, or application to act on another system’s behalf. That makes integration a trust boundary, not just a software feature. The practical question is not whether data can move, but who or what is authorized to move it, under what scope, and for how long.
Definitions vary across vendors when integrations are described as “apps,” “connectors,” or “service accounts,” but the security issue is the same: each integration can create standing access if it is not governed as an identity. NIST’s NIST Cybersecurity Framework 2.0 reinforces the need to understand external dependencies, access pathways, and risk-based oversight. In NHI programs, integrations should be inventoried, scoped, and reviewed with the same discipline applied to human privileged access. The most common misapplication is treating an integration as a one-time IT setup, which occurs when teams fail to track the credential, permission set, and downstream systems after deployment.
Examples and Use Cases
Implementing integrations rigorously often introduces operational friction, because every connection must be approved, monitored, and rotated, requiring organisations to weigh automation speed against governance overhead.
- A CI/CD platform uses an API key to deploy to production, and the key must be rotated, scoped, and logged like any other privileged NHI.
- A SaaS-to-SaaS sync app exchanges customer records through delegated OAuth permissions, creating a long-lived access path that needs periodic review.
- An AI agent calls internal tools through a connector, and the integration must be constrained to specific actions rather than broad system access.
- A third-party observability service ingests logs through a token, and the token should be treated as a secret with a defined owner and offboarding plan.
These patterns are visible in incidents such as the Klue OAuth Supply Chain Breach, where an integration channel became the path to broader exposure, and the GitHub Repo Breach — Heroku and Travis CI OAuth Tokens, where tokens tied to integrations expanded blast radius. At the standards level, OAuth-based integrations should align with OAuth 2.0 because the grant type determines how much trust is delegated and how revocation works.
Why It Matters in NHI Security
Integrations matter because they often become the quietest path to the most sensitive data. They are frequently deployed faster than human access, reviewed less often than privileged accounts, and forgotten after the project that created them is closed. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why integrations must be treated as first-class identity assets rather than background plumbing. The same guide reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and that 71% of NHIs are not rotated within recommended time frames. That combination makes integrations a recurring source of persistence for attackers.
Governance must include ownership, least privilege, rotation, revocation, and dependency mapping. It also means understanding what happens when a partner, agent, or automation is no longer trusted. The Ultimate Guide to NHIs frames this as a lifecycle problem, not a one-time configuration task, and that view is consistent with NIST Zero Trust Architecture, which assumes access must be continually verified and bounded. Organisations typically encounter integration risk only after a token is abused, at which point integration governance becomes operationally unavoidable to address.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret-heavy integrations and the need to inventory and secure access paths. |
| NIST CSF 2.0 | PR.AC-4 | Supports least-privilege management for system-to-system access paths. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero trust requires integrations to be continuously authorized, not implicitly trusted. |
| NIST SP 800-63 | AAL2 | Credential assurance concepts inform how strong an integration's delegated access should be. |
| OWASP Agentic AI Top 10 | A8 | Agent-to-tool integrations can expand blast radius when tool access is overbroad. |
Treat every integration as an NHI, inventory its credential, and enforce rotation and revocation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
