Why do GenAI integrations create security risk even when the model is approved?

Why This Matters for Security Teams

An approved model is only one component in a larger execution chain. The risk shifts when a GenAI integration is allowed to read production data, invoke tools, call APIs, or inherit permissions from the application around it. That turns a model review into a runtime exposure problem, where trust is created by connectors, tokens, and policy gaps rather than the model artefact itself. Guidance in the NIST Cybersecurity Framework 2.0 and the NIST AI 600-1 GenAI Profile both point to governance beyond the model boundary.

That is why NHI controls matter in GenAI work. If the integration is backed by an OAuth grant, service account, or API key with broad scope, the model can become the front end for a much larger permission set. NHIMG research on the State of Non-Human Identity Security shows how often organisations lack visibility into third-party access and over-privileged identities, which is exactly the environment these integrations inherit. In practice, many security teams encounter abuse only after an approved pilot is connected to real data and a wider set of permissions is already live.

How It Works in Practice

The secure way to assess a GenAI integration is to map the full access chain, not just the model selection. Start with what the agent, assistant, or embedded model can actually do at runtime: which connectors it can call, which data sources it can query, which secrets it can reach, and whether those privileges are static or time-bound. A model can be “approved” and still sit inside a workflow that is effectively over-privileged.

Current practice increasingly treats the integration as an identity problem. That means binding access to the workload through short-lived credentials, explicit scopes, and policy checks at the moment of request. NHI analysis such as the OWASP NHI Top 10 helps frame this as an agentic and workload-identity issue, not a model-quality issue. Pair that with controls such as:

• separate model approval from connector approval, so access changes require a second review
• use least privilege for service accounts, OAuth apps, and API tokens attached to the integration
• rotate or expire secrets quickly, especially where the model can invoke tools on behalf of users
• log every runtime request, including data source, tool call, and downstream permission used
• apply allowlists for actions, not only for prompts or model endpoints

NHIMG’s Top 10 NHI Issues is useful here because it reflects the operational reality that credential sprawl and visibility gaps are what turn a safe model into a risky integration. Security teams should treat each connector as a new trust boundary, because once the model can chain tools or inherit adjacent permissions, the approval decision is no longer anchored to the original model review. These controls tend to break down when the integration is added through low-code automation because permissions are inherited faster than they are reviewed.

Common Variations and Edge Cases

Tighter approval gates often slow deployment, so organisations have to balance speed against the risk of uncontrolled access expansion. That tradeoff is especially visible when teams want a model approved once and reused across multiple products, environments, or business units.

Best practice is evolving, but current guidance suggests that model approval alone is not enough for these cases:

• consumer tools that let users connect personal or departmental data sources after the model is approved
• multi-tenant platforms where one approved model is reused with different connector scopes in each tenant
• agentic workflows where the model can call tools, open tickets, or trigger downstream automations without human confirmation
• vendor-managed integrations where the organisation cannot fully inspect the secret handling or permission inheritance

The biggest edge case is when a “safe” model sits behind a broad integration layer that was never re-reviewed after the first launch. NHIMG’s Ultimate Guide to NHIs and related research make the operational point clearly: the model may be approved, but the identity, secret, and connector posture around it can drift. That is why security owners should revisit approval whenever the access chain changes, rather than assuming the original model sign-off still applies.

Related resources from NHI Mgmt Group

• Why do non-human identities create compliance risk even when policies exist?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do collaboration tools create such a large secrets risk?