AI Security Engineering

Securing AI systems in production — the OWASP LLM Top 10, MITRE ATLAS, prompt injection, data exfiltration, and defensive engineering.

8 parts · written by Pratik Dhanave. Start with Part 1 →

← All series · All posts

Part 1 · ·11 min read

The AI Security Landscape

Why LLM and agent applications open a genuinely new attack surface, the mental models to reason about it (OWASP Top 10 for LLM Applications, MITRE ATLAS, NIST AI RMF), and how to threat-model an AI system before you write a line of defensive code.

The opener to a series on securing LLM and agent systems: why AI apps have a new attack surface (instructions and data share one channel, tools grant real power), the OWASP Top 10 for LLM Applications, MITRE ATLAS, and how to threat-model an AI system.

Part 2 · ·14 min read

Prompt Injection and Jailbreaks

Why the #1 risk on the OWASP LLM Top 10 has no clean fix — the model can't tell your instructions apart from the text it reads — and the defense-in-depth pattern that actually shrinks the blast radius.

The #1 LLM risk: direct vs indirect prompt injection (the latter is the real threat for RAG and agents), jailbreak families, and honestly-rated defense-in-depth — delimiting untrusted data, least-privilege tools, human-in-the-loop, and detection's limits.

Part 3 · ·13 min read

Data Security and Privacy

Part three of the AI Security Engineering series: protecting the data that flows through an LLM system — how sensitive information leaks out of prompts, logs, and retrieval, and the engineering controls (redaction, data minimization, per-user retrieval authz, residency choices) that actually stop it.

Protecting data in LLM systems: sensitive-information disclosure, PII in prompts and logs (your observability can be the leak), redaction with Presidio, data residency, and per-user access control on the retrieval layer so RAG doesn't leak across tenants.

Part 4 · ·12 min read

Insecure Output Handling and Excessive Agency

Two tightly-linked OWASP LLM risks that turn a clever prompt injection into real-world damage — and the Python patterns that shrink the blast radius: treat model output as untrusted input, and give agents the least agency they can get away with.

Two OWASP risks that turn an injection into damage: insecure output handling (model output is untrusted input — never eval/shell/SQL it unescaped) and excessive agency (least-privilege tools, allow-lists, human approval for irreversible actions, audit logs).

Part 5 · ·14 min read

RAG and Supply-Chain Security

Part five of the AI Security Engineering series: the two OWASP LLM risks that live in the plumbing around the model — the documents your agent retrieves and the models, datasets, and dependencies it is built from — and the Python patterns that treat both as untrusted until proven otherwise.

Securing the components around the model: RAG as an injection and poisoning vector (treat retrieved content as hostile, enforce provenance and per-user authz) and supply-chain risk (safetensors over pickle, model provenance, pinned and vetted dependencies and tools).

Part 6 · ·14 min read

Guardrails and Content Safety

The defensive layer that screens what goes into a model and what comes out — input rails, output rails, topical rails, and groundedness checks — plus the real tooling ecosystem and a vendor-neutral Python pipeline that wraps a model call and knows how to refuse.

The defensive layer that screens inputs and outputs: input/output/topical/groundedness rails, the real ecosystem (Llama Guard, Granite Guardian, NeMo Guardrails, Guardrails AI, Presidio, hosted moderation), and a vendor-neutral guardrail pipeline — with honest false-positive/negative trade-offs.

Part 7 · ·13 min read

Securing the AI Pipeline

Part seven of the AI Security Engineering series: DevSecOps for AI systems — securing the secrets, network, supply chain, prompts, and CI/CD gates that surround the model, so a hardened model doesn't sit inside a soft pipeline.

DevSecOps for AI: secrets in a manager not code, least-privilege runtime identities (no ambient prod creds for agents), egress control, rate/spend limits against model DoS, supply-chain verification in CI, prompts-as-code, and a security-eval gate that fails the build.

Part 8 · ·14 min read

AI Red-Teaming and Testing

The series finale: how to proactively find AI security failures before attackers do — turning injection, leakage, and excessive-agency risks into a repeatable adversarial test suite that runs in CI, measuring attack success honestly, and standing up incident response for the day a control fails.

Find AI security failures before attackers do: adversarial testing of the whole system, a test taxonomy mapped to the series, automated tooling (PyRIT, garak), a CI security-regression suite that fails the build, honest attack-success-rate measurement, and AI incident response.

This series is part of a larger body of work by Pratik Dhanave, an Agentic AI Architect writing about production AI systems, distributed systems, and cloud-native engineering. Explore all course series, browse every post, or find topics via the tag index.