LLM security in 2025 is now a data and identity problem

At a glance

What this is: This is an analysis of how LLM security risks in 2025 are being driven by sensitive data exposure, access control failures, and excessive agency in AI workflows.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern not only people and service accounts, but also AI-connected identities, permissions, and data access paths.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Sentra's analysis of LLM security risks in 2025

Context

LLM security now sits at the intersection of data governance, identity control, and AI operational risk. As RAG, fine-tuning, and tool-calling become common, the main failure mode is no longer just model output quality. It is whether sensitive data, credentials, and permissions are governed well enough to stop exposure during training and inference.

That shift matters for IAM practitioners because AI systems increasingly depend on the same access patterns used by humans, service accounts, and NHIs. Once an LLM can reach internal data stores or trigger actions through connected tools, traditional review cycles become too slow to prevent misuse or data leakage.

Sentra’s article is typical of the current market conversation: the technology problem is presented as a data security issue, but the real control challenge is identity and access governance around the model lifecycle.

Key questions

Q: How should security teams govern AI models that can call tools and access data?

A: Security teams should govern AI models as non-human identities with named owners, limited scope, short-lived credentials, and continuous authorization. The critical shift is to treat every tool call, data read, and update path as a privileged action that can be logged, revalidated, and revoked. Without that discipline, model risk becomes identity risk.

Q: Why do conversational AI systems create new identity and access risks?

A: Because they can combine data retrieval, decision-making, and execution in a single interaction. That collapses the gap between information access and business action, which traditional IAM and security tools were not built to manage. The result is higher exposure when the system can modify records or disclose sensitive guest data.

Q: What do organisations get wrong about securing LLMs connected to tools?

A: Many teams focus on content moderation and miss the execution layer. An LLM may still call APIs, change records, or expose data even when the text output looks harmless. The real control boundary is the tool and the permission model around it, not the chat interface alone.

Q: How can security teams tell whether AI agent access is drifting out of scope?

A: Look for agents touching systems, data sets, or tools that are outside the intended task boundary, especially when those actions are not part of the approved workflow. Behavioural baselines, entitlement logs, and cross-system correlation are the key signals. If the agent can act meaningfully outside its original purpose, scope drift is already happening.

Technical breakdown

Why RAG changes the LLM data exposure model

Retrieval-augmented generation connects the model to external knowledge sources at inference time, which means the model no longer relies only on its trained parameters. Instead, it can pull live or semi-live content from internal systems, documents, and databases. That improves usefulness, but it also widens the blast radius if source data is overexposed, misclassified, or reachable through weak entitlements. The security boundary moves from the model alone to the full data path feeding the model.

Practical implication: govern retrieval sources as sensitive access paths, not just as AI inputs.

How excessive agency becomes an access control problem

Excessive agency occurs when an AI system can take actions beyond the minimum needed for its task, especially through tool-calling and connected workflows. In practice, the model may not just generate text. It may invoke SaaS actions, query cloud services, or trigger downstream automation. If those tools inherit broad permissions, the model effectively becomes a high-speed access broker with no human review in the loop. That is why AI security now overlaps directly with PAM, NHI governance, and least privilege design.

Practical implication: scope tool permissions to task-bound access and treat every agent as a governed identity.

Why training data hygiene now sits inside the security perimeter

Training and fine-tuning on proprietary data create a second exposure surface because sensitive information can enter the model pipeline before deployment. If source data is unclean, over-permitted, or poorly classified, the model can inherit privacy, compliance, and bias problems that are hard to reverse later. This is why data security posture management is increasingly paired with access governance and monitoring. The issue is not only what the model knows, but who was allowed to contribute that knowledge and under what controls.

Practical implication: apply classification, access review, and monitoring before data enters training or tuning workflows.

Threat narrative

Attacker objective: The attacker aims to abuse model-connected identities and data paths to exfiltrate sensitive information or trigger unauthorized actions at machine speed.

1. Entry occurs when attackers gain access to exposed credentials, over-permissive training data, or connected AI tooling that was not tightly scoped.
2. Escalation follows when the model or its associated identities can reach internal data stores, cloud services, or SaaS tools beyond intended limits.
3. Impact occurs through sensitive data exposure, unauthorized actions, model misuse, or downstream trust erosion across AI-enabled workflows.

NHI Mgmt Group analysis

AI security has become an identity governance problem, not just a model safety problem. The article correctly places data exposure and excessive agency at the centre of LLM risk, but the deeper issue is who and what is authorised to move data, call tools, and inherit privilege. Once an LLM is connected to internal systems, its security posture depends on IAM, PAM, and NHI controls as much as on the model itself. Practitioners should treat model workflows as governed access chains, not isolated AI features.

LLM training data creates a governance debt that compounds over time. Sensitive content that enters training or fine-tuning pipelines can persist through the model lifecycle, making later remediation expensive and incomplete. That is why data classification, lifecycle review, and access restriction need to happen before the dataset is committed to training. The control gap is not visibility alone, but the absence of enforceable lifecycle governance for model inputs. Practitioners should assume that training decisions create long-lived security obligations.

