LLM cybersecurity now depends on governing AI agents as identities

At a glance

What this is: Living Security Human Risk Management Platform argues that LLM risk now extends beyond prompt abuse to the governance of AI agents as non-human identities with system access.

Why it matters: IAM, PAM and NHI teams need to treat agent access, delegated actions and oversight as a single governance surface because conventional human-centric controls miss how AI agents behave in production.

Context

Large language models are not just content generators. In enterprise use, they are increasingly wrapped in AI agents that can access systems, process data and trigger actions, which creates a governance problem that looks more like identity and privilege management than classic application security.

The security gap is that many programmes still separate model risk, user risk and access control. Once an AI agent can act inside business workflows, those boundaries break down, and identity-aware governance becomes the practical way to control machine behaviour without assuming human judgement will be present.

Key questions

Q: How should security teams govern AI agents that browse and transact on behalf of users?

A: Security teams should govern AI agents as delegated actors with narrow, task-scoped permissions, not as enhanced browsers. The right model is to bind access to the specific action being performed, preserve auditability at the transaction layer, and separate machine identity from the human principal wherever possible.

Q: Why do AI agents create more risk than standard LLM evaluations suggest?

A: AI agents create more risk because the dangerous part is often what they do after the response is generated. A model can produce safe-looking text while still making an unsafe database query, file write, payment, or email action through connected tools. That is why evaluation must follow the action path and verify real credentials, real tools, and real permissions.

Q: What are the signs that AI code assistant use is becoming a security problem?

A: Warning signs include developers bypassing security policy to use assistants, repeated acceptance of outdated or unsafe recommendations, and the appearance of sensitive data in generated output. Another signal is when teams use these tools informally outside approved workflows, creating a shadow LLM problem that security and compliance teams cannot see or govern effectively.

Q: What is the difference between securing LLMs and securing AI agents?

A: LLM security focuses on inputs, outputs, and data leakage at the model layer. AI agent security adds the execution layer, where tool use, privilege boundaries, and identity controls determine what the system can actually do. In practice, agents require both content controls and hard authorization controls.

Technical breakdown

Why AI agents behave like non-human identities

An AI agent is not the same thing as an LLM. The model generates output, but the agent is the runtime system that uses that output to decide whether to call tools, query data or continue a task. That makes the agent a non-human actor with a usable identity surface: it authenticates, inherits permissions, accesses data and can be delegated authority. Traditional security tooling often monitors users or workloads in isolation, but an agent can sit between them and blur those boundaries. The governance problem is not just what the model says, but what the agent is allowed to do with that output.

Practical implication: Treat agent identity, authorization and auditability as first-class controls rather than assuming model safeguards alone are enough.

Prompt injection and poisoned data exploit trust boundaries

The article points to prompt injection, jailbreaks and training-data poisoning as key risks because they exploit the trust boundary around the model and the agent using it. Prompt injection works by smuggling instructions into content the system thinks is benign, while poisoning contaminates the data or model behaviour upstream. In both cases, the weak point is not raw computation but the lack of robust input trust, content separation and policy enforcement across the AI lifecycle. Once an agent can act on contaminated instructions, the attack becomes operational rather than theoretical.

Practical implication: Validate inputs, separate trusted from untrusted context, and constrain agent actions with policy enforcement that cannot be overridden by model output.

Why human-centric monitoring misses agentic risk

The article frames AI agents as part of an expanded attack surface because they interact with employees, data and systems in ways that existing security stacks do not naturally correlate. Human risk programmes look for behaviour, identity and access anomalies in people, while logging and EDR tools often see device or application events. An AI agent can cross those boundaries in a single workflow, which means risk signals get fragmented. That is why the article emphasises unified visibility across employee behaviour, identity systems and AI activity. Without that correlation, the organisation sees the consequences after the agent has already acted.

Practical implication: Correlate AI activity with identity and access signals so that anomalous agent behaviour is visible before it becomes a downstream incident.

