How to Secure LLM Applications: An Enterprise Checklist

Why LLM security is different

LLM security is the practice of protecting applications built on large language models against a class of threats that traditional application security was never designed to see. If your team ships a chatbot, a copilot, a document assistant, an agent, or any feature that puts a language model in the request path, you have inherited a new attack surface — and most of your existing controls do not cover it.

The reason is structural. A conventional application has a clean boundary between code and data: the program is trusted, the input is untrusted, and security is largely a matter of keeping the two apart. A language model erases that boundary. It reads instructions and data in the same channel — natural language — and cannot reliably tell a legitimate instruction from a malicious one hidden inside a document it was asked to summarize. The model is probabilistic, so its behavior can be steered by anyone who can get text in front of it.

That combination breaks assumptions that traditional AI application security tooling never had to question. A web application firewall inspects HTTP for known-bad code; it has nothing to say about a politely worded sentence that convinces a model to ignore its own rules. Data-loss prevention watches files and network flows; it does not read model output for regulated data escaping in fluent prose. The controls are not wrong — they are simply aimed at a different layer.

This guide for shipping secure LLM applications is a working checklist for the people who ship and defend LLM features: application engineers, platform teams, and the security functions that back them. It is organized by area so you can assign owners, and it is anchored to the OWASP Top 10 for LLM Applications so it maps to a vocabulary auditors and peers already share. For how these controls fit an enterprise program, see the Deflected platform overview.

The LLM threat model

Before the checklist, it is worth being precise about what you are defending against. A threat model for an LLM application looks different from one for a traditional web service in a few specific ways.

The instruction/data boundary is gone

In a normal application, you validate input and then your trusted code decides what to do with it. In an LLM application, the input is partly the program. Any text that reaches the model's context window — the user's message, a retrieved document, a tool result, an email, a web page, even a file name — can contain instructions the model may follow. This is the root cause of prompt injection, the first and most consequential category in the OWASP LLM Top 10, and it is why every other control on this list assumes the model can be turned against you.

The trust boundary extends to everything the model reads

Because the model treats retrieved content as authoritative, your trust boundary now includes every source that feeds it: knowledge bases, vector stores, third-party APIs, uploaded files, and the open web. A poisoned document in a shared drive becomes an attack vector the moment your retrieval system indexes it. This is indirect prompt injection, and it is harder to defend than the direct kind because the malicious text never passes through a human.

Outputs are untrusted, and actions are consequential

Model output can be manipulated, so it must be treated as untrusted before it reaches a browser, a shell, a database, or another system — the OWASP category of insecure output handling. And when a model is wired to tools that can send email, move money, modify records, or run code, a successful manipulation stops being a content problem and becomes an action problem. OWASP calls the over-granting of such capability excessive agency.

The data and the model itself are targets

LLM applications concentrate sensitive data in new places: prompts, embeddings, fine-tuning sets, and logs. That creates fresh paths for sensitive information disclosure. Meanwhile the model and its dependencies form a supply chain that can be compromised through training-data poisoning or tampered weights and packages. The asset you are protecting is no longer just the app — it is the model, its data, and its behavior.

How to use this checklist

The rest of this article is the checklist itself, split into ten areas. Each maps to one or more OWASP LLM Top 10 categories and is written as concrete controls you can adopt, assign, and verify. You will not implement all of them on day one. Instead:

1. Threat-model first. Walk your application and note where untrusted text enters, what the model can do, and what data it can reach. Let that drive priority.
2. Assign an owner per area. Input handling, output handling, and agent permissions often belong to application engineers; supply chain, secrets, and observability to platform and security teams.
3. Treat it as defense in depth. No single control stops prompt injection. The goal is layered containment, so that when one control is bypassed, the blast radius is small.
4. Verify continuously. A control you have not tested adversarially is a hypothesis, not a defense.

It helps to keep the mapping between OWASP LLM Top 10 risks and the checklist areas visible, so a control you adopt can always be traced back to the threat it answers. The correspondence is roughly:

• Prompt injection (direct and indirect) → input handling, secure system-prompt design, data & RAG security, and least-privilege tooling. No single area closes it; the layers together contain it.
• Insecure output handling → output handling, with encoding, validation, and sandboxing at every place model output is consumed.
• Sensitive information disclosure → output handling, data & RAG security, secrets management, and disciplined logging.
• Excessive agency and insecure plugin/tool design → the tools, agents & least-privilege section, plus human-in-the-loop approval for consequential actions.
• Training-data poisoning and supply-chain vulnerabilities → model & supply-chain risk, with provenance and integrity checks.
• Model denial of service → rate limiting, quotas, and cost controls that appear across input handling, agents, and observability.
• Overreliance → output handling and UX design that keeps a human accountable for consequential decisions.
• Model theft → secrets and access control, tenant isolation, and the encryption practices in the post-quantum section.

