Prompt injection is not solved
Why prompt injection is a trust-boundary problem, and what runtime inspection can honestly do about it.
The structural problem
Language models process instructions and data in the same medium: tokens. Role labels and system prompts influence behaviour, but they do not create the kind of hard isolation boundary engineers expect from an operating system, database permission, or transaction policy.
That is why prompt injection is wider than a malicious message typed into a chat box. Instructions can arrive through retrieved documents, tool output, email, uploaded files, OCR, or earlier conversation turns. The source changes; the trust problem does not.
- Direct injection enters through customer input.
- Indirect injection arrives inside content the application retrieves or parses.
- Tool-call manipulation targets arguments or authorization context before execution.
- Obfuscation uses encoding, Unicode, spacing, or framing to evade simple matching.
What runtime detection can do
A runtime control can inspect content before it crosses a trust boundary, preserve evidence, and return a decision that the application can enforce. It can make common attack patterns expensive and visible. It cannot convert probabilistic language understanding into a mathematical guarantee.
Koreshield first normalises text so that Unicode compatibility characters, HTML entities, URL encoding, invisible characters, selected homoglyphs, and several encoded forms can be evaluated consistently. Detection then combines named indicators and boundary-specific analysis. The response includes confidence and evidence rather than hiding the decision behind a single opaque label.
Three boundaries, three contracts
Customer input, retrieved context, and proposed actions carry different data and require different fallbacks. The rebuilt API therefore exposes separate scan contracts instead of pretending that one transparent proxy understands every application.
- POST /v1/scan inspects customer-controlled text and optional application context.
- POST /v1/rag/scan inspects selected documents, their metadata, and the originating query.
- POST /v1/tools/scan evaluates a proposed tool name, arguments, and authorization context before execution.
Detect before enforce
A detector that blocks legitimate support traffic creates its own operational failure. Koreshield workspaces therefore support detect and enforce modes. Detect mode records what would have been blocked without stopping the workflow, giving a team a real calibration period against its own traffic.
The responsible rollout is layered: constrain data access, preserve provenance, scan at trust transitions, apply ordinary authorization after the model proposes an action, and monitor the evidence. Prompt engineering remains useful, but it should never be the only control protecting a consequential workflow.