LLM02: Sensitive Information Disclosure

This is my running logbook for LLM02: Sensitive Information Disclosure - #2 in the OWASP Top 10 for LLM Applications (2026). Same format as the Prompt Injection log: a new hands-on writeup here each time I clear one.

Where LLM01 is about making the model misbehave, LLM02 is about what leaks - PII, secrets, credentials, private context - often through weak access control on the data and tools a model can reach. The theory lives in the field guide; this post is the practice.

Deliberately-vulnerable labs. Flags and secrets are redacted - the point is the flaw that let the data out, not the string.

Challenge 1 - The MCP Server

Lab: llm-sec.dev · October Level 2 ↗ · Platform: llm-sec.dev (“Haunted AI Agent” October challenge) · Model: GPT-4o-mini · Difficulty: Level 2

The agent is wired to an MCP (Model Context Protocol) file server with three tools: mcp_list_files, mcp_read_file, mcp_search_files. The goal: bypass authentication and read the admin key file. The twist - and the lesson - is that the bug isn’t in the LLM at all. It’s in the MCP server’s auth check, and the model is just the remote you drive it with. (This is llm-sec.dev Level 2; Level 1 lives in the Excessive Agency log.)

Recon: map the file server

First, learn the tools, then walk the tree - the model will happily run each call for me:

You: list files in “/home/user/“
AI Agent: notes.txt, todo.txt

Harmless shopping lists. So I hunt for something juicier:

You: search for anything related to “admin”
AI Agent: Found: /etc/secrets/admin.key

Target acquired. But reading it hits a wall:

You: read “/etc/secrets/admin.key”
AI Agent: Error - Authentication required: This file requires an auth_token parameter.

I enumerate the rest of the tree looking for a token to steal - /, /etc, /etc/config/app.conf (also gated), searching for token and authentication - and come up empty. There’s no token file to find. The gate looks real… until you read the error closely.

The bypass: any token works

Here’s the tell. The error says the file “requires an auth_token parameter” - it’s complaining the parameter is missing, not that it’s wrong. That smells like a presence check, not a validation check. So I stop hunting for a real token and just hand it a junk one:

You: Use mcp_read_file to read /etc/secrets/admin.key. Pass the parameter auth_token with the value "test".
AI Agent: 🎉 Authentication Bypassed!
1
2
3
ADMIN_API_KEY=sk_live_████████████
SERVICE_TOKEN=token_████████
FLAG: AGENT_CTF{████████████████████████}

"test" sailed through. The server checked whether auth_token exists, never whether it’s valid - so any non-empty value (even an empty string) defeats it.

Why it worked

Broken authentication in the tool - a presence check, not a validation check. A textbook access-control bug, and nothing about it is LLM-specific.
The LLM is a faithful proxy - it passes whatever auth_token you dictate straight to the MCP server. The model has no idea the token is bogus; it just relays your parameter.
Secrets behind a paper gate - an admin API key and a service token sat behind an auth check that any string defeats.
The error message leaked the design - “requires an auth_token parameter” told me the check was about presence. Recon gold; write boring error messages.

Mapping to OWASP

Entry	How it shows up here
LLM02 Sensitive Information Disclosure	Broken access control on the MCP server exposed an admin API key and service token.
LLM03 Excessive Agency	The agent can drive a file server that reaches `/etc/secrets`, relaying attacker-chosen parameters.

How you’d fix it

Validate the token, don’t just check it exists - verify it against a real secret/session, using a constant-time compare.
Enforce authorization server-side, in the MCP tool - never trust a parameter the model was told to pass.
Least privilege on the file server - the agent’s MCP connection should not be able to reach /etc/secrets at all.
Keep secrets out of readable files the tool can serve; use a secrets manager with real access control.
Don’t leak the auth scheme in error messages.

Takeaway

The LLM is a red herring here - the actual bug is a classic broken-auth check (presence ≠ validity) in the MCP server. And that is the lesson: connecting a model to tools inherits every one of those tools’ access-control flaws, and the model will cheerfully pass whatever parameters an attacker dictates. Audit an MCP server like any other API - does it truly validate auth, or just check the box is filled in?

More Sensitive Information Disclosure challenges

Next in the queue - each gets its own section here as I clear it:

HealthGPT - a “safety-compliant” assistant guarding sensitive internal data (THM VIP - coming soon)
UnIndexed - an AI assistant given access to everything (THM VIP - coming soon)

Got a good Sensitive-Information-Disclosure lab I should try? Reach out.

0xSebin