LLM security is the set of practices and controls that protect large language models and the applications built on them from adversarial use, misuse, and operational failure. It spans model training and data integrity, deployment access control and isolation, inference-time inspection, and the surrounding application architecture.
- Protects models and the applications on them across the full lifecycle
- Covers training, deployment, inference, and application architecture
- The head term most enterprise buyers search when they begin evaluating AI risk
- An evaluation that tests one layer leaves the other three unaddressed
Why is LLM security important?
LLM security matters because it is the entry point for most enterprise AI risk programs. It is the head term security buyers search first, which means it is also where the most consequential scoping mistake happens: treating one layer of the discipline as the whole of it.
The discipline spans training through to application architecture, and the layers fail independently. A model deployed with sound access control can still be manipulated at inference. An application with strong input filtering can still leak through a tool call. Poisoned training data compromises every downstream control, and no runtime inspection detects it. A buyer evaluation that probes only inference leaves three layers untested.
The working checklists reflect that breadth. The OWASP Top 10 for LLM Applications is one of the primary references, used alongside the NIST AI RMF and MITRE ATLAS for threat coverage, and alongside ISO/IEC 42001 for the management-system layer that wraps the technical controls.
What is LLM security?
LLM security is the protection of language models and the systems built around them from adversarial manipulation and operational failure. Its subject is broader than the model, because most real exposure sits in what surrounds it.
Four layers make up the discipline. Training covers data integrity – provenance, poisoning resistance, and what the model may have memorized. Deployment covers access control, isolation, and how the model is exposed to callers. Inference covers inspection of what goes in and what comes out, which is where prompt injection and data leakage are detected. Application architecture covers everything the model connects to: tool use, retrieval, and the identity under which calls are made.
The fourth layer is where most incidents actually occur, and it is the least model-specific. An agent with a permitted tool and a steerable reasoning loop is an architecture problem rather than a model problem, which is why LLM security cannot be delegated to whoever selected the model.
Types of LLM security
The four lifecycle layers are the primary taxonomy, and each has its own controls and failure modes.
Training-stage security addresses data poisoning, provenance verification, and memorization of sensitive material. Controls are preventive and largely unavailable to organizations consuming third-party models, which is why provenance documentation matters for buyers.
Deployment-stage security addresses authentication, network isolation, tenancy, and key management. These are conventional controls applied to a new asset type, and they are the most familiar to an existing security team.
Inference-stage security addresses prompt injection, jailbreaking, sensitive data in prompts, and unreliable output. Controls are inline and operate per request.
Architecture-stage security addresses tool access, retrieval sources, agent identity, and permission scope. Controls are authorization-shaped rather than content-shaped, and this is the layer that grows fastest as deployments become agentic.
LLM security & Onyx
Onyx covers the LLM security lifecycle from inventory and posture through inline runtime defense, with alignment to the OWASP Top 10 for LLM Applications categories, NIST AI RMF functions, and MITRE ATLAS techniques – so coverage can be discussed against a named taxonomy rather than a feature list.
In practice that means the deployment and architecture layers are assessed through discovery and posture scoring, while the inference layer is enforced inline. AI Security handles the runtime defense, and posture scoring evaluates each asset across exposure, privilege, data access, autonomy, and blast radius. Training-stage integrity is addressed through supply chain and provenance visibility across models, agents, and MCP servers rather than through control of a third party's training process.