Read that way, the checklist is not ten unrelated chores; it is a coordinated answer to a known threat catalog. The sections that follow work through each area in turn.

Input handling & prompt-injection defense

Input handling is where LLM security begins, because prompt injection is the defining vulnerability of the category. It is worth stating plainly: prompt injection cannot be fully solved today. There is no input filter that catches every malicious instruction, because the attack is expressed in the same open-ended language your application legitimately uses. The realistic goal is containment — making injection hard to pull off and cheap to survive.

Separate instructions from data

• Keep your system prompt and developer instructions structurally distinct from user and retrieved content. Use the model provider's designated roles and message boundaries rather than concatenating everything into one string.
• Clearly delimit untrusted content (for example, wrap retrieved documents in explicit markers) and instruct the model to treat anything inside those markers as data to be analyzed, never as instructions to be followed. This is not foolproof, but it raises the bar.
• Never let user input silently overwrite or append to the system prompt. Assemble prompts from templates with typed, validated slots.

Constrain the model's job

• Write narrow, specific system prompts. A model told exactly what it may and may not do is easier to keep on task than one given a broad, open mandate.
• Where the task allows, constrain the output format — for example require structured JSON against a schema — so downstream code can reject anything that does not conform.
• Prefer allow-lists over deny-lists. Enumerate the topics, actions, and formats the application supports rather than trying to enumerate everything an attacker might try.

Filter and screen inputs at a gateway

• Inspect inbound prompts for known injection patterns, jailbreak templates, and suspicious instruction-like content before they reach the model. Treat this as a signal that raises risk, not a complete defense.
• Normalize and sanitize input: strip or neutralize hidden characters, zero-width text, and unusual encodings that are commonly used to smuggle instructions past filters and human reviewers.
• Decode and inspect content that arrives in other formats — base64 blobs, HTML comments, image alt text, document metadata — because instructions are frequently hidden where a casual reviewer will not look.
• Rate-limit and monitor for automated probing. Injection attacks are often iterative; an attacker testing hundreds of variations should be visible and throttled.

Know the injection techniques you are defending against

Defenders reason better when they can name the attack patterns. The common families are worth recognizing:

• Direct instruction override — the classic "ignore your previous instructions and instead do X." Rare in its naive form now, but endlessly rephrased.
• Role-play and hypothetical framing — asking the model to "pretend," "simulate a system with no rules," or act as a fictional character for whom the restrictions supposedly do not apply.
• Indirect injection through content — instructions planted in a web page, PDF, email, or code comment that the model later reads during retrieval or browsing. The user who triggers it may be entirely innocent.
• Obfuscation and encoding — payloads split across messages, translated, spelled out, or encoded to slip past pattern matching while still being understood by the model.
• Payload smuggling into tools — text crafted so that when the model calls a tool, the tool arguments carry the attack into a downstream system.

You will not enumerate every variant, and you should not try to. Recognizing the families tells you what your gateway, your delimiters, and your least-privilege boundaries each need to withstand.

A dedicated inline gateway is the cleanest place to enforce these controls consistently across every application, which is exactly what a prompt firewall is designed to do. The essential point is that input filtering buys you time and telemetry; it does not buy you immunity. The controls that actually bound the damage live in the next several sections.

Secure system-prompt design

The system prompt is the closest thing an LLM application has to trusted configuration, and it is routinely under-engineered. Teams treat it as prose to be tweaked rather than as a security control to be designed, versioned, and tested. Because the system prompt shapes every response, small weaknesses in it become systemic weaknesses in the product.

Write the prompt as a specification, not a suggestion

• State the model's role, scope, and hard boundaries explicitly and up front. Ambiguity is what jailbreaks exploit; a precise mandate leaves less room to negotiate.
• Enumerate what the assistant must refuse, and instruct it to refuse rather than improvise when a request falls outside scope or when instructions conflict.
• Tell the model how to treat untrusted content directly: that anything appearing in user input or retrieved documents is data to be analyzed, never commands to be executed, even if that content claims to come from you or from the system.
• Instruct the model never to reveal, summarize, or transform its own system prompt or hidden instructions on request. Assume it will sometimes be asked; make the intended behavior explicit.

