A shadow app-to-app connection is an application integration that exists outside normal governance or monitoring. These links often rely on API keys, tokens, or service credentials that are never fully tracked, making them difficult to review, revoke, or detect when they become risky.
Expanded Definition
shadow app-to-app connections are unofficial or poorly governed integrations between software systems, typically created to move data, trigger workflows, or call internal APIs without passing through approved architecture, review, or monitoring. In NHI security, the risk is not the connection itself but the invisible identity it depends on: API keys, OAuth tokens, certificates, or service credentials that may be stored in scripts, CI/CD jobs, configuration files, or embedded code.
Definitions vary across vendors, but the practical distinction is clear: a sanctioned integration has ownership, inventory, logging, and revocation paths, while a shadow connection often has none of those controls. That makes it harder to apply the identity lifecycle discipline described in the Ultimate Guide to NHIs and harder to align with governance expectations in the NIST Cybersecurity Framework 2.0.
The most common misapplication is treating any machine-to-machine traffic as a normal integration, which occurs when teams focus on application uptime but do not record the credentials, owners, or approval path behind the connection.
Examples and Use Cases
Implementing app-to-app governance rigorously often introduces friction for developers and platform teams, requiring organisations to weigh release speed against the cost of inventory, approvals, and periodic review.
- A data pipeline uses a hardcoded API key in a script to pull customer records from a SaaS platform, but no central team knows who owns the key or when it was last rotated.
- A finance microservice calls an internal ledger API with a long-lived token stored in a build variable, creating a connection that works in production but never appears in the service catalog.
- A third-party automation tool exchanges files with an internal system through a service account created during a pilot project, then left active after the project ended.
- A developer adds a temporary webhook integration for testing, but the endpoint and credential remain active after deployment, bypassing normal change control.
These patterns are common in environments where integration sprawl outpaces governance. The Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which helps explain why shadow connections persist. For identity assurance and access control planning, the NIST Cybersecurity Framework 2.0 provides a useful governance anchor.
Why It Matters in NHI Security
Shadow app-to-app connections are a high-value blind spot because they often carry standing access, broad permissions, and weak lifecycle controls. Once an attacker discovers an overlooked token or service credential, they may move laterally, exfiltrate data, or impersonate trusted internal services without triggering human MFA prompts. This is why the issue is not just integration hygiene, but NHI governance.
NHI Mgmt Group research shows that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. Those numbers are especially relevant when a shadow connection exists outside inventory, because revocation, rotation, and audit response become slow or impossible. The security control problem is compounded when secrets are stored outside managed vaults or embedded directly in code, a pattern also documented in the Ultimate Guide to NHIs.
Organisations typically encounter shadow app-to-app risk only after a token leak, service outage, or unauthorized data transfer, at which point the connection 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 | Shadow connections hide credentials and bypass lifecycle controls. |
| NIST CSF 2.0 | PR.AA-01 | Governed access management requires known identities and accountable connections. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit verification for each app-to-app request. | |
| NIST SP 800-63 | AAL2 | Credential assurance principles inform how service identities should be protected. |
| OWASP Agentic AI Top 10 | GENAI-03 | Untracked tool connections mirror risky agent tool-use and delegated access patterns. |
Treat every service connection as untrusted until authenticated, authorized, and continuously validated.
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
