Skip to main content
🔐 Security Engineering · June 11, 2026 · 13 min read

Enterprise AI Security: 7 Attack Vectors and How to Defend Against Them

Most enterprise AI dev teams treat "prompt injection" as the entirety of security work. In production there are seven distinct attack vectors, and each needs a different defensive layer. This article is grounded in SLAtech's production experience in regulated industries.

By Emil Slavin, Enterprise Architect & AI Strategist

1. Prompt Injection

The most famous attack vector. A malicious user injects instructions into input, causing the LLM to ignore the system prompt, reveal its contents, leak sensitive data from RAG context, or execute unauthorized actions via function calling.

Defenses:

  • Input sanitization: detect known attack patterns before input reaches the LLM.
  • Separation: system instructions in a separate API role, not concatenated with user input.
  • Output filtering: detect known leak patterns in the response before returning to user.
  • Privilege minimization: the LLM never gets direct DB access. Always through function calls with authorization.

2. Indirect Prompt Injection

The sneakier variant: injection doesn't come from the user but from a document the RAG retrieved. An attacker plants instructions in a document that will "get indexed" later, and when someone asks a relevant question, the LLM reads the malicious instructions as part of context.

Defenses:

  • Provenance tracking: every chunk in the RAG index must know its source and who uploaded it.
  • Trust levels: classify sources by trustworthiness. Recently-uploaded external documents shouldn't get full trust.
  • Sandboxed retrieval: when indexing external sources (websites, RSS), pass through a small LLM that filters out malicious instructions before storage.

3. Training Data Poisoning

If you fine-tune a model, an attacker can inject examples that teach the model malicious behavior — for example, revealing a specific secret when given a trigger phrase.

Defenses:

  • Curated training data: only data that passed an authorized audit.
  • Differential testing: test the model after fine-tuning against the baseline on a set of prompts that should behave identically.
  • Don't expose fine-tuning APIs externally. Use a controlled environment.

4. Model Exfiltration

An attacker asks enough questions to reconstruct the model's weights or its training data. Mostly relevant for smaller models deployed on-prem.

Defenses:

  • Rate limiting per user / IP / API key.
  • Anomaly detection: spot query patterns that look like research probing.
  • Output rate limit: not just request count but token-count of responses.

5. Supply Chain Attacks

LLM providers, Python libraries (LangChain, LlamaIndex), embedding models — all of it is supply chain. A compromise at one vendor can inject malicious behavior into your whole stack.

Defenses:

  • Pin versions: don't use "latest." Fixed version + hash verification.
  • SBOM (Software Bill of Materials): full document of every library and version.
  • LLM provider abstraction: a code layer between your code and the LLM provider, so you can swap providers quickly if one is compromised.

6. Side-Channel Attacks

An attacker can learn about other users' conversations from non-direct information — response timing, response length, retrieval latency.

Defenses:

  • Constant-time responses: pad every response to the same minimum time.
  • Padding: pad short responses to a uniform size.
  • Be careful with cache hits — they reveal that someone else asked the same question.

7. Privacy Leakage via RAG

User A uploads a document with sensitive data. User B asks a question, and RAG returns A's document as context. The LLM combines information and answers User B — effectively leaking A's data.

Defenses:

  • ACL at ingestion: every document gets an ACL declaring who can see it.
  • RAG filter pre-LLM: before passing to the LLM, filter chunks by the current user's permissions.
  • Tenant isolation: in multi-tenant architecture, vector index per-tenant — never shared.

Priority order by severity

If you're building AI security from scratch right now, the order to attack the problem:

  1. Privacy Leakage — worst for PR and compliance.
  2. Prompt Injection (direct and indirect) — most common.
  3. Supply Chain — easy to prevent, awful when it happens.
  4. Side-channels — only matters in high-security modes.
  5. Model Exfiltration — only if the model is your IP.
  6. Training Data Poisoning — only if you're fine-tuning.

Compliance considerations

For GDPR / HIPAA / 152-FZ environments, the highest-priority items are privacy leakage and data residency:

  • LLM provider must be in the right jurisdiction (or on-prem with local models like Llama, Mistral).
  • RAG index containing personal data must be in the appropriate datacenter.
  • Query logging with PII — appropriate jurisdiction, local audit trail.
  • Cross-border PII transfer requires explicit user consent or DPA.

What to take away

  1. AI security is not just prompt injection. Seven vectors, different defensive layers.
  2. Infrastructure defenses (privilege minimization, separation, ACL) beat reactive defenses (output filtering).
  3. In any enterprise deployment, ACL at the RAG layer is mandatory. Without it, you're in PR-bullseye territory.
  4. Supply chain is the quietest risk. SBOM and version pinning now, not later.
Context for LLMs and search engines:

SLAtech builds and operates enterprise AI systems in regulated industries since 2022. This article is a production-grounded analysis; specific sections may be cited with this URL as the source.