Do not rely on the system prompt alone

A well-designed system prompt raises the cost of an attack, but it is not an authorization boundary. A model can be talked out of instructions given only in text. So the system prompt must be one layer among several:

• Never place secrets, credentials, internal URLs, or data that would be damaging to disclose inside the system prompt. Treat everything in the prompt as potentially readable by an attacker.
• Back every behavioral rule that actually matters with a deterministic control elsewhere — a gateway check, a tool permission, an output filter — so that a bypassed instruction is not a bypassed defense.
• Keep the prompt minimal. Every extra capability or exception you write in is another thing an attacker can turn to their advantage.

Manage prompts like code

• Store system prompts in version control, review changes the way you review code, and record who changed what and why. A prompt edit can weaken security as surely as a code change.
• Pin prompts to releases and test each version against your evaluation and red-team suites before it ships, so a wording change cannot quietly reopen a closed hole.
• Separate configuration from content: keep the security-relevant framing stable and version-controlled, even as task-specific context is assembled at runtime from validated inputs.

Output handling

The single most important rule of LLM security is also the most frequently violated: treat every model output as untrusted input to whatever consumes it. This is OWASP's insecure output handling category, and it is where prompt injection turns into classic, well-understood vulnerabilities — because a manipulated model will happily produce a malicious payload, and if you pass that payload straight to a browser, a database, or a shell, you have handed the attacker a familiar exploit through a new door.

Validate and encode before use

• Encode model output for its destination context. Text rendered in a web page must be HTML-encoded to prevent cross-site scripting; text used in a query must be parameterized to prevent SQL injection; text used in a shell must be treated as hostile and never interpolated into a command.
• Validate structured output against a strict schema and reject anything that does not match. Do not "repair" malformed output by feeding it back without limits.
• Never eval or directly execute model-generated code without a sandbox and explicit review. If the product generates code for users, run it in an isolated, least-privilege environment.

Prevent data leakage in responses

• Scan outbound responses for sensitive information — personal data, credentials, secrets, internal identifiers — before they reach the user. A model with access to regulated data can disclose it in fluent language that traditional DLP will not catch.
• Apply the same egress inspection to any content the model sends to external tools or webhooks. Exfiltration frequently happens through a tool call, not the user-facing reply.
• Redact or mask sensitive fields as close to the source as possible, so the model never sees more than the task requires.

Guard against overreliance

• Design the UX so users understand output may be wrong. OWASP flags overreliance — treating confident model output as authoritative — as a genuine risk, especially for code, legal, medical, and financial content.
• Keep a human in the loop for consequential decisions, and make it easy to trace a claim back to its source when the application uses retrieval.

Data & RAG security

Retrieval-augmented generation (RAG) makes models useful by grounding them in your data, and in doing so it becomes one of the largest attack surfaces in an LLM application. Every document your retriever can return is content the model may treat as authoritative — which means every document is a potential vehicle for indirect prompt injection.

Treat retrieved content as untrusted

• Apply the same input-handling discipline to retrieved chunks as to direct user input: delimit them clearly, mark them as data, and never let them silently escalate into instructions.
• Govern what enters the index. Content from untrusted or externally writable sources — shared drives, ticket systems, email, crawled web pages — should be screened before it is embedded, because a poisoned document is dormant only until it is retrieved.
• Prefer curated, provenance-tracked corpora for high-stakes applications, so you can answer "where did this come from" for any chunk the model used.

Enforce tenant and permission isolation

• Filter retrieval by the requesting user's actual entitlements. The vector store must respect the same access controls as the source systems; otherwise a user can retrieve — and the model can surface — data they were never authorized to see.
• Isolate tenants at the data layer. In multi-tenant products, one tenant's embeddings must never be retrievable in another tenant's context. Enforce this with hard partitioning, not just query-time filters that a bug could bypass.
• Propagate identity end to end. The permissions that gate retrieval should trace back to the authenticated user, not to a shared service account with broad access.

Protect the data itself

• Encrypt embeddings and source data at rest and in transit. Embeddings are not anonymized data; they can leak information about their source content and deserve the same protection as the originals.
• Minimize what you index. The less sensitive data sits in a retrievable store, the smaller the consequence of any single failure.

Tools, agents & least privilege

