By NHI Mgmt Group Editorial TeamDomain: AI SecuritySource: Living Security Human Risk Management PlatformPublished July 14, 2026

TL;DR: As organizations adopt LLMs, Living Security Human Risk Management Platform argues that the real security issue is not just model abuse but the expansion of the attack surface through AI agents, which behave like non-human actors and require identity-aware governance. The implication is that security teams must treat AI access, prompt handling, and human-machine interaction as one control problem, not separate domains.


At a glance

What this is: This is an analysis of LLM security risks and defenses, with the central finding that AI agents expand the attack surface as non-human actors that traditional security tools cannot fully see.

Why it matters: It matters because IAM, PAM, and NHI programmes increasingly have to govern AI-driven access, human interaction with models, and the credentialed systems those agents touch.

By the numbers:

👉 Read Living Security Human Risk Management Platform's analysis of AI cybersecurity for large language models


Context

Large language model security is no longer only about model quality or prompt safety. Once an LLM can access systems, process data, and trigger downstream actions, it becomes part of the access layer and inherits the governance problems that come with any privileged software path, especially where AI agents operate alongside human users.

The article's core concern is that AI agents behave like non-human actors in the enterprise, which creates an identity and access problem as much as a cyber one. That makes the boundary between LLM security, NHI governance, and human risk management especially important for security teams trying to control real exposure rather than just model outputs.


Key questions

Q: What breaks when AI agents are given access without identity governance?

A: What breaks is accountability. The organisation may see actions, logs, and alerts, but it cannot reliably tie them to a governed identity with clear scope and revocation. That creates uncontrolled blast radius, especially when agents can reach sensitive systems through shared tokens, delegated service accounts, or broad API access.

Q: Why do LLMs complicate IAM and PAM programmes?

A: Because they blur the line between a user, an application, and an acting system. An LLM may sit inside a workflow, inherit credentials, and execute actions that look operational rather than interactive. That means IAM has to account for delegation paths, while PAM must consider ephemeral, task-scoped privilege instead of only human admin sessions.

Q: What do security teams get wrong about prompt injection defence?

A: They often assume better blocklists will solve the problem, but obfuscation simply changes the shape of the payload. Real defence requires examining meaning across the full interaction, including retrieved content and model responses. If the control cannot interpret intent, it will keep missing the attack class it is meant to stop.

Q: How should organizations approach the governance of AI agents?

A: Organizations should adopt a governance framework that incorporates continuous visibility, adaptive IAM practices, and stringent policy-based controls. This ensures that all agent actions are tracked, authorized appropriately, and assessed for compliance.


Technical breakdown

Why LLMs create a new non-human identity problem

A large language model becomes a governance issue when it is connected to tools, data, or workflows. At that point it is not just generating text, it is issuing actions through credentials, APIs, or delegated permissions. That changes the risk from content integrity alone to identity and authorisation, because the model can be tricked, over-scoped, or embedded in a workflow with more privilege than it should have. Traditional controls designed for human authentication and periodic access review do not fully capture this runtime behaviour.

Practical implication: Map every model-connected workflow to an owning identity, permission set, and revocation path before granting production access.

Prompt injection, jailbreaking, and data poisoning explain most model abuse

Prompt injection hides malicious instructions inside seemingly ordinary input, while jailbreaking uses crafted prompts to override guardrails. Data poisoning goes deeper by corrupting the information a model learns from, which can distort outputs or leak sensitive content later. These are different mechanisms, but they share one consequence: the model begins acting on attacker influence rather than trusted policy. In practice, the weakness is not only the model itself but the untrusted text, data, and dependencies feeding it.

Practical implication: Treat all model inputs, training data, and retrieved context as hostile until they are validated and isolated.

AI security depends on controlling the full AI lifecycle

The article points to an end-to-end lifecycle problem. Training data, model deployment, runtime integrations, and post-deployment monitoring are all part of the security surface. If role-based access controls are loose, if logging is weak, or if adversarial testing is missing, attackers gain multiple paths to influence the system. For identity teams, the key lesson is that lifecycle governance must include both the people who can configure the model and the machine identities the model can use at runtime.

Practical implication: Apply lifecycle controls that cover data sourcing, access scoping, runtime monitoring, and periodic adversarial testing.


NHI Mgmt Group analysis

AI agents are now an identity governance problem, not just an AI security problem. Once an LLM can access systems, call tools, or act on behalf of a user, it becomes a non-human identity that must be governed like any other privileged actor. That means ownership, scope, and revocation matter as much as prompt safety. Teams that keep these concerns separate will miss how quickly model access becomes operational access.

Prompt injection is best understood as identity misuse through untrusted text. The attack does not need to break cryptography to succeed. It exploits the fact that the model may accept external instructions as if they were authorised context. For practitioners, that means context boundaries, retrieval controls, and tool permissions need to be designed as one control plane, not three disconnected ones.

