How prompt injection works
Prompt injection is the embedding of adversarial instructions in content an AI model processes, with the goal of overriding the operator’s intent. A language model does not cleanly separate instructions from data: everything in its context — the system prompt, the user’s request, a fetched web page, an e-mail, a document, the result of a tool call — is text it may treat as something to follow. An attacker exploits that by planting instructions where the model will read them.
Two forms are distinguished. Direct prompt injection comes from the user interacting with the model, crafting input that overrides the rules it was given. Indirect prompt injection is the more dangerous variant for enterprises: the instructions hide inside content the model retrieves in the course of its work — a web page it summarizes, an e-mail it triages, a document it analyzes, a tool result it consumes. The operator never sees the malicious text; the model encounters it mid-task, and may follow it.
Why it matters
For a chatbot that only answers questions, a successful injection produces a bad answer — embarrassing, but bounded. The risk changes category when the AI has tools and credentials. An agent that reads e-mail, queries databases and calls APIs is an agent whose behavior can be redirected by anything it reads: a successful injection can make it exfiltrate the data it has access to, or trigger actions its credentials permit, all while every system involved sees perfectly legitimate, authenticated calls.
What makes the problem structural is that no model-level filter is complete. Detection heuristics and safety training raise the bar, but the instruction–data ambiguity is inherent to how language models work, and new bypasses keep appearing. Security teams therefore treat prompt injection the way they treat phishing: not as something to eliminate, but as something that will sometimes land — which shifts the design question from prevention to blast radius.
Defending in depth
The working assumption is defense-in-depth: treat model output as untrusted input, and build the controls that hold even when the model is fooled. Give agents least-privilege tool scopes, so a redirected agent can only misuse what it legitimately holds. Allow-list which tools exist for it at all — a tool an agent cannot discover is a tool an injection cannot invoke. Require human approval for destructive calls, so the most damaging actions pause for a person regardless of why the agent proposed them. Monitor and audit every call to catch anomalous behavior, and keep a kill-switch that halts a misbehaving agent immediately.
The common property of these controls is that they live in the identity layer, outside the model. They do not depend on recognizing the injection, on the model resisting it, or on any assumption about model internals: authorization is enforced at the point of action, so the guardrails hold regardless of whether the model was fooled. An identity-aware MCP gateway like Monosign’s limits what a compromised agent can actually do.