Notifications
Clear all
Topic starter
25/06/2026 1:40 pm
TL;DR: LLMs can speed search, reporting, and access description work, but they also bring hallucinations, prompt injection, data leakage, and infrastructure and governance questions that matter in enterprise identity security, according to SailPoint. The practical issue is not whether LLMs are useful, but which identity workflows can tolerate probabilistic behaviour without weakening control boundaries.
NHIMG editorial — based on content published by SailPoint: Large language models: What's under the hood?
Questions worth separating out
Q: How should security teams use LLMs in identity workflows without weakening control?
A: Use LLMs for draft assistance, search translation, and first-pass reporting, but keep final identity decisions under human review.
Q: Why do LLMs create risk in identity and access management programmes?
A: LLMs can hallucinate, leak information, and behave inconsistently when prompts or context change.
Q: What do teams get wrong about prompt injection in enterprise AI systems?
A: They often treat prompt injection as a content problem instead of an access problem.
Practitioner guidance
- Define LLM-permitted identity use cases Separate low-consequence drafting and search tasks from high-consequence activities such as final access approval, audit attestation, and entitlement changes.
- Inventory every data source the model can see Document which identity records, reports, and logs are exposed to prompts, embeddings, plugins, or downstream tools.
- Treat tool access as privileged access Apply the same scrutiny you would use for a service account or admin workflow when an LLM can query systems, generate reports, or pass data to plugins.
What's in the full article
SailPoint's full blog covers the operational detail this post intentionally leaves for the source:
- The specific experiments SailPoint ran to test LLM search, access descriptions, and audit support
- The detailed list of LLM blind spots and the examples SailPoint used to illustrate each one
- The infrastructure considerations SailPoint applied when evaluating Amazon Bedrock for enterprise use
- SailPoint's own question set for assessing data provenance, regulation, and PII handling before deployment
👉 Read SailPoint's analysis of LLM blind spots in identity security →
LLM blind spots and identity security: what teams should watch?
Explore further
25/06/2026 3:39 pm
LLM-assisted identity work creates a control problem, not just a productivity gain. Search, audit drafting, and access description generation can reduce manual effort, but they also import probabilistic output into workflows that assume precision. That shifts the burden from speed to assurance, because the wrong answer can become an identity decision artifact. Practitioners should treat LLM output as a draft input that must be verified against governed identity sources.
A few things that frame the scale:
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
- In the same research, 80% of organisations report their AI agents have already performed actions beyond their intended scope, including unauthorised access and inappropriate data sharing.
A question worth separating out:
Q: Who is accountable when LLM-generated identity output is wrong?
A: Accountability stays with the organisation that approved the workflow, not the model itself. Governance teams need documented ownership, review checkpoints, and escalation paths for model-assisted identity processes. Frameworks such as the NIST AI Risk Management Framework and identity governance controls both matter when AI output can affect access or compliance evidence.
👉 Read our full editorial: LLM blind spots are reshaping enterprise identity security
