Notifications
Clear all
Topic starter
11/08/2026 3:20 pm
TL;DR: LLM security now covers prompt injection, sensitive data exposure, poisoned training data, model theft, and supply chain abuse, with Panther citing 13% of organisations reporting AI model or application breaches in 2024 and 97% of those lacking proper AI access controls. The control gap is not visibility alone; it is that conventional security assumptions do not map cleanly onto natural-language systems with tool access and opaque internals.
NHIMG editorial — based on content published by Panther: What Is LLM Security? Risks, Vulnerabilities, and Best Practices
By the numbers:
- In 2024, 13% of organizations reported breaches involving AI models or applications, and 97% of those organizations lacked proper AI access controls.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams govern LLM and agent access in production?
A: Treat every model, agent, connector, and service account as part of one identity surface.
Q: Why do LLMs create more risk when they can call tools or APIs?
A: Tool access turns the model from a text generator into a delegated operator.
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.
Practitioner guidance
- Define model identity and ownership Assign a named owner for each production LLM workflow, including the service account, retrieval layer, and downstream tools it can use.
- Constrain delegated privileges Reduce each model's tool scope to the minimum required, prefer read-only access where possible, and use short-lived credentials for any action that can alter data or trigger workflows.
- Instrument prompt and retrieval audit trails Log full prompt-response pairs, retrieved documents, tool calls, and policy decisions so investigators can reconstruct how an output was produced.
What's in the full article
Panther's full article covers the operational detail this post intentionally leaves for the source:
- Detection-as-code examples for LLM-specific threat patterns such as prompt injection and abnormal retrieval behaviour
- Practical control steps for filtering prompts, validating outputs, and monitoring model activity at scale
- Examples of how teams can instrument logs for prompt-response pairs, tool calls, and policy decisions
- Implementation advice for teams using model-enabled applications, assistants, or retrieval-augmented generation systems
👉 Read Panther's guide to LLM security risks, vulnerabilities, and best practices →
LLM security risks and the governance gap teams are missing?
Explore further
11/08/2026 3:31 pm
LLM security is now an identity problem as much as a model problem. The article is right to frame natural-language attacks as something traditional security tools were not designed to see, but the deeper governance issue is privilege, not prose. Once an LLM can read retrieval content, invoke tools, or use API keys, its effective identity must be governed like any other high-risk workload. That means IAM, PAM, and secrets management become core AI controls, not adjacent ones. Practitioners should treat model access as a first-class identity estate.
A question worth separating out:
Q: Which frameworks should practitioners use for LLM security governance?
A: For AI-specific risk, use NIST AI Risk Management Framework and OWASP Agentic AI Top 10. Where credentials and workload access are involved, add OWASP NHI guidance, NIST Cybersecurity Framework, and identity controls that cover secrets, privilege, and auditability.
👉 Read our full editorial: LLM security gaps show why traditional controls miss AI threats