Excessive agency is the named concept practitioners should watch most closely. It describes the point at which an AI system can take actions outside its intended scope because permissions were designed around convenience rather than task boundaries. In practice, this is where AI security meets NHI governance: agent identities, tool tokens, and delegated permissions must be bounded like any other high-risk credential. Teams that ignore this will keep discovering that model behaviour is only as safe as the privileges behind it. Practitioners should redesign access around bounded delegation.

Data security posture management is becoming the operational control plane for LLM risk. The article’s emphasis on discovery, classification, and real-time monitoring reflects a broader shift toward continuously governed data paths rather than periodic review. That aligns with broader security frameworks such as NIST CSF and NIST SP 800-53, but the identity layer remains decisive because access to data determines what the model can learn and reveal. Practitioners should converge DSPM with identity governance rather than running them as separate programmes.

The market is moving toward unified control of model, data, and identity risk. Organisations can no longer manage LLMs with standalone policy documents or model review checklists. They need controls that link data entitlements, tool permissions, and suspicious identity behaviour into a single operational view. The practical implication is that AI security programmes will increasingly depend on the same governance primitives used for privileged access and non-human identities.

What this signals

Excessive agency is becoming a programme design problem, not an edge-case risk. As AI systems take on more tool use and data access, security teams need to define the permitted action space before deployment, not after the first incident. That means aligning AI governance with IAM, PAM, and NHI controls, then using NIST AI Risk Management Framework language to anchor accountability.

Model lifecycle controls now need the same discipline as identity lifecycle controls. Data that enters training or tuning pipelines should be governed with the same seriousness as privileged access requests, because remediation after ingestion is slow and partial. For teams that already manage NHIs, the lesson is clear: apply lifecycle thinking to datasets, tokens, and agent permissions together.

The practical signal for security leaders is that AI oversight will increasingly depend on cross-functional monitoring between data security, IAM, and cloud operations. A model may be the interface, but the real control failure usually sits in the identity path behind it.

For practitioners

• Tighten retrieval-source governance Inventory every RAG source, classify the data it can expose, and require explicit approval for any dataset that feeds inference time access. Treat retrieval paths as privileged data channels, not convenience connectors.
• Constrain AI tool permissions Assign task-scoped permissions to every agent or model-connected tool, then remove broad cloud and SaaS entitlements that are not required for the workflow. Use least privilege and separate identities for each major function.
• Classify and sanitize training inputs Run data discovery and sanitization before any fine-tuning or continual training step, with special handling for PII, secrets, and regulated records. Block uncontrolled ingestion into model pipelines.
• Monitor model-linked identity activity Watch for suspicious behaviour from user, app, and machine identities tied to LLM workflows, including unusual access patterns and data exfiltration attempts. Alert on permission drift and unexpected tool invocation.

Key takeaways

• LLM security in 2025 is primarily an access-control and data-governance problem, because model capability expands wherever retrieval and delegation are allowed to reach.
• The strongest signal in the article is that AI agents and LLM workflows already exceed intended scope in most environments, which makes least privilege a live control issue rather than a theoretical one.
• Practitioners should connect DSPM, IAM, and NHI governance so that training inputs, tool permissions, and model-linked identities are controlled as one lifecycle.

Key terms

• Retrieval-augmented Generation: Retrieval-augmented generation is a pattern where an AI model pulls external information before generating output. The security challenge is that access rules can weaken when data is chunked, embedded, cached, or reused, so source permissions may not automatically follow the content into the model's context.
• Excessive agency: A condition where an AI system is given more operational authority than its task requires. The risk is not just poor output. It is that mistakes, manipulation, or compromise can produce destructive actions at machine speed across the systems the agent can reach.
• Data Security Posture Management: Data Security Posture Management, or DSPM, is the continuous discovery and monitoring of where sensitive data lives, how it is exposed, and where policy gaps exist. Its value rises when it feeds remediation rather than generating findings alone, especially in environments where AI expands the number of data paths.
• AI-connected Identity: An AI-connected identity is a non-human identity used by an AI application or agent to access data, tools, or services. It may be a service account, token, or API key. The governance challenge is that these identities can move data at machine speed and often outlive the review process built for humans.

What's in the full article

Sentra's full article covers the operational detail this post intentionally leaves for the source:

• How Sentra applies DSPM, DAG, and DDR together across LLM training data workflows
• The specific data discovery and classification approach used to detect sensitive content in unstructured sources
• How the platform flags suspicious user, app, and machine identity activity tied to AI pipelines
• Why the article positions cloud-native data security as the control layer for AI training and inference

👉 Sentra's full article covers DSPM, data governance, and identity-driven monitoring for LLM training workflows.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It is designed for practitioners who need to connect access control, lifecycle governance, and operational risk across identity programmes.