Global Software AI
1 мин чтения

The OWASP LLM Top 10 is an application-security list

OWASP's 2025 list shows that securing an LLM application requires architecture, testing, and development controls around the model.

Автор: Tim Crouch

Больше из серии AI Security

The 2025 OWASP Top 10 for LLM Applications keeps attention on the application, not only the model. Prompt injection leads the list, but sensitive information disclosure, supply-chain weaknesses, data and model poisoning, improper output handling, excessive agency, system-prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption all depend on how the complete service is designed and operated.

CISSP Domain 3, Security Architecture and Engineering, provides the first lens. An LLM should sit behind explicit trust boundaries, least-privilege access, constrained tools, protected data paths, and controls that assume model output may be wrong or hostile. Excessive agency is an architecture problem: a system that can take consequential actions needs authorization, limits, verification, and safe failure behavior outside the model.

Domain 8, Software Development Security, turns those principles into implementation. Teams must validate inputs, handle outputs safely, review dependencies and model provenance, protect retrieval stores, separate secrets from prompts, set resource limits, and test integrations. The LLM is one component in a software supply chain and runtime environment. Standard application-security practices remain necessary even when the failure begins with natural language.

Domain 6, Security Assessment and Testing, challenges teams to test realistic misuse. That includes direct and indirect prompt injection, poisoned knowledge, unauthorized tool calls, data disclosure, denial of wallet, and insecure downstream rendering. Tests should verify controls and business consequences, not merely record that a model produced an undesirable sentence.

The list should not be treated as a complete AI threat model or a compliance certificate. It is a prioritized starting point. My practical takeaway is to use each category as a design-review question: where can this risk appear in our architecture, which control owns it, how will we test it, and what evidence will show the control still works after the model, data, prompt, or integration changes?