Genai risk is exposing gaps in enterprise identity governance

At a glance

What this is: Lasso Security’s guide says GenAI is expanding enterprise attack surface through shadow use, data leakage, insecure integrations, and weak auditability.

Why it matters: For IAM, NHI, and human identity teams, the practical problem is that governance, monitoring, and access controls built for stable systems do not map cleanly to prompt-level AI activity.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read Lasso Security's guide to CISO pain points in GenAI risk

Context

GenAI risk is not just a model-security problem. It is an identity governance problem because employees, developers, and business units are now creating and using AI-enabled access paths faster than security teams can inventory or control them. In practice, that means prompt-level interactions, plugin authorisations, API integrations, and unsanctioned tools can all become part of the enterprise attack surface.

Traditional IAM and monitoring controls were designed for relatively stable users, service accounts, and system boundaries. The article’s core point is that GenAI breaks that assumption by introducing dynamic, probabilistic, and partially invisible workflows that are hard to classify, much less govern, under existing policy models.

In other words, the security issue is not only what the model knows. It is who can reach it, what it can reach in turn, and how much of that access escapes review. That is why GenAI governance now sits across human behaviour, NHI controls, and broader access management discipline.

Key questions

Q: How should security teams govern shadow AI in the enterprise?

A: Start by inventorying every sanctioned and unsanctioned GenAI tool, then assign an owner, a data classification boundary, and a logging requirement. Shadow AI becomes a governance issue when security cannot see prompts, outputs, or linked data sources. Without a register, policy enforcement and incident response both fail because the system is effectively unaccountable.

Q: Why do GenAI plugins and APIs create identity risk?

A: They introduce extra trust boundaries that can be over-permissioned, weakly authenticated, or left without clear revocation ownership. If a model can act through a service account or API token, then identity scope matters as much as model behaviour. The risk is not only data exposure, but backend abuse through a credential path that was never tightly governed.

Q: How can teams know whether GenAI monitoring is actually working?

A: Look for prompt-level telemetry, retrieval traces, output logs, and downstream action records that can be joined into a single event chain. If the organisation can only see model uptime or platform health, it is not seeing the security-relevant layer. Effective monitoring answers who used the tool, what data entered it, and what happened next.

Q: What should organisations do when GenAI is embedded in code and workflows?

A: Apply secure SDLC and third-party dependency controls to AI outputs, including review for bugs, secrets, prompt-injection artifacts, and unsafe API use. AI-assisted code is not exempt from normal engineering governance. The practical standard is the same as any external input: inspect, test, approve, and monitor before it reaches production.

Technical breakdown

Shadow AI and prompt-level visibility gaps

Shadow AI emerges when teams adopt chatbots, copilots, or embedded GenAI features without central oversight. The technical issue is that many of these interactions happen outside the telemetry planes used by SIEM, DLP, and endpoint controls, so security teams cannot reliably see prompts, outputs, or linked data sources. That makes detection and auditability difficult even when the tool is internally deployed. Visibility must therefore extend to the interaction layer, not just the application layer, if organisations want to understand what data entered the model and where the output went.

Practical implication: map sanctioned and unsanctioned GenAI usage to identify where prompt-level logging is absent.

Plugins, APIs, and over-permissioned access paths

Modern GenAI tools increasingly rely on plugins and third-party APIs to act on data or trigger workflows. Each integration creates an additional identity and authorisation boundary, and weak authentication or excessive permissions can let an attacker abuse backend systems through the model path. This is an NHI problem as much as an application problem because the control weakness often sits in the service-to-service credential or API entitlement, not in the model itself. Treat every extension as a scoped trust relationship with its own lifecycle.

Practical implication: review every model integration for credential scope, token exposure, and revocation ownership.

Why deterministic security controls struggle with GenAI

Legacy security tooling assumes predictable events, fixed rules, and well-bounded workflows. GenAI systems instead generate outputs probabilistically and can change behaviour based on prompt content, retrieval context, and external tool access. That makes traditional signature-based or policy-only controls insufficient for detecting prompt injection, jailbreaks, data poisoning, or hallucination-driven misuse. The architecture problem is not simply that the threat is new. It is that the control plane was not built to inspect natural-language intent and model-mediated action in real time.

Practical implication: pair model-aware detection with access governance so security can observe both intent and action.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI is a governance failure before it is a detection failure. When employees and business units adopt GenAI outside central oversight, the organisation loses the ability to define what is sanctioned, what is monitored, and what data is at risk. That is not just operational drift. It is a governance gap that weakens accountability across human identity, machine identity, and access policy. The practitioner conclusion is that inventory and ownership must come before enforcement.

