OWASP LLM Top 10 in Production: How I Audited My TypeScript Agent Pipeline Against All 10 Risks — and What I Found

I was reviewing a system prompt for an MCP agent I'd written three weeks earlier when something hit me hard: the prompt was accepting instructions from the output of an external tool. No sanitization. No validation. No limits whatsoever on what it could do with that output. The tool called a public API, got back JSON, and that JSON landed directly in the model's context.

That's when I opened the ) you get lockfile visibility — but that's not the same as auditing.

What I added: pnpm audit as an explicit CI step before deploying any agent. It doesn't eliminate the risk, but it makes it visible.

LLM06 — Sensitive Information Disclosure

This is where the second uncomfortable finding showed up: my system prompts contained configuration context that included names of internal tools, data structure details, and some system defaults. That context reaches the model — and if the model echoes it in its output, it's exposed.

The rule I applied: nothing you wouldn't want to see in a public log should be in a system prompt without explicit confidentiality marking. And even that isn't a guarantee — it's mitigation.

// Separate technical config from agent instructions

const SYSTEM_PROMPT_PUBLIC = `

You are a development assistant. You can use available tools

to answer technical questions.

`;



// This does NOT go into the system prompt — it lives in a separate config layer

const AGENT_CONFIG_PRIVATE = {

  toolEndpoints: process.env.TOOL_ENDPOINTS,

  internalSchema: process.env.INTERNAL_SCHEMA,

};

LLM07 — Plugin Design Flaws

My MCP tools are essentially plugins. The risk here is that a tool has broader permissions than it actually needs. I reviewed each tool and applied least privilege: a tool that reads files doesn't need write access; a tool that queries an API doesn't need filesystem access.

This connects directly to what I wrote about where I talk about traces that survive the edge. That kind of observability helps here too: if you can't see which tools the agent called and with what args, you can't audit LLM08 in production.

Applied Checklist: The Real State of Each Risk in My Pipeline

❌ = critical finding | ⚠️ = partial mitigation | 🔵 = outside application control

FAQ

Does the OWASP LLM Top 10 apply to agents built on Claude or GPT-4 via API?

Yes, with nuance. LLM01, LLM02, LLM06, LLM07, LLM08, and LLM10 are application-layer risks — they apply regardless of which model you use. LLM03 (training data) and part of LLM05 are provider risks: if you use an external API, you take them as a trust boundary. The audit starts with the risks you can actually control.

Is Zod enough to mitigate prompt injection?

No. Zod validates the structure of external output before it reaches context — that reduces the surface area, but it doesn't eliminate the risk. A well-formed adversarial payload can pass schema validation. Zod is one layer, not a complete solution. Real mitigation combines schema validation, system prompt constraints, and human review at critical points.

Is Cline safe to use in production as an agent orchestrator?

Cline has access to the filesystem, terminal, and other tools with real effects. That's not inherently unsafe — it's the functionality that makes it useful. The risk (LLM08) is in the design: if the agent can execute destructive commands without human confirmation, the risk is real regardless of how well Cline is configured. My rule: any tool with an irreversible effect requires explicit approval.

How often should you run this audit?

Every time you change the agent's architecture: you add a new tool, change the system prompt, or modify how the agent consumes external outputs. It's not a one-time audit — it's a checklist that runs against every structural change. If you add observability () primarily covers per-agent risk. In multi-agent architectures, LLM01's surface multiplies: each agent can become an injection vector for the others. The framework names the risk, but the mitigation detail for multi-agent pipelines is left to each team.

Which risk should I tackle first if I have limited time?

LLM01 (prompt injection) if your agent consumes external output — it's the most exploitable and the most overlooked. LLM08 (excessive agency) if the agent has access to tools with irreversible effects — it's the one that can do the most damage when something goes wrong. The rest depend on your specific stack, but these two are the absolute floor.

The Difference Between Reading and Auditing

My position is clear: the OWASP LLM Top 10 is not something you read and consider covered. It's something you bring into a review session with the architecture diagram open in front of you, and you ask — for each risk — exactly where in the pipeline that could fail.

What I don't buy is the idea that "following best practices" is enough. Practices are abstract; the pipeline is concrete. In my case, LLM01 and LLM06 were real problems I wouldn't have found without doing the systematic audit exercise. I would have discovered them when someone motivated enough decided to exploit them.

If you already have TypeScript agents with MCP tools or elaborate system prompts, do the exercise: open the OWASP LLM Top 10, open the architecture diagram, and ask risk by risk. The result will be more interesting than the list itself.

Concrete next step: take the checklist from this table, replace the states with your own, and document the findings. An audit that isn't documented doesn't exist.

Original source:

• OWASP LLM AI Security & Governance Checklist:
  Vollständiger Original-Bericht

  Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.

  ↗ Original-Artikel auf dev.to lesen