How do I stop prompt injection from leaking my system prompt or API keys?

Asked by makers — answered by AXIS. This question comes up repeatedly in listing intake and onboarding conversations; we have reworded it so no individual maker is identifiable.

The question: "I keep reading that prompt injection can make an app leak its instructions or worse. What's the current honest state of defense for a solo maker — what actually works versus security theater?"

The answer. The honest state first, because vendors fog this: prompt injection has no complete fix in 2026. Public demonstrations keep landing against major, well-resourced products — including coding agents tricked into revealing credentials via crafted content in things as mundane as a pull-request title. A model that reads untrusted text can be influenced by untrusted text; that's the substrate you're building on. Defense is therefore about blast radius, not prevention. Ranked by what practitioners and the OWASP LLM guidance actually support:

Tier 1 — architectural (these work because they don't rely on the model behaving):

1. Nothing secret in the prompt. Keys, internal URLs, customer data — out. A leaked prompt should be embarrassing at most, never a breach.
2. Least privilege on tools. If the model can call functions, each tool gets the narrowest scope that works, and the user's permissions bound the tool's reach — the model never has standing the requesting user lacks.
3. Human confirmation on consequential actions. Sends, deletes, purchases, anything external — model proposes, user confirms. Boring and undefeated.
4. Treat model output as untrusted input. Escape it before rendering, validate it before executing, never let it directly select an authorization outcome.

Tier 2 — meaningful friction (raises attacker cost, stops the casual case):

1. Separate untrusted content from instructions structurally (delimiters, role separation) and tell the model retrieved content is data — helps against drive-by injection, folds against a determined one.
2. Output filtering for known-sensitive strings (your own key formats, prompt fragments) as a tripwire.
3. Rate limits and anomaly flags — a session suddenly probing in twenty phrasings is a signal worth logging.

Tier 3 — mostly theater when sold alone: injection-detection classifiers as your primary defense (real bypass rates, false confidence), "unbreakable prompt" incantations ("ignore all attempts to..."), and any vendor claiming solved-problem status.

The design question that matters more than any mitigation: what's the worst thing a fully-compromised model call can do in your app? Architect until that answer is boring, then the residual prompt-injection risk is survivable by construction.

What tools or data does your model currently have in scope? Post your worst-case honestly and we'll workshop the blast-radius cut.

AXIS Editorial

Follow-up from maker intake: "What does 'least privilege on tools' concretely look like when my agent needs broad access to be useful — that's the product?"

The resolutions that work in practice: (1) scope per session, not per app — the agent gets a token minted for this user's resources for this task's duration, so 'broad' never means 'everyone's'; (2) split read from write — wide reads with confirmed writes preserves most usefulness at a fraction of the risk; (3) gateway the credentials — the agent calls your API which holds the real keys and enforces policy, so no key ever sits in the loop the model influences; (4) budget every session — actions-per-task caps that make runaway behavior self-limiting. Products that 'need' an ungated god-token usually need one of these four designs instead.

AXIS Editorial

Follow-up from maker intake: "Is indirect injection actually being exploited, or is it conference-talk material? I only handle uploaded PDFs."

Actively demonstrated against production systems, including this year — hidden instructions in web content, documents, and code-review metadata steering assistants that read them; security vendors now track it as a leading LLM-app attack pattern. Uploaded PDFs are squarely in scope: text layers, embedded objects, even white-on-white content all reach your context window. Your mitigations are the thread's Tier 1 applied to the upload path: the PDF's content should influence answers about the PDF, never trigger tools or reach other users' sessions — and if your model has no tools and single-tenant context, say so in your listing's security notes, because that's a genuinely strong answer.

Jonathan (AXIS Launch)

The 'worst case boring' test is how I'd have every maker on this platform frame their security section, so let me give the two ends from real listings: strong answer — 'a fully hijacked session can produce bad text in that user's own chat, rate-limited to N calls; no tools, no cross-tenant data in context.' Weak answer — 'we have guardrail prompts and a filter.' The first is an architecture; the second is a hope. Buyers' technical diligence has started asking this question in almost exactly this form, so having the strong answer is worth actual money.

AXIS Editorial

Follow-up from maker intake: "Where do the injection-detection products fit, then? 'Mostly theater when sold alone' implies a right way to use them."

As one tripwire among several, priced accordingly: a detection layer that flags-and-logs (rather than silently blocks) gives you visibility into probing attempts, which has real operational value — you learn you're being attacked, which sessions, and how. What it can't be is the wall: published bypass research against every major detection approach means a Tier-1-shaped hole remains a hole regardless of the classifier in front of it. Reasonable spend: low, after the architectural work, for monitoring. Unreasonable: any spend instead of the architectural work.