Notifications
Clear all
Topic starter
01/08/2026 8:53 pm
TL;DR: LLM deployments now face prompt injection, sensitive data leakage, supply chain compromise, output misuse and excessive agency, with Akto mapping those risks across the OWASP Top 10 for LLM applications, NIST AI governance and the EU AI Act. The practical issue is no longer model quality alone but whether access, outputs and tool use are governed tightly enough to survive adversarial use.
NHIMG editorial — based on content published by Akto: LLM security risks in agentic systems and the biggest threats to large language models in 2026
By the numbers:
- 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 LLMs that can call tools or run code?
A: Security teams should govern them as privileged workloads, not as chat interfaces.
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.
Q: What do organisations get wrong about prompt injection?
A: They often treat it as a purely content-filtering problem.
Practitioner guidance
- Map every LLM and agentic integration to an access owner Inventory each model, assistant and MCP connection, then assign a business owner for the credentials, data sources and actions it can reach.
- Separate retrieval trust from execution trust Treat retrieved content as untrusted until it passes policy checks, and block any path where model output can trigger privileged actions without a second control.
- Constrain tool use with least privilege and step-up approval Limit each agent to the narrowest tool set and data scope it actually needs, then require human approval for account changes, refunds, deletions or any action that alters security state.
What's in the full article
Akto's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step breakdowns of the OWASP LLM risk categories as Akto applies them in testing and monitoring.
- Examples of the article's mitigation patterns for prompt injection, output handling and model poisoning.
- Descriptions of the AI agent, MCP and chatbot coverage that underpin Akto's testing workflow.
- The platform-specific feature list for discovery, detection and CI/CD integration that implementation teams would need.
👉 Read Akto's analysis of LLM security risks in agentic systems →
LLM security risks and agent abuse: are your controls keeping up?
Explore further
01/08/2026 9:02 pm
LLM security is becoming an identity governance problem, not just a model safety problem. Once an LLM can read enterprise data, call tools or act inside workflows, it behaves like a governed access principal. That means the relevant question is not only whether the model is accurate, but whether its inputs, outputs and delegated actions are constrained like any other privileged system. For IAM and PAM teams, the operational boundary is now the model itself, its retrieval sources and the service identities behind its tools.
A question worth separating out:
Q: How can teams tell whether LLM governance is actually working?
A: Look for evidence that model access is scoped, tool use is logged, sensitive outputs are blocked or reviewed, and poisoned context fails closed. If teams cannot trace prompts, retrieval sources and actions end to end, governance exists on paper but not in practice.
👉 Read our full editorial: LLM security risks in 2026: prompt injection, MCP and agent abuse
