Security teams should treat app-to-app integrations as production access paths, not simple automation. Start by inventorying every connected app, then classify the data, permissions, and trust relationships involved. Require approval for new integrations, monitor non-user activity, and apply least privilege to tokens, service accounts, and API keys so hidden access does not become persistent risk.
Why This Matters for Security Teams
Low-code and no-code platforms turn business users into integration builders, but every connector, webhook, OAuth grant, API key, and service account creates a production access path. That matters because app-to-app trust is often broader than the visible workflow. NHI Management Group research shows only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges, which is exactly the kind of hidden access these platforms amplify.
Security teams often misclassify these integrations as low-risk automation because no human logs in interactively. In practice, the opposite is true: the integration becomes the actor, and its permissions can persist long after the business owner has forgotten it exists. That is why app-to-app governance must be treated as identity governance, not just SaaS administration. The NIST Cybersecurity Framework 2.0 is useful here because it frames access, monitoring, and recovery as ongoing operational disciplines rather than one-time approvals.
In practice, many security teams discover risky integrations only after a vendor change, a leaked token, or a broad OAuth grant has already been abused.
How It Works in Practice
Governance starts with inventory. Security teams need a live register of every low-code and no-code integration, including the source app, destination app, data classes touched, auth method used, and the business owner accountable for it. That inventory should include shadow integrations created by employees outside formal IT processes. NHIMG guidance on Lifecycle Processes for Managing NHIs is directly relevant because these connections need onboarding, review, rotation, and offboarding like any other non-human identity.
Next, require approval for new integrations based on risk, not convenience. A connector that can read email, write files, and post to chat has a very different exposure profile than a read-only notification flow. At minimum, policy should classify integrations by data sensitivity, privilege level, external reach, and whether the platform can act without human re-authentication. The goal is to reduce standing trust and make hidden access observable.
- Prefer scoped OAuth grants over broad workspace-wide permissions.
- Use dedicated service accounts or workload identities for system-to-system access.
- Rotate tokens and API keys on a defined schedule, and revoke them on workflow retirement.
- Monitor non-user activity in logs, including unusual volume, new destinations, and off-hours execution.
- Require approval for third-party connectors that can access regulated or customer data.
Visibility is the control that holds the rest together. NHI Management Group research shows 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which means most teams are not governing the full blast radius. That is why the Top 10 NHI Issues and the Regulatory and Audit Perspectives sections matter in practice: auditors will ask who approved the integration, what it can access, and how quickly it can be removed. These controls tend to break down when business teams can create connectors faster than security can review them because the approval process becomes a bottleneck and shadow IT bypasses it entirely.
Common Variations and Edge Cases
Tighter integration control often increases friction for operations teams, so organisations have to balance speed against blast radius. That tradeoff becomes sharper in departments that rely on citizen development, where a single workflow may chain multiple apps and identity grants together.
One common edge case is delegated admin or vendor-managed automation. These integrations may be legitimate, but they should still use least privilege, documented ownership, and time-bounded access. Another issue is long-lived refresh tokens, which can make a supposedly simple connector function like a dormant backdoor if the account owner leaves or the app changes behaviour. Current guidance suggests treating any integration that can write data, trigger downstream actions, or create additional access as high risk, even if the platform labels it as low-code.
There is no universal standard for every low-code platform yet, so teams should anchor their policy in identity control, change management, and continuous review rather than platform-specific trust assumptions. The safest operating model is to assume the integration will outlive the original use case unless revocation is automated and tested. NHIMG’s research on OAuth supply chain breach patterns and shadow AI app exposure shows how quickly a trusted connector can become an enterprise-wide risk when governance is weak.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF, 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-01 | Inventory and visibility are core to governing app-to-app identities. |
| CSA MAESTRO | IAM-02 | Covers identity and access controls for machine and agentic workloads. |
| NIST AI RMF | Supports governance, accountability, and monitoring for automated decision paths. | |
| NIST CSF 2.0 | PR.AC-4 | Directly relates to access management for connected applications and tokens. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust supports verifying every integration request and limiting implicit trust. |
Catalog every integration, token, and service account before granting or renewing access.
Related resources from NHI Mgmt Group
- How should security teams govern citizen development in generative AI and low-code environments?
- How should security teams govern app-to-app connections in cloud-first environments?
- How should security teams govern third-party app access in Salesforce environments?
- How should security teams govern third-party app integrations without slowing cloud and SaaS automation?
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