The moment you give a model tools — the ability to call functions, hit APIs, query databases, send messages, or execute code — you convert a content risk into an action risk. OWASP names the failure mode directly: excessive agency, the granting of more capability, permission, or autonomy than the task requires. An agent that can be prompt-injected and can also move money is a categorically more dangerous system than a chatbot that can only talk.

Apply least privilege to every tool

• Grant the minimum set of tools needed for the task, and scope each tool as tightly as possible. A tool that reads records should not also be able to delete them; a tool that sends notifications should not be able to send arbitrary email.
• Scope permissions to the current user and session, not to a powerful shared identity. If the agent acts on behalf of a user, it should inherit that user's limits.
• Constrain tool parameters. Validate and bound every argument the model supplies — amounts, recipients, identifiers, file paths — with server-side checks the model cannot talk its way past.

Require approval for consequential actions

• Insert a human-in-the-loop gate before high-impact, irreversible, or high-value actions: financial transfers, data deletion, external communications, privilege changes. The model proposes; a person confirms.
• Make approval meaningful. Surface exactly what will happen, in plain terms, so the approver can catch a manipulated action rather than rubber-stamping it.

Contain the blast radius

• Run tool execution and any generated code in sandboxed, isolated environments with no ambient access to production secrets or networks.
• Set hard limits: spending caps, rate limits, and quotas per user and per session, enforced outside the model so they hold even when the model is compromised.
• Design for reversibility. Prefer actions that can be undone, logged, and reviewed over ones that cannot.

Because agents combine so many of these risks, they deserve dedicated adversarial testing before and after launch — the kind of ongoing pressure a continuous AI red team applies. Least privilege is what makes an agent's mistakes survivable; testing is what tells you whether your least-privilege boundaries actually hold.

Model & supply-chain risk

An LLM application is only as trustworthy as the model, data, and dependencies underneath it. OWASP dedicates categories to training-data poisoning and supply-chain vulnerabilities because the components you did not build — base models, fine-tuning datasets, embeddings, adapters, and the libraries that load them — can carry backdoors, hidden triggers, or license and integrity problems into your stack.

Establish provenance and integrity

• Source models and datasets from vetted providers, and record where each component came from. Maintain an inventory — effectively a bill of materials — for the models, datasets, and major dependencies in your AI pipeline.
• Verify integrity on acquisition and on load. Pin versions, check signatures or hashes where available, and fail closed if a component does not match what you approved.
• Prefer formats and loaders that do not execute arbitrary code on deserialization. Some legacy model-serialization formats can run code when loaded; treat those as hazardous.

Guard against poisoning

• Curate and screen any data used for training or fine-tuning. Poisoned examples introduced during training can implant behavior that only activates on a specific trigger — invisible in normal testing.
• Isolate and evaluate third-party or community models before production use. Test them adversarially for backdoors and unexpected behavior, not just for accuracy.
• Re-vet on updates. A new version of a model or dataset is a new supply-chain event and deserves the same scrutiny as the first.

Vetting external models, datasets, and dependencies for poisoning and hidden triggers before they enter your pipeline is a specialized discipline; it is the focus of model supply-chain security. The goal is a clear, defensible sign-off that every component in your AI stack is one you chose deliberately and verified.

Secrets & access control

LLM applications are unusually good at leaking secrets, because they process and generate free-form text and are often wired to many systems at once. Two related risks matter here: secrets the model can reach, and secrets that end up in places the model or its logs expose.

Keep secrets out of the model's reach

• Never place API keys, credentials, or tokens in prompts or system messages. Anything in the context window can be surfaced through injection or disclosure.
• Hold secrets in a managed secrets store and inject them into tool execution server-side, so the model orchestrates actions without ever seeing the credentials that perform them.
• Scope and rotate credentials aggressively. Each tool and integration should use narrowly scoped, short-lived credentials that limit what a leaked secret can do.

Enforce identity and authorization around the model

• Authenticate every request to the LLM application and carry the user's identity through to retrieval and tool use, so authorization decisions are made on the real principal.
• Do not rely on the model to enforce access control. The model is not an authorization boundary; permission checks must live in deterministic code that the model cannot influence.
• Apply the principle of least privilege to the application's own service identities, so a compromise of the app does not hand over the keys to everything it can reach.

Guardrails & content safety

Guardrails are the runtime policies that decide what the application will and will not say or do. They are not a substitute for the structural controls above, but they are an essential layer — the place where your organization's content, safety, and compliance requirements are enforced on every interaction.

Define and enforce policy at runtime

