Artificial Intelligence Security Case Studies (for Linux Bash Users)

Your AI can be one curl away from leaking secrets. As AI systems move from prototypes to production, their attack surface expands quickly: model endpoints, data pipelines, third‑party packages, and even the documents you feed into RAG. This post walks through practical, shell‑first case studies you can reproduce, learn from, and bake into your DevSecOps workflow.

What you’ll get:

• Why AI security deserves first-class treatment in your stack

• 4 real case studies with actionable, command-line steps

• Installation commands for apt, dnf, and zypper wherever tools are used

Why AI security matters (and why Bash is your friend)

• AI systems touch sensitive data, run third‑party code, and connect to the internet—three ingredients attackers love.

• Attacks are often logic-level (prompt injection, data poisoning, supply chain) rather than purely network-level. You need both app logic checks and infra hygiene.

• Linux and Bash give you reproducible, automatable guardrails you can run locally, in CI, and on servers without heavyweight dependencies.

---

Case Study 1: RAG prompt injection via hidden instructions in ingested docs

Context: A red team slipped hidden instructions in HTML comments and CSS‑hidden spans inside internal docs. A RAG pipeline embedded the raw HTML. At query time, the LLM obeyed the hidden instructions and attempted to exfiltrate data via tool calls.

What went wrong:

• HTML (and PDFs → HTML) were ingested without sanitization.

• No content scanning for exploit phrases.

• The assistant had broad tool access without tight allowlists.

Actionable steps: 1) Strip risky markup, comments, and hidden text before embedding. 2) Scan content for injection patterns; quarantine suspicious files. 3) Restrict the assistant’s tool use to a minimal allowlist; log all tool calls.

Tools we’ll use: pandoc, ripgrep, jq

Install:

• apt:

  sudo apt update
  sudo apt install -y pandoc ripgrep jq
  

• dnf:

  sudo dnf install -y pandoc ripgrep jq
  

• zypper:

  sudo zypper refresh
  sudo zypper install -y pandoc ripgrep jq
  

Sanitize and scan your corpus:

#!/usr/bin/env bash
set -euo pipefail

IN=${1:-docs}
OUT=${2:-sanitized}

mkdir -p "$OUT"

sanitize_one() {
  local src="$1"
  local base rel dst ext
  rel="${src#$IN/}"
  base="$(basename "$src")"
  dst="$OUT/${rel%.*}.txt"
  mkdir -p "$(dirname "$dst")"

  ext="${src##*.}"
  case "$ext" in
    html|htm)
      # Drop HTML comments and hidden spans, then convert to plain text
      sed -E 's/<!--.*?-->//gs; s/<span[^>]*style="[^"]*display:\s*none;?[^"]*"[^>]*>.*?<\/span>//g' "$src" \
        | pandoc -f html -t plain -o "$dst"
      ;;
    md)
      pandoc -f markdown -t plain -o "$dst" "$src"
      ;;
    txt)
      cp "$src" "$dst"
      ;;
    *)
      # Fallback: try pandoc if known, otherwise skip
      if pandoc -o "$dst" "$src" >/dev/null 2>&1; then :; else return 0; fi
      ;;
  esac

  # Scan for common injection cues
  if rg -nEi '(ignore (all|previous) instructions|system prompt|exfiltrat|upload to|send to|delete logs|base64)' "$dst" >/tmp/inj.$$; then
    echo "{\"file\":\"$dst\",\"hits\":$(jq -Rs '.' </tmp/inj.$$)}" | jq .
  fi
}

export -f sanitize_one

find "$IN" -type f -print0 \
  | xargs -0 -I{} bash -c 'sanitize_one "$@"' _ {}

• Pipe the JSON output into a SIEM or a simple review queue.

• Only feed $OUT into your embedding/indexing pipeline.

• Combine with a tool allowlist in your agent to prevent side-effects from untrusted content.

---

Case Study 2: Exposed model endpoint with weak/no auth

Context: A staging, OpenAI‑compatible server bound to 0.0.0.0:8000 leaked capability metadata and accepted arbitrary requests. Attackers scanning common ports could enumerate models and attempt prompt‑based data exfiltration via connectors.

Actionable steps: 1) Audit listeners; bind inference servers to localhost by default. 2) Enumerate exposed endpoints across your subnets. 3) Add auth (token, mTLS) and network controls; prefer reverse proxies.

Tools we’ll use: nmap, curl, jq

Install:

• apt:

  sudo apt update
  sudo apt install -y nmap curl jq
  

• dnf:

  sudo dnf install -y nmap curl jq
  

• zypper:

  sudo zypper refresh
  sudo zypper install -y nmap curl jq
  

Find and test endpoints:

# 1) See what's listening locally
ss -ltnp | awk 'NR==1 || /:8(000|081|088|443)/'

# 2) Scan your VPC/subnet for common LLM ports
nmap -p 8000,8080,7860,8888 --open 10.0.0.0/16 -oG - | awk '/Ports:.*open/ {print $2,$0}'

# 3) Probe an OpenAI-compatible API
API=http://10.0.12.34:8000
curl -s "$API/v1/models" | jq .
curl -s "$API/v1/chat/completions" \
  -H 'Content-Type: application/json' \
  -d '{"model":"whatever","messages":[{"role":"user","content":"hi"}]}' | jq .

