OWASP LLM Top 10 Security in Practice
Yesterday I had the privilege of attending a talk by Sergey Saburov from Acronis on “Agentic Engineering & LLM Security.” Sergey provided an in-depth analysis of security threats facing modern LLM applications, along with numerous real-world case studies aligned with the OWASP LLM Top 10 framework.
I’ve organized and summarized the content based on the latest OWASP LLM Top 10 v2.0 (2025) official standard. I’ve corrected some terminology discrepancies from the original talk (e.g., LLM06, LLM10) and compiled Python PoC (Proof of Concept) and defense scripts tailored for Kubernetes platform engineers, hoping this serves as a reference for building secure AI systems.
LLM01: Prompt Injection
Definition: Includes both direct prompt injection (jailbreaking) and indirect prompt injection. Indirect injection occurs when an attacker embeds malicious instructions into data sources (e.g., web pages, emails, documents) that the LLM may retrieve or process.
PoC Attack Code:
| |
Defense Script (Guardrails & Semantic Filter): Note: Simple keyword filtering is easily bypassed; semantic analysis is recommended.
| |
LLM02: Sensitive Information Disclosure
Definition: Specifically refers to LLMs accidentally leaking PII, keys, or proprietary algorithms in the output; a core output-side DLP (Data Loss Prevention) issue.
PoC Attack Scenario:
| |
Defense Script (PII/Secrets Detection):
| |
LLM03: Supply Chain Vulnerabilities
Definition: Includes supply chain risks from insecure models, plugins, libraries, etc. For example, loading tampered model weights can lead to arbitrary code execution.
PoC Attack Scenario:
| |
Defense Script (Signature Verification): Recommendation: In Kubernetes environments, use TUF or Sigstore/Cosign for model image signature verification.
| |
LLM04: Data and Model Poisoning
Definition: Manipulating training or fine-tuning data to implant backdoors or biases. Defense focuses on data lineage tracking and training environment isolation.
PoC Attack Sample:
Defense Script (Anomaly Detection): Note: Setting distance thresholds in high-dimensional space is challenging; it’s recommended to combine with K8s network isolation to prevent models from accessing external malicious payloads during training/fine-tuning.
| |
LLM05: Improper Output Handling
Definition: Downstream systems failing to validate LLM output, leading to security vulnerabilities (e.g., XSS, CSRF, SQL injection, Shell injection).
PoC Attack Scenario:
| |
Defense Script (Output Encoding/Sanitization):
| |
LLM06: Excessive Agency
Definition: An agent is granted excessive permissions or can invoke high-risk functions without an approval mechanism.
PoC Attack Code:
| |
Defense Script (Least Privilege & Approval):
| |
LLM07: System Prompt Leakage
Definition: Attackers use prompt engineering techniques to steal the system’s built-in proprietary prompt or business logic.
PoC Attack Prompt:
| |
Defense Script (Semantic Similarity Check): Note: Character matching (SequenceMatcher) is easily bypassed; semantic similarity detection is recommended.
| |
LLM08: Vector and Embedding Weaknesses
Definition: Includes poisoning attacks on vector databases and permission isolation failures due to shared indexes across tenants.
PoC Attack Scenario:
| |
Defense Script (Source Verification):
| |
LLM09: Misinformation
Definition: The hallucination problem, where the model generates plausible but incorrect information.
PoC Scenario:
| |
Defense Script (RAG Grounding Check):
| |
LLM10: Unbounded Consumption (DoS)
Definition: Includes token exhaustion, storage explosion, GPU memory overflow, etc., leading to denial of service.
PoC Attack:
| |
Defense Script (Resource Quota):
| |
Infrastructure Protection Recommendations (Kubernetes)
For Kubernetes platform engineers, the following protection measures should be prioritized:
| Risk Item | K8s-Specific Protection Measures |
|---|---|
| LLM06 (Excessive Agency) | Use Kubernetes Workload Identity (e.g., AWS IRSA, GCP Workload Identity) to ensure Pods have only the minimum IAM permissions to operate specific cloud resources, rather than hardcoded Secrets. |
| LLM10 (Resource Consumption) | In addition to token limits, configure K8s Resource Quotas and LimitRanges to prevent GPU memory from being exhausted by malicious long-text inference, which could cause node OOM. |
| LLM03 (Supply Chain) | Implement Admission Controllers (e.g., Kyverno or OPA Gatekeeper) to block pulling model images from unauthorized Registries. |
| Network Layer | Use nftables or K8s NetworkPolicy to restrict Pod egress traffic. LLM Pods should only be able to connect to vector databases and trusted APIs, blocking reverse shell connections. |
Thanks to Sergey Saburov for the hands-on insights.
Sources
- Samsung Software Engineers Busted for Pasting Proprietary Code into ChatGPT
- Poisoning Attacks on LLMs Require a Near-constant Cost
- Jailbreaking Commercial Black-Box LLMs with Explicitly Harmful Prompts
- OWASP LLM07:2025 System Prompt Leakage – Risks & Mitigations
- The Embedded Threat in Your LLM: Poisoning RAG Pipelines via Vector Embeddings
- LLM09:2025 Misinformation - OWASP Gen AI Security Project
- OWASP Top 10 for Large Language Model Applications
🤖 AI Related Posts by semantic similarity
Want updates? Subscribe via RSS
Related Content
- Before Discussing LLM Security, Is Your Kubernetes Foundation Up to Standard?
- Cilium 2026 (Continued): How the Unified Data Plane Is Reshaping Kubernetes Platform Architecture
- From Azure SRE Agent to HolmesGPT: AIOps Practices in Multi-Cloud Kubernetes Environments
- Weekend Project: Building a Local Load Balancer for LLM API Keys
- Kubernetes Complexity: Starting From a Job Interview Question