LLM supply chain risk creates governance debt across the AI lifecycle. Training data, pre-trained components, third-party libraries, and runtime integrations can all be compromised in different ways. When those layers are treated as isolated procurement or engineering tasks, accountability disappears. Security leaders should treat model provenance and runtime trust as part of the same assurance model.

Human risk management and NHI governance now overlap at the point of delegation. The article's framing is useful because it shows how people and AI agents interact in the same workflows, but the control failure usually appears when delegated access is broader than the task. That is where IAM, PAM, and AI governance meet. Practitioner focus should be on task-scoped access with clear human oversight and machine identity traceability.

Model abuse reveals a named concept: AI access sprawl. This is the gradual expansion of model permissions, data reach, and action rights across too many workflows without a matching governance model. It creates hidden privilege accumulation, especially when teams add integrations faster than they can review them. The practical conclusion is to inventory and shrink AI access before it becomes entrenched.

What this signals

AI access sprawl is the operational risk that emerges when model integrations, delegated permissions, and runtime tools multiply faster than governance can track them. For security leaders, that means AI projects should be reviewed like identity programmes, not just application features. The relevant standards conversation spans the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026.

The programme signal to watch is whether AI access can be described in the same language as human access: owner, purpose, scope, approval, and revocation. If those fields are missing, the organisation is already operating with hidden privilege. Security teams should inventory AI-connected credentials and align them with the Ultimate Guide to NHIs , Key Challenges and Risks.

Identity and AI governance will converge around runtime control rather than model content alone. That shift pushes teams toward stronger logging, tighter task scoping, and more explicit review of machine-to-machine delegation, especially where AI agents touch sensitive data or production systems.


For practitioners

  • Define machine identities for every LLM integration Assign each model-connected workflow a named owner, explicit permissions, and a documented revocation process. Separate development, testing, and production credentials so an agent cannot inherit broad access by default.
  • Restrict tool use to task-scoped permissions Limit each AI agent to the smallest tool set and data path needed for the approved workflow. Use short-lived credentials where possible and remove standing access to production systems.
  • Validate all prompts, retrieved context, and training inputs Sanitise untrusted text before it reaches a model, and isolate external content from privileged system instructions. Apply review and filtering to retrieval sources, datasets, and uploads that could carry malicious instructions.
  • Add adversarial testing to AI release gates Test models for prompt injection, jailbreaking, poisoning, and unauthorised tool invocation before production deployment and after major workflow changes. Treat failed tests as release blockers, not tuning issues.

Key takeaways

  • LLM security becomes an identity problem once models can act through credentials, tools, and delegated workflows.
  • Prompt injection, jailbreaking, and poisoning are different attack paths, but they all exploit weak trust boundaries around model inputs and actions.
  • Security teams need lifecycle governance for AI access, including ownership, scope control, monitoring, and revocation before deployment scales further.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 address the attack surface, NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10Prompt injection and tool misuse are central to the article's threat model.
NIST AI RMFGOVERNThe article centres on accountability, ownership, and lifecycle oversight for AI-enabled systems.
NIST CSF 2.0PR.AC-4The article emphasises least-privilege access for model-connected workflows and agents.
NIST SP 800-53 Rev 5IA-5Credential management is directly relevant to AI systems that access tools and sensitive data.
ISO/IEC 27001:2022A.5.15Access control governance is relevant where AI systems reach sensitive information.

Assign governance ownership for AI access, risk review, and release approvals across the model lifecycle.


Key terms

  • Large Language Model: A large language model is an AI system trained on large text datasets to generate and transform language based on statistical patterns. In identity security, its value depends on whether the output is accurate enough to support search, reporting, or analysis without introducing hallucination, leakage, or inconsistent results.
  • Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
  • Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
  • AI Access Sprawl: AI access sprawl is the uncontrolled growth of permissions, data reach, and tool access granted to AI systems over time. It usually appears when teams add integrations faster than they document ownership, review privileges, or define a clean revocation path.

What's in the full article

Living Security Human Risk Management Platform's full article covers the operational detail this post intentionally leaves for the source:

  • Step-by-step examples of how the platform correlates employee behavior, identity signals, and AI activity across a single risk view
  • Specific examples of automated remediation such as micro-training, quarantine actions, and alert triage workflows
  • Discussion of how the Human Risk Management model is applied to both human and non-human actors in practice
  • Practitioner-facing guidance on how to start building AI-native risk controls into an existing security programme

👉 The full Living Security Human Risk Management Platform article covers the model, workflow, and control examples in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle basics. It helps security and IAM practitioners apply identity discipline to AI-driven access and other non-human systems.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 21, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org