# LLM Security Hardening Checklist: Closing the OWASP LLM Top 10 > Source: https://netray.co/tools/llm-security-hardening-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A practical control checklist for hardening LLM applications against prompt injection, insecure output handling, supply chain risk, and excessive agency, organized around the OWASP LLM Top 10. ## Category on-prem-ai ## Tool **Kind:** checklist **Groups:** #### Input and prompt handling **Items:** **Text:** System instructions and untrusted content (user input, retrieved documents, tool outputs) are structurally separated in the prompt, not just concatenated **Critical:** true Input length limits are enforced before content reaches the model, preventing context-stuffing and denial-of-service style abuse Retrieved and third-party content is explicitly labeled as untrusted data rather than treated as trusted instruction Rate limits and per-identity request quotas are enforced to contain both abuse and runaway agent loops #### Output handling and action authorization **Items:** **Text:** Model output is never passed directly to a shell, database query, or code execution context without sanitization **Critical:** true **Text:** Consequential actions (financial, data deletion, external communication) require independent validation or human approval before execution **Critical:** true A defined, minimal set of tools and API scopes is granted to the model; no agent has broader access than its task requires Output is filtered for known-sensitive patterns such as credentials, export-controlled identifiers, and personal data before it reaches a user or downstream system Structured output (JSON, function calls) is schema-validated before being consumed by any downstream system #### Model and supply chain integrity **Items:** **Text:** Model weights are downloaded from verified sources with recorded checksums, and stored in safetensors rather than pickle-based formats **Critical:** true Third-party fine-tuned or merged models are treated as new supply chain entries requiring the same vetting as a base model Dependencies for the serving stack (inference engine, tokenizer libraries, vector database client) are pinned and scanned for known vulnerabilities A documented process exists for evaluating training data sources for poisoning risk before any fine-tuning run Model registry tracks version, provenance, license, and approved use case for every deployed model #### Infrastructure and resource protection **Items:** **Text:** Inference endpoints are network-segmented with authenticated service identities, never a shared static API key **Critical:** true GPU hosts and inference containers run with least-privilege configurations: non-root, read-only filesystems where possible, dropped capabilities Resource limits (max tokens, max concurrent requests, timeout) prevent a single request or user from exhausting shared GPU capacity Model files and vector indexes are protected against unauthorized copy to prevent weight and embedding theft #### Monitoring, testing, and response **Items:** **Text:** All inference requests are logged with identity, timestamp, model version, and correlation ID for audit and incident investigation **Critical:** true Anomaly detection flags unusual prompt volume, oversized inputs, and repeated jailbreak-pattern attempts Adversarial testing for prompt injection, jailbreaks, and data extraction runs before launch and on a recurring schedule afterward An incident response runbook explicitly covers model compromise, prompt injection exploitation, and output-based data leakage Overreliance is addressed in the UX: outputs presenting as authoritative fact are labeled, sourced, or confidence-scored where accuracy is uncertain **Scoring Note:** An LLM application is defensible when at least 90% of all items are complete and every critical item is closed. The critical items map directly to the OWASP LLM Top 10 categories with the highest real-world incident rate: prompt injection, insecure output handling, excessive agency, and supply chain compromise. Any open critical item should block a production launch, since each represents a path an attacker needs no special access to exploit, only the ability to send input the system will eventually process. ## Content **Intro:** This free LLM security hardening checklist organizes practical controls around the OWASP LLM Top 10, the industry-recognized categories of LLM application risk, and it is written for AI engineers, security architects, and platform leads shipping production LLM applications, whether self-hosted or API-backed. It spans five domains: input and prompt handling, output handling and action authorization, model and supply chain integrity, infrastructure protection, and monitoring and response. Most LLM security incidents trace back to a handful of repeated patterns: untrusted content treated as trusted instruction, model output executed without sanitization, and agents granted far broader action scope than their task required. **Sections:** #### Why LLM applications need a distinct security model **Body:** Traditional application security assumes a relatively fixed set of inputs and a deterministic code path. LLM applications break both assumptions: input is unbounded natural language, and the code path itself, what tool gets called, what data gets retrieved, what action gets taken, is determined by the model's own generated output at runtime. That shift means output handling deserves the same scrutiny traditionally reserved for input validation, because in an LLM system the model's output is effectively untrusted code waiting to be interpreted by whatever consumes it next. **Bullets:** - Model output driving a tool call, database query, or shell command is functionally similar to user input in a traditional application. - Excessive agency, granting an agent broader action scope than its task requires, turns a successful manipulation into real damage. - Supply chain risk extends beyond code dependencies to model weights, fine-tuning data, and third-party model providers. - Overreliance is a security-relevant failure mode too: users treating confident, ungrounded output as verified fact leads to real-world bad decisions. #### The controls that matter most **Body:** The items marked critical correspond to the OWASP LLM Top 10 categories with the highest documented incident rate: prompt injection through unseparated instruction and content, insecure output handling that lets model output reach execution contexts unsanitized, excessive agency granting broad unreviewed action scope, and supply chain compromise through unverified model artifacts. Each of these can be exploited by an attacker with no special access, only the ability to get text in front of the model, which is why they take priority over infrastructure hardening that assumes a more capable adversary. **Bullets:** - Structural separation between instructions and untrusted content, since this closes the most common injection path. - Independent validation before consequential actions execute, removing the model as the sole gatekeeper of its own decisions. - Verified model provenance with safetensors-only weight files, closing the code-execution path some formats permit. - Complete inference logging, without which an incident investigation has nothing to work from. #### How to work through the checklist **Body:** Assign ownership by domain: application engineering owns input and output handling, platform engineering owns infrastructure and supply chain, and security owns monitoring and incident response, with a single accountable lead tying the domains together. Close every critical item before production traffic reaches the system. Re-run the full checklist whenever you add a new tool or data source to an existing agent, change model providers, or expand the system's action scope, since each of those changes can silently reopen a control you closed months earlier. #### How Netray hardens production LLM systems **Body:** Netray builds and hardens LLM applications for manufacturers where a security failure has real operational and compliance consequences. We architect the instruction and content separation that closes the most common injection path, scope agent actions to the minimum required with independent validation on anything consequential, and verify model supply chain integrity from weight file to deployed serving stack. For self-hosted deployments, we extend this hardening down through the infrastructure layer, so the same rigor applies whether you are calling a hosted API or running an open-weight model entirely inside your network. **Cta:** Get a control-by-control LLM security review mapped to the OWASP LLM Top 10 before your next production launch. **Faq:** #### What is the OWASP LLM Top 10 and why does it matter for hardening? **Answer:** It is a community-maintained list of the ten most critical security risks specific to LLM applications, covering categories like prompt injection, insecure output handling, training data poisoning, model denial of service, supply chain vulnerabilities, sensitive information disclosure, insecure plugin design, excessive agency, overreliance, and model theft. It matters because it reflects real incident patterns across the industry rather than theoretical risks, and mapping your hardening checklist to it makes gaps easier to communicate to security teams already familiar with the framework. #### Is insecure output handling really a bigger risk than prompt injection? **Answer:** They are closely linked rather than competing risks: prompt injection is often the delivery mechanism, and insecure output handling is what turns a successful injection into real damage. A system with perfect input filtering but no output validation is still vulnerable if an attacker finds any path to influence generated output, while a system that never executes model output unsanitized limits the blast radius even when injection succeeds. Harden both; neither is sufficient alone. #### How do we scope agent action permissions correctly? **Answer:** Start from the task, not the available tool catalog. Grant only the specific actions a given agent needs to complete its defined task, not general access to every tool your platform supports. Review the granted scope whenever the agent's task changes, and treat any request to expand an agent's action scope as a security review event, not a routine configuration change, since excessive agency is one of the most common ways a successful manipulation turns into real damage. #### Do these controls apply if we are using a hosted API instead of self-hosting the model? **Answer:** Most of them do. Input and prompt handling, output validation, action authorization, and monitoring are entirely your responsibility regardless of where the model runs. Model supply chain and infrastructure hardening shift partially to the vendor, but you still need to verify their practices contractually and understand what they do and do not cover, since a vendor's security posture for the model does not automatically extend to how your application uses its output. ## Search terms LLM security hardening checklist, OWASP LLM Top 10 checklist, LLM security controls, AI application security checklist, prompt injection hardening, secure LLM deployment checklist, self-hosted LLM security --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json