Trust and security · 2026-09-22
Prompt injection in LLM APIs: defending against direct and indirect attacks
Beyond API key and rate-limit security, this covers the architectural safeguards needed against prompt injection attacks delivered through user input and retrieved documents.
API keys and rate limits are not enough
The API key protection and rate limiting covered in the LLM API security article control who sends a request and how often. Prompt injection operates at a different layer: text embedded in the request itself is designed to make the model ignore or override its original instruction. This attack can happen with a valid API key and a normal request rate, so identity and rate control do not block it.
Direct prompt injection is the simple form, where the user themselves tries to override the system instruction. Indirect prompt injection is the riskier one: an instruction hidden inside a web page, email, or document the model processes can change the model's behavior without the user's knowledge.
Input/output separation and scoped tool permissions
If an agent has access to a tool (writing a file, sending an email, initiating a payment), limiting that tool's permission scope to the minimum the task actually needs reduces the possible damage from indirect injection. If a research task only needs read access, not granting write access to that session prevents a malicious instruction from producing an action even in the worst case.
Passing the model's output through a verification step before turning it directly into an action (running code, a payment, sending an email) prevents the model itself from being the only security layer. That verification can be human approval, or a simple rules engine checking whether the output conforms to the expected format.
- Scope a tool's permission to what the task actually needs; don't grant broad access by default.
- Pass a model-produced action through a verification step before executing it directly.
- Treat sources carrying indirect-injection risk (third-party web content, email) at a separate trust level.
Don't expect perfect resistance from the model
No model guarantees rejecting an embedded instruction with one-hundred-percent reliability; this is not a flaw specific to one model version or provider, but a general limit of current architectures. Defense should therefore rely on the surrounding architecture — permission scoping, a verification step, trust separation by input source — rather than on the model alone.
Frequently asked questions
Is prompt injection the same thing as jailbreaking?
No. Jailbreaking aims to bypass a model's own safety restrictions; prompt injection aims to make the model ignore its original task instruction and follow the attacker's instruction instead. The two require different defenses.
Is an app that only takes input from trusted sources still at risk?
Even if the input source looks trusted, if that source's content can be modified by a third party (a web page, a shared document), it carries indirect-injection risk. What matters is not the source itself, but who controls the content the source delivers.