Threat narrative

Attacker objective: The attacker aims to turn the AI agent’s trusted access into an execution path for data exposure, workflow abuse or automated deception.

1. Entry occurs when a malicious prompt, poisoned training input or compromised integration reaches the AI agent through normal enterprise workflows.
2. Credential and data access follow when the agent uses its granted permissions to query systems, retrieve content or invoke tools on the attacker’s behalf.
3. Impact emerges when the manipulated agent leaks sensitive information, executes unintended actions or amplifies phishing and social engineering at scale.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agents are now governance objects, not just productivity features. Once an agent can access systems, query data and act inside workflows, it acquires an operational identity that needs explicit authorization, oversight and revocation. The article is right to frame this as a human risk problem, but the deeper issue is identity governance for a non-human actor. Practitioners should manage agents as scoped principals, not as user interface enhancements.

Prompt injection is an identity and trust problem before it is a model problem. The model only becomes dangerous when untrusted input can cross into trusted execution paths. That means the failure mode is not simply bad text generation, but broken separation between content, instruction and authority. Security teams should read this as a warning that trust boundaries around AI need the same discipline applied to delegated access elsewhere in the stack.

Unified visibility matters because agentic risk is cross-domain by design. The article connects identity, behaviour and threat intelligence because the signal is fragmented across systems that were never built to explain non-human actions end to end. That makes agent observability a control requirement, not a reporting nicety. If the organisation cannot reconstruct what an agent saw, used and changed, it cannot govern it credibly.

AI governance debt will accumulate fastest where agents inherit human trust by default. Many programmes will allow agents to inherit access because that is the fastest route to adoption, then struggle to prove who authorised what later. This creates a named concept worth tracking: delegated agent trust gap. The gap appears when humans keep the accountability but the machine executes the action. Practitioners should close it with explicit approval boundaries and revocation paths.

From our research library:

• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Delegated agent trust gap: enterprise AI programmes will fail first where human approval and machine execution are loosely coupled. Security teams should expect the control burden to move from prompt hygiene alone to explicit agent authorization, logging and containment, especially when agents can reach internal systems.

The most practical governance shift is to treat agent activity as part of the identity fabric rather than a separate AI exception. That means correlating who requested the action, which agent executed it and what data or tool the agent touched, then using that evidence to limit blast radius before it expands.

For practitioners

• Define explicit agent identities and scopes Assign each AI agent a distinct identity, documented purpose and least-privilege permission set so access can be reviewed and revoked independently of the human user who requested it.
• Separate trusted instructions from untrusted content Sanitize prompts, retrieved documents and user inputs before they can influence tool use, and block agents from treating embedded instructions as policy.
• Log every agent action with identity context Capture the agent identity, trigger, tool call, data source and downstream action in logs that can be correlated with IAM and SOC telemetry.
• Test the agent for prompt injection paths Red-team the workflows where agents read email, tickets, chat or documents, because those are the easiest places for malicious instructions to enter the control plane.
• Create revocation and containment playbooks for agents Predefine how to disable an agent, withdraw its tokens and halt delegated actions when it behaves outside its approved scope.

Key takeaways

• AI agents introduce a non-human identity problem into LLM security because they can access systems and perform actions, not just generate text.
• The main failure mode is trust boundary collapse, where untrusted prompts or poisoned inputs drive real tool use and data access.
• Identity-aware governance, revocation and audit logging are the controls most likely to limit agent abuse in production.

Key terms

• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• 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.
• Delegated trust: Delegated trust is the decision to let another system or organization issue, validate, or transmit access on your behalf. It is common in cloud and SaaS environments, but it becomes risky when scope, duration, and revocation are not tightly controlled. In NHI governance, delegated trust must be explicit and continuously reviewable.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and identity lifecycle fundamentals. It helps practitioners connect identity controls to the non-human actors now shaping modern security programmes.