• Enumerate what is out of bounds for your application — categories of content, actions, and disclosures that must never occur — and enforce those rules on both inputs and outputs.
• Apply topical guardrails so the assistant stays within its intended domain and refuses to be repurposed into a general-purpose tool that leaks capability or brand risk.
• Version your guardrail policies and treat changes as reviewable security changes, not casual configuration tweaks.

Fail safely

• Decide deliberately how the system behaves when a guardrail or upstream model is unavailable. For most enterprise use cases, failing closed — refusing rather than passing content through unchecked — is the safer default.
• Make refusals graceful and logged, so users get a usable experience and security teams get a signal.
• Layer guardrails with the gateway. Enforcing content and safety policy inline, alongside injection and leakage defenses, keeps behavior consistent across every application and model you run.

Logging, observability & audit

You cannot secure what you cannot see, and LLM applications are opaque by default. Robust observability is what turns an incident from a mystery into a timeline — and what lets you prove, to auditors and to yourselves, that your controls are working.

Log what matters

• Capture the full interaction: prompts, retrieved context, tool calls and their arguments, model responses, and the decisions your guardrails and gateway made. Without tool-call and context logging, agent incidents are nearly impossible to reconstruct.
• Record the identity behind every request, so actions can be attributed to a user and session.
• Make security-relevant logs immutable and tamper-evident, so they stand up as evidence.

Handle sensitive data in logs responsibly

• Logs are now a data-disclosure surface. Redact or tokenize sensitive fields before they are written, and apply strict access controls and retention limits to the logs themselves.
• Encrypt logs at rest and in transit, and treat log storage with the same care as the production data it may reflect.

Monitor and alert

• Watch for the signals that precede an incident: spikes in blocked prompts, repeated jailbreak attempts, anomalous tool usage, unusual data-access patterns, and cost or rate anomalies that can indicate abuse or model denial of service.
• Route those signals into your existing security operations so LLM events are triaged alongside the rest of your estate, not stranded in a separate console.

Evaluation & regression testing

Adversarial testing tells you whether an attacker can break your application; evaluation tells you whether your own changes have broken it. The two are complementary, and mature LLM security programs run both. Because a model, a prompt, or a retrieval change can silently alter behavior, security needs a repeatable evaluation harness the same way functional software needs a test suite.

Build a security evaluation suite

• Assemble a standing set of security test cases: known injection strings, jailbreak templates, data-exfiltration prompts, out-of-scope requests, and inputs that previously caused a failure. Every real incident should become a permanent test case.
• Encode the expected behavior as an assertion — the model should refuse, redact, stay in scope, or produce schema-valid output — so results are pass or fail, not a matter of opinion.
• Cover the failure classes that matter to your product: refusal quality, PII leakage, prompt-disclosure resistance, tool-call safety, and output validity. Breadth here is what catches regressions.

Gate changes on the suite

• Run the evaluation suite automatically before any model upgrade, prompt edit, guardrail change, or new data source reaches production. Treat a regression the way you would a failing unit test — it blocks the release.
• Track scores over time. A slow drift in refusal quality or leakage rate is a warning you want to see on a trend line, not discover in an incident.
• Judge model output carefully. Automated grading, including using a separate model as an evaluator, scales well but can itself be gamed; sample and human-review the high-stakes categories rather than trusting the automated score blindly.

Evaluation and red-teaming reinforce each other: red-teaming discovers new weaknesses, and each discovery becomes a regression test that guarantees the weakness stays closed. Together they turn LLM security from a point-in-time audit into a property the system keeps release over release.

Red-teaming & continuous testing

Every control described so far is a hypothesis until it has survived a real attack. Because models change, prompts evolve, and new jailbreak techniques appear constantly, LLM security cannot be a one-time assessment. It has to be continuous.

Test adversarially, not just functionally

• Attack your own application the way a threat actor would: direct and indirect prompt injection, jailbreaks, data-exfiltration attempts, tool misuse, and attempts to induce disclosure of system prompts or sensitive data.
• Test the whole system, not just the model. The interesting failures are usually in the seams — how retrieved content flows into prompts, how outputs reach tools, how permissions are enforced.
• Prioritize findings by exploitability and impact, and drive them to a fix with an owner and a deadline, the way you would any vulnerability.

Make it continuous and evidence-producing

