App-to-app trust is the set of permissions and delegated relationships that allow one software system to act on behalf of another. It is a core NHI risk because it often persists longer than the original business need and is rarely visible in basic application inventories.
Expanded Definition
App-to-app trust describes the permissions, credentials, and delegated authority that let one application or service act for another in production workflows. In NHI security, it includes service accounts, API keys, OAuth tokens, workload identities, and agent permissions that can outlive the business task they were created for.
Usage in the industry is still evolving because some teams treat app-to-app trust as an IAM design pattern, while others treat it as a runtime governance problem. The practical difference matters: the first focuses on how trust is issued, and the second on how that trust is continuously verified, limited, and revoked. That distinction maps well to zero trust principles described in NIST Cybersecurity Framework 2.0 and to broader NHI lifecycle guidance in Ultimate Guide to NHIs.
The most common misapplication is assuming a successful authenticated call means the underlying trust is still justified, which occurs when long-lived credentials are reused after the original integration or project has changed.
Examples and Use Cases
Implementing app-to-app trust rigorously often introduces operational friction, because every allowed connection must be justified, monitored, and sometimes re-authenticated, requiring organisations to weigh automation speed against exposure from overbroad delegation.
- A payment microservice calls an order service using a scoped token, but the scope is broader than the transaction path and should be reduced to the minimum required claims.
- A CI/CD pipeline uses a deployment secret to push artifacts into production, and that secret must be rotated and offboarded when the pipeline changes ownership, as emphasised in Ultimate Guide to NHIs.
- An AI agent invokes internal tools through MCP, but each tool call still needs bounded authorization, logging, and revocation paths rather than broad inherited trust.
- A backend job uses mutual TLS to authenticate to an API, aligning the connection model with identity-centric controls discussed in NIST Cybersecurity Framework 2.0.
- A third-party analytics service is granted access to customer records, but the integration should be reviewed like any other NHI dependency because it extends trust beyond the internal boundary.
Why It Matters in NHI Security
App-to-app trust becomes a security issue when it is invisible, persistent, or over-scoped. Unlike human logins, these relationships often run continuously and are embedded in application code, orchestration layers, and secrets stores, making them hard to inventory and even harder to retire cleanly. NHI governance is especially important because NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts according to Ultimate Guide to NHIs.
That gap matters because app-to-app trust can become a lateral movement path after one credential is exposed, one service is deprecated, or one integration is acquired through a merger. The right control model combines least privilege, rotation, offboarding, and continuous review, which is consistent with the governance direction of NIST Cybersecurity Framework 2.0. When app-to-app trust is treated as permanent plumbing, compromise is often discovered only after abnormal API activity or a failed audit reveals that a forgotten integration still has production access, at which point the trust relationship itself 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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret, token, and workload identity misuse in app-to-app trust. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control applies directly to delegated application authority. |
| NIST Zero Trust (SP 800-207) | 3.4 | Zero Trust requires continuous verification of workload and service-to-service access. |
Inventory each app trust path, then reduce scope, rotate credentials, and revoke unused relationships.
