Notifications
Clear all
Topic starter
12/06/2026 9:43 pm
TL;DR: LLM security spans prompt injection, data leakage, model poisoning, and excessive agency across training, deployment, and runtime monitoring, according to Lasso Security. The governance gap is that conventional IAM and access review processes were not built for AI behavior that can disclose, transform, or act on sensitive data at machine speed.
NHIMG editorial — based on content published by Lasso Security: Large Language Model (LLM) Security: Challenges & Best Practices
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern LLMs that can call tools and APIs?
A: Security teams should govern tool-enabled LLMs like delegated identities with explicit boundaries.
Q: Why do LLMs create more risk than ordinary automation workflows?
A: LLMs create more risk because their behaviour can change at runtime based on prompt content, retrieved context, or user input.
Q: What do teams get wrong about prompt injection?
A: Teams often treat prompt injection as a text-only problem, but it is really a trust-boundary problem.
Practitioner guidance
- Inventory every AI-connected identity path Map the credentials, service accounts, API keys, plugins, and data connectors that can be reached from each LLM workflow.
- Separate prompts from execution privileges Ensure that a model can suggest actions without directly holding the permissions to perform them.
- Apply least privilege to tool-enabled agents Scope each agent or model integration to the minimum connector set, resource scope, and action set required.
What's in the full article
Lasso Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Practical examples of how the vendor maps LLM risks to specific application and development use cases.
- The eight-component breakdown of an LLM security programme, including monitoring, privacy, and compliance considerations.
- The article's OWASP LLM Top 10 discussion with risk-by-risk explanations and examples.
- The vendor's recommended controls for employee use, model training, and response planning.
👉 Read Lasso Security's guide to LLM security risks and best practices →
LLM security and AI agents: are your identity controls keeping up?
Explore further
13/06/2026 12:00 am
LLM security is becoming identity security by another name. Once a model can access data, call tools, or influence workflows, the question is no longer only whether the model is accurate. The question is who or what is authorised to act through it, and under what boundaries. That makes LLM security a control problem across NHI, IAM, and lifecycle governance, not just a model-risk problem. Practitioners should evaluate AI systems as governed identities with bounded privileges.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
A question worth separating out:
Q: Who is accountable when an AI system exposes data or takes an unwanted action?
A: Accountability should sit with the team that assigned the permissions, connected the data, and approved the workflow. In practice, that means product owners, security, and identity governance all share responsibility for the model’s delegated reach. If the permissions were excessive, the failure is governance, not just model behaviour.
👉 Read our full editorial: LLM security exposes the governance gap in AI and identity controls
