The 8 security threats to assess before deploying LLMs and how to mitigate each one
An employee pastes an entire customer list with ID numbers into an AI assistant. That data, along with the prompt, goes directly to an external model's API. No one meant harm. The tool was just too useful. The core problem with enterprise AI security is that LLMs have no clear boundaries. This article uses a threat-mitigation table to answer what decision-makers care about: data leakage, prompt injection, unauthorized access, and which three controls to lock down first.
By
Tenten AI FDE 團隊
導入方法論
Published
September 7, 2025
Read time
5 分鐘
The 8 security threats to assess before deploying LLMs and how to mitigate each one
An employee pastes an entire customer list with ID numbers into an AI assistant. That data, along with the prompt, goes directly to an external model's API. No one meant harm. The tool was just too useful. The core problem with enterprise AI security is that LLMs have no clear boundaries. This article uses a threat-mitigation table to answer what decision-makers care about: data leakage, prompt injection, unauthorized access, and which three controls to lock down first.
A financial services customer opened an internal AI assistant to their workforce last year to speed up claims document review. Three weeks after launch, the security team found something in the audit logs. An employee had pasted an entire customer list, complete with ID numbers and policy numbers, into the chat and asked it to 'organize this into a table for me.' That data, along with the prompt, went straight to the external model's API unchanged.
No one acted with malice. The tool was simply too useful. People found it so useful they forgot it was a data egress point.
That's the core problem with enterprise AI security
Unlike traditional systems, LLMs have no clear boundary. They blend input and instructions into a single natural language stream. They only become valuable by connecting to your most sensitive internal knowledge. If you haven't run a proper risk assessment before deployment, you've handed your company's data controls to a system that can be tricked by a single sentence.
The reference table below is the actual checklist we work through line by line during assessments. The left side lists the threats. The right side lists the concrete safeguards we implement, not principles, but specific actions.
The 8 threats and corresponding defenses
| Threat | What Actually Happens | Corresponding Safeguard |
|---|---|---|
| 1. Data Leakage | An employee pastes PII or trade secrets into a conversation that travels via API to an external model or is retained for training | Deploy DLP pre-filtering and PII masking; negotiate zero-retention clauses with vendors; shift sensitive scenarios to private deployment or models running in a VPC |
| 2. Prompt Injection | Malicious instructions ("ignore the preceding instructions") embedded in retrieved web pages, PDFs, or emails hijack the model's behavior | Isolate system prompts from user input and document content at the architectural layer; tag and sanitize retrieved content by source; require human approval for high-risk actions |
| 3. Unauthorized Access | RAG retrieval bypasses existing access controls. An employee in Department A retrieves salary documents from Department B | Apply the original access control list at the retrieval layer with document-level permission filtering; pass the user's identity with each query instead of using a single service account to fetch everything |
| 4. Unsafe Output Handling | Model output is executed directly downstream (SQL, shell, HTML), creating an injection vulnerability | Treat model output as untrusted input; use parameterized queries, escape output, and never call eval() directly |
| 5. Hallucinations Influencing Decisions | The model confidently fabricates regulations or numbers that get adopted as fact | Require all output to cite sources and link to originals; set confidence thresholds for critical domains and train teams to expect 'I don't know' as a valid answer |
| 6. Shadow AI | Employees privately connect ChatGPT, third-party plug-ins, and other tools outside your visibility | Offer a compliant official option to reduce incentive to circumvent it; monitor and control unauthorized AI traffic at the network layer |
| 7. Supply Chain Risk | Third-party models, open-source libraries, or vector databases contain backdoors or vulnerabilities | Lock model versions and sources; scan dependencies; evaluate vendors' security certifications and data residency policies |
| 8. Over-Privileged Agents | Agentic workflows granted write, payment, or email permissions create irreversible consequences if compromised | Apply least-privilege principles; require human approval for irreversible actions; log every tool call completely |
How to use this table without it becoming shelf-ware Most enterprises do an AI security assessment and then watch it sit gathering dust in a slide deck. The question isn't whether you know these threats exist. It's whether those safeguards are in place once the system goes live.
We learned this lesson the hard way. Item 3, permission filtering, looked fine during the demo when everyone tested with an admin account. But once we went live with role-based access, we discovered the retrieval layer wasn't passing user identity at all. Unauthorized queries went through. Now we test permission filtering and prompt injection with real low-privilege accounts and real malicious documents, not just by reviewing the architecture.
Compliance matters too. In Taiwan, financial and healthcare customers need to add personal data protection law, Financial Supervisory Commission outsourcing rules, and data residency requirements on top. Private deployment exists because some data legally cannot leave the jurisdiction or be retained by an external model. This determines which models you can use, and you need to decide it at the very start of the assessment. Otherwise you'll discover midway through architecture that you need to rebuild everything.
A practical priority sequence
You don't need all eight from day one. Based on our experience, locking down three things eliminates most of the risk: data leakage (DLP plus masking), unauthorized access (retrieval inheriting permissions), and human approval gates for irreversible agent actions. These three block the worst catastrophes. The rest can be added as adoption grows. At Tenten, when we conduct FDE frontline deployments, the security assessment isn't a handoff document. It's a checklist we open during the engineer's first week on the ground. We test every item with real accounts and real malicious inputs. A system that passes the demo doesn't matter. What matters is that once people are actively using it, your audit logs show nothing leaked.
One stuck workflow
is enough to begin
Tell us what the team does today, where it breaks down, and what a better working day should look like.