When does GenAI create more identity risk than business value?

GenAI creates more identity risk than value when the organisation cannot explain who or what has access, why that access exists, and how quickly it can be revoked. If the deployment depends on permanent credentials, broad roles, or weak monitoring, the operational burden already exceeds the security margin.

Why This Matters for Security Teams

GenAI stops being a net benefit when it is deployed with permanent access, unclear ownership, or no reliable revocation path. At that point, the model is not just generating text or code; it is acting through identities that can read data, call tools, and move across systems. That shifts the question from “what can it do?” to “what can it do without anyone noticing?” Current guidance from the NIST AI 600-1 GenAI Profile and NIST Cybersecurity Framework 2.0 points security teams toward traceability, access governance, and continuous monitoring rather than static trust. NHIMG research shows why that matters: only 5.7% of organisations have full visibility into their service accounts, and once identity sprawl is hidden, risk rises faster than business value. See the Ultimate Guide to NHIs and Top 10 NHI Issues for the governance patterns behind that failure. In practice, many security teams encounter the real cost of GenAI only after an exposed token, overbroad connector, or unreviewed agent permission has already created an incident.

How It Works in Practice

The practical test is whether the GenAI workload can be governed like a bounded identity or whether it behaves like an autonomous actor with changing intent. For static chat copilots, conventional RBAC may be sufficient if the model only responds within tightly scoped workflows. For agents, that same model often fails because the system can decide when to call tools, which tools to chain, and how to persist across tasks. That is why intent-based authorisation is gaining traction: access is evaluated at runtime against the task the agent is trying to complete, not just a preassigned role. The emerging pattern is to pair that with NIST AI 600-1 GenAI Profile controls and the operational discipline described in 52 NHI Breaches Analysis.

• Issue JIT credentials per task, not permanent secrets, so access expires when the action ends.
• Bind the agent to workload identity rather than shared credentials, using cryptographic proof of what it is.
• Use policy-as-code to evaluate each request in context, including data sensitivity, destination system, and approval state.
• Log tool calls, secret use, and privilege changes so revocation is fast when behaviour drifts.

Operationally, this means secrets should be short-lived, narrowly scoped, and automatically revoked on completion. It also means that “approved once” is not a durable control for a system that can laterally move, chain tools, or retry actions at machine speed. NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now documents how quickly exposed credentials are abused, which is why static keys are especially dangerous in AI pipelines. These controls tend to break down when agents are embedded in legacy integrations with shared service accounts, because the environment cannot distinguish one task, one tool call, or one operator intent from another.

Common Variations and Edge Cases

Tighter controls often increase latency and operational overhead, so organisations have to balance safety against developer friction and runtime complexity. That tradeoff is real, especially where a GenAI feature is read-only, low-risk, and heavily sandboxed. In those cases, broad concern about “AI risk” can lead to unnecessary control layering. But once a workload can write records, trigger workflows, or access customer data, current guidance suggests treating it as a governed identity problem rather than a feature toggle. There is no universal standard for agent authorisation yet, but best practice is evolving toward context-aware decisions, JIT secrets, and stronger workload identity boundaries.

Some edge cases deserve special caution. Multi-agent systems can amplify small permission errors because one agent may delegate to another, creating an access path no single reviewer anticipated. Long-running background agents are also harder to secure because their credentials must survive long enough to do work, yet not long enough to become standing privilege. For organisations comparing this with broader GenAI governance, OWASP NHI Top 10 is useful for agentic risk patterns, while DeepSeek breach shows how exposed secrets and model-adjacent data can turn a productivity system into a liability. The practical rule is simple: if the GenAI system cannot be explained, bounded, and revoked quickly, the organisation is paying for automation while absorbing unmanaged identity exposure.

Related resources from NHI Mgmt Group

• When do banking APIs become an identity risk instead of a business enabler?
• Should organisations use business impact to prioritise identity risk?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?