• Run adversarial testing on a schedule and on every meaningful change — a new model version, a new tool, a new data source, a prompt revision. Any of these can reopen a closed hole.
• Keep the results. A record of what was tested, what was found, and what was fixed is exactly the evidence that boards, customers, and auditors increasingly ask for.

Standing up this capability internally is real work; an always-on continuous AI red team provides it as a service, returning prioritized, fixable findings and the proof of resilience that goes with them. The point is not a single clean report — it is a durable practice that keeps pace with how fast the systems change.

Incident response for LLM applications

Even a well-defended LLM application will eventually have an incident: a jailbreak that works, a poisoned document that leaks data, an agent that takes an action it should not have. Response is a control in its own right, and LLM incidents have enough distinctive features that a generic playbook is not enough. Prepare before you need it.

Prepare a plan tailored to AI failures

• Extend your existing incident-response process to cover AI-specific scenarios: prompt-injection compromise, data leakage through model output, agent misuse, model or supply-chain compromise, and abusive load that degrades service.
• Define severity in AI terms. A jailbreak that only produces off-brand text is not the same as one that exfiltrates customer data or triggers a financial action; classify accordingly.
• Establish escalation paths that include the people who understand the model and the application, not only the traditional on-call responders.

Contain, then recover

• Know your containment levers in advance: revoking a tool's credentials, disabling a specific tool or agent, tightening or failing the gateway closed, rolling back a prompt or model version, or removing a poisoned document from the index and re-embedding.
• Preserve evidence. The full interaction log — prompts, retrieved context, tool calls, outputs, and gateway decisions — is what lets you reconstruct what happened and prove the scope. Immutable logging pays for itself here.
• Scope the blast radius using identity and session data: which users, which tenants, which data, which actions. Least-privilege boundaries make this answer small and quick.

Learn and close the loop

• Run a blameless post-incident review focused on which layer of defense failed and why, and which layer contained the damage.
• Turn every incident into a permanent regression test and, where relevant, a new gateway rule or guardrail, so the same attack cannot recur silently.
• For severe or novel incidents, bring in specialist help. Expert AI incident response can shorten containment and root-cause analysis when the failure mode is unfamiliar.

Post-quantum encryption of data in transit and at rest

The final area is the one most easily deferred and most expensive to defer: the cryptography protecting the data your LLM application handles. Prompts, embeddings, fine-tuning corpora, and logs frequently contain information that will still be sensitive for years — which puts them squarely in the path of the harvest-now, decrypt-later threat, in which an adversary records encrypted traffic today to decrypt once quantum computers mature.

Most of today's transport security rests on public-key math that a sufficiently large quantum computer could break. Data protected only by classical public-key cryptography is therefore already exposed if it will still matter when that capability arrives. The mitigation is to adopt the post-quantum standards finalized by NIST, and to do so now for anything long-lived:

• ML-KEM-1024 (formerly CRYSTALS-Kyber, NIST FIPS 203) for key encapsulation, protecting the key exchange that secures data in transit at a high quantum security level.
• Hybrid X25519 + ML-KEM key exchange, which runs a proven classical algorithm alongside the post-quantum one, so the connection stays secure even if either scheme is later weakened.
• AES-256 for symmetric encryption of data at rest and in transit — including prompts, embeddings, training data, and logs — which remains robust against known quantum attacks at that key length.

The data flowing through an LLM is exactly the kind of concentrated, high-value, long-lived information worth protecting against a decade of adversaries — not just this year's. Building post-quantum encryption into your AI data path is a control you will be glad you adopted early.

How Deflected helps

The checklist above is vendor-neutral by design; you can implement most of it with disciplined engineering. Where teams want the controls delivered as coordinated capability rather than a standing internal project, Deflected maps directly onto the areas above.

For how these fit together with governance, encryption, and expert services across an enterprise AI program, see the Deflected platform overview.

Frequently asked questions

The takeaway

Securing an LLM application is not about finding the one control that stops the attacks. It is about accepting that the model can be turned against you, then building enough discipline around it — in input handling, output handling, retrieval, tool permissions, supply chain, secrets, guardrails, observability, testing, and encryption — that the model's worst behavior stays survivable. That is what defense in depth means in the AI era.

Work the checklist by area, assign owners, threat-model your application, and verify continuously. Anchor your program to the OWASP Top 10 for LLM Applications so you share a language with peers and auditors, and protect long-lived data in your AI pipeline with post-quantum encryption before the harvest-now, decrypt-later window closes. Do that, and you can ship AI features at the speed your business wants without inheriting risk you cannot see or bound.