GenAI plugin ecosystems create an identity perimeter that most enterprises do not govern yet. The article’s API and plugin examples show that the real exposure often sits in over-permissioned credentials, weak authentication, and unclear revocation responsibility. Those are classic NHI weaknesses presented through a new interface. The field should treat every model integration as a distinct trust boundary with lifecycle obligations attached. The practitioner conclusion is that entitlement review must extend to model-connected services.

Prompt-level activity exposes the limits of legacy monitoring architecture. SIEM, DLP, and endpoint controls still matter, but they do not see everything that happens inside a GenAI interaction. That is why model-aware observability, traceability, and policy enforcement are becoming core controls rather than optional enhancements. The industry implication is that AI governance is now a control-plane problem, not a documentation exercise. The practitioner conclusion is that security teams need telemetry where the decision is made, not only where the data finally lands.

GenAI security is converging with NHI governance because the same trust assumptions are being reused in a new form. The article shows employees, developers, and tools all operating through access paths that can be copied, embedded, or forgotten. That pattern mirrors longstanding NHI issues such as unmanaged credentials and excessive privilege, but with faster proliferation and less transparency. The practitioner conclusion is that GenAI programmes should be governed with the same lifecycle discipline applied to service accounts and API tokens.

Traceability is now a compliance requirement, not a luxury feature. The article notes that organisations struggle to show what an LLM saw, generated, or who accessed it, which means auditability becomes part of operational readiness. That aligns with NIST CSF-style governance expectations and sector-specific accountability models. The practitioner conclusion is that if the organisation cannot reconstruct AI interactions, it cannot defend them.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• From our research: Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• As GenAI expands the number of machine-mediated access paths, the governance baseline should be lifted with Top 10 NHI Issues and the lifecycle guidance in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Shadow AI will continue to outpace traditional discovery unless security teams move from application inventories to interaction inventories. The real programme signal is whether the organisation can trace a prompt back to a user, a dataset, and a downstream action. Without that chain, AI governance remains partially fictional.

As GenAI becomes embedded in engineering and business workflows, the control set will look increasingly like NHI governance with stronger traceability requirements. In practice, that means service account discipline, API scope review, and prompt logging must be managed together, not as separate workstreams.

The security bar is shifting from preventing AI use to governing AI use. Organisations that can classify tools, tie them to owners, and verify access paths will be better positioned to align with NIST Cybersecurity Framework 2.0 and model-specific controls.

For practitioners

• Inventory sanctioned and unsanctioned GenAI usage Build a single register of chatbots, copilots, embedded AI features, plugins, and internal model endpoints so security can assign ownership and logging requirements.
• Extend logging to prompt and retrieval activity Capture prompts, retrieved source data, model outputs, and downstream actions so investigators can reconstruct what the system saw and did.
• Review AI-connected service accounts and API tokens Check every model integration for scope, ownership, and revocation path, especially where the model can call backend systems or third-party APIs.
• Apply secure SDLC controls to AI-generated code Treat model-suggested code like third-party input, with review for vulnerabilities, secret leakage, malicious constructs, and unsafe dependency use.

Key takeaways

• GenAI creates an identity governance problem because it expands who can act, what they can reach, and how much of that activity is visible to security teams.
• The scale of the underlying NHI problem is already severe, with 96% of organisations storing secrets outside secrets managers and only 5.7% having full service-account visibility.
• Security teams should treat model access, integrations, and prompt telemetry as part of the same governance surface before AI adoption outruns oversight.

Key terms

• Shadow Ai: Undiscovered or unmanaged AI tools, workflows, or embedded model features operating outside central security oversight. In practice, the risk is not only unsanctioned use but also the loss of logging, ownership, and policy enforcement across prompts, outputs, and connected data sources.
• Prompt-Level Telemetry: Security logging that records the inputs, retrieved context, outputs, and downstream actions of a GenAI interaction. It matters because traditional platform or endpoint logs often miss the decision layer where data exposure, misuse, or policy violations actually occur.
• Model-connected Service Account: A non-human identity that authorises a GenAI system to reach data, APIs, or backend services. The account can look ordinary from an IAM perspective, but the exposure grows when the model can invoke it dynamically and the ownership or revocation path is unclear.
• Retrieval-augmented generation: A GenAI pattern that supplements model output with external or proprietary data sources at runtime. It improves relevance, but it also widens the governance surface because the system now depends on data access, retrieval controls, and traceability for what was exposed to the model.

Deepen your knowledge

GenAI governance and NHI control boundaries are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to bring AI use under identity discipline without slowing delivery, it is worth exploring.

This post draws on content published by Lasso Security: The CISO’s Guide to GenAI Risks: Unpacking the Real Security Pain Points. Read the original.