Lock it down:

• Bind to loopback:

  # Example uvicorn
  uvicorn app:app --host 127.0.0.1 --port 8000
  

• Remote access via SSH tunnel (no direct exposure):

  ssh -L 8000:127.0.0.1:8000 user@server
  

• Put nginx/traefik in front with auth and rate limits; restrict at the network layer (security groups, firewall).

---

Case Study 3: Data poisoning in training sets

Context: A crowdsourced dataset accumulated label‑flipped and near‑duplicate samples from a few accounts. Models trained on the full dataset misclassified a critical class at a higher rate. A quick content and contributor audit would have caught it.

Actionable steps: 1) Detect near‑duplicates with fuzzy hashing to reduce attack surface. 2) Check label distributions and contributor outliers before training. 3) Gate new data with quarantine + review on drift.

Tools we’ll use: ssdeep, csvkit, jq

Install:

• apt:

  sudo apt update
  sudo apt install -y ssdeep python3-csvkit jq
  

• dnf:

  sudo dnf install -y ssdeep python3-csvkit jq
  

• zypper:

  sudo zypper refresh
  sudo zypper install -y ssdeep python3-csvkit jq
  

Fuzzy‑hash and quarantine near‑duplicates:

# Build a baseline from your trusted set
ssdeep -br data/trusted > trusted.ssdeep

# Compare new submissions against baseline
mkdir -p quarantine clean

while IFS= read -r -d '' f; do
  # If similarity >= 90, treat as near-duplicate (tune threshold for your domain)
  if ssdeep -bm trusted.ssdeep "$f" | awk 'NR>1 && $1+0 >= 90 {exit 0} END {exit 1}'; then
    echo "Quarantine: $f"
    cp "$f" quarantine/
  else
    cp "$f" clean/
  fi
done < <(find data/new -type f -print0)

Spot label and contributor anomalies in CSV:

# Expecting columns: id,label,contributor,text
CSV=data/new/metadata.csv

echo "Label distribution (descending):"
csvcut -c label "$CSV" | tail -n +2 | sort | uniq -c | sort -nr

echo "Top contributors:"
csvcut -c contributor "$CSV" | tail -n +2 | sort | uniq -c | sort -nr | head

echo "Label x Contributor cross-tab (sample):"
csvcut -c label,contributor "$CSV" | tail -n +2 | sort | uniq -c | sort -nr | head 20

Feed only clean/ into training. Review quarantine/ and high‑influence contributors before merging.

---

Case Study 4: Model supply chain compromise via malicious dependency

Context: In late 2022, the PyTorch nightly package was impacted by a malicious dependency (“torchtriton”) on PyPI that could exfiltrate data on install. Model projects routinely depend on third‑party wheels from public indexes—pinning and auditing is mandatory.

Actionable steps: 1) Audit dependencies regularly for known vulnerabilities. 2) Pin exact versions and hashes; fail closed on mismatch. 3) Separate build from deploy; only ship vetted artifacts.

Tools we’ll use: python3-pip, pip-audit, pip-tools

Install Python’s package manager:

• apt:

  sudo apt update
  sudo apt install -y python3-pip
  

• dnf:

  sudo dnf install -y python3-pip
  

• zypper:

  sudo zypper refresh
  sudo zypper install -y python3-pip
  

Install auditing and locking helpers (user scope):

python3 -m pip install --user pip-audit pip-tools
export PATH="$HOME/.local/bin:$PATH"

Audit and lock:

# 1) Snapshot current environment
pip freeze > requirements.txt

# 2) Audit for known CVEs
pip-audit -r requirements.txt

# 3) Create a hash-locked requirements file from your inputs
# If you use pyproject.toml, point pip-compile at it; otherwise, seed with a minimal requirements.in
echo "torch==2.3.*" > requirements.in
echo "transformers==4.41.*" >> requirements.in
pip-compile --generate-hashes requirements.in -o requirements.lock

# 4) Install with hash verification (CI/CD, build images)
python3 -m pip install --no-deps --require-hashes -r requirements.lock

Best practices:

• Build from a private mirror of PyPI; promote only scanned artifacts.

• Periodically pip-audit in CI and fail on new issues.

• Rebuild images regularly; don’t let “latest” drift silently.

---

Pulling it together: a minimal AI security checklist you can automate

• Pre-ingest sanitization and injection scanning for RAG corpora.

• Endpoint audits: bind to localhost, enumerate exposures, add auth, and log.

• Dataset hygiene: de-duplication and contributor/label drift checks.

• Supply chain: audit, pin, and verify hashes; promote via a private index.

Make these steps cronable or wire them into your CI. The commands above are composable and fast, which makes them good candidates for pre-merge and pre-deploy gates.

Conclusion and next steps

AI security isn’t abstract—it’s bashable. Start by picking one case study that maps to your environment:

• If you run RAG, implement the sanitization script and block suspicious docs.

• If you host inference, lock endpoints to loopback and add a simple auth layer today.

• If you curate data, run the fuzzy hash and CSV checks before the next training job.

• If you ship Python models, add pip-audit and hashed installs to CI.

Need a ready-to-run starter? Drop the above snippets into a repository, add a Makefile target for each check, and wire them into your pipeline. Your future incident report will be a non-event.