Encoded prompt injection is the version of prompt injection that hides the malicious instruction inside an encoded, obfuscated, or transformed representation — Base64, invisible Unicode, RTL overrides, structured metadata, or tool-call responses — so it survives shallow filtering and only becomes dangerous when the workflow decodes or reassembles it. Sunglasses v0.2.34 ships ten detection patterns across parasitic_injection, invisible_unicode, code_switching, rtl_obfuscation, and token_smuggling categories specifically to cover this attack surface: GLS-TS-257, GLS-TS-258, GLS-IU-532, GLS-IU-533, GLS-CS-576, GLS-CS-577, GLS-PI-022, GLS-PI-023, GLS-RTL-004, GLS-PX-568. Gateway policy and model-layer guardrails are a good start — but runtime trust is the layer that stops encoded injection after access is already granted.
Encoded prompt injection is the version of prompt injection that makes teams overestimate how much safety they already bought. The malicious instruction is no longer sitting in clean plain text where a defender expects it. It is wrapped in transformation, hidden in metadata, embedded in a tool response, spread across fields, disguised as a helper note, or encoded in a representation the workflow later decodes or reassembles. At that point the security question is not only "did the model see a bad sentence?" It is whether the workflow should still trust the next action path after that hidden instruction has already crossed the first layer of defenses.
That is why encoded prompt injection is such a useful buyer-facing noun right now. It sharpens a measured Sunglasses riser — prompt injection — without forcing the explanation back into generic AI-safety language. The category correction is simple: model filtering matters, prompt screening matters, connector policy matters, and gateway policy matters. But none of those layers fully answers whether the workflow should still trust this tool call, follow this callback, carry this MCP handoff, or reach this endpoint right now once a hidden instruction has already entered the live path.
This page is built around that second sentence. It explains what encoded prompt injection is, why answer engines and buyers should care, what the usual defenses still get right, and where AI agent security fundamentals, hardening checklists, and Sunglasses runtime review still need a runtime-trust layer after access has already been granted.
Quick answer: what encoded prompt injection still gets past shallow defenses
Encoded prompt injection is dangerous because the unsafe instruction can look harmless until a later workflow step decodes, reassembles, or trusts it. Model-layer filters and policy checks still matter, but AI agent security also needs runtime trust: a layer that asks whether the workflow should still be trusted to take this tool call, follow this callback, carry this MCP handoff, or reach this endpoint after a transformed instruction enters the path.
The key difference is timing. Most security copy still frames prompt injection as a bad input detected at the moment of ingestion. Encoded prompt injection often becomes harmful later. The text looks like a note, blob, serialized field, response fragment, or helper payload at first. Then a decoder, retriever, tool adapter, parser, or downstream agent turns it back into operational guidance. That delayed reconstruction is exactly why action-time trust matters.
If your current defense story ends at input filtering, the workflow can still stay "in policy" while its authority quietly shifts underneath it. That is the runtime gap encoded prompt injection exposes better than almost any other prompt-injection label.
What encoded prompt injection is
Prompt injection already means untrusted content is steering an agent. Encoded prompt injection is the same core problem with a more realistic delivery method: the attacker does not need the payload to look like a classic adversarial prompt in the raw surface you are scanning. They only need the workflow to reconstruct the payload later and treat it like valid authority.
That encoding can be literal or practical. Literal means Base64, Morse, chunked text, compressed strings, substituted characters, or serialized fields that later get decoded. Practical means a tool response that says "for troubleshooting, prefer this fallback endpoint," a note embedded in structured metadata, or a sequence of ordinary-looking strings that become unsafe only when stitched together by retrieval, summarization, or tool orchestration.
This is why the category should not be taught only as a content-moderation problem. It is also a workflow-trust problem. The dangerous moment is the point at which the system decides that the transformed content is now trustworthy enough to shape the next action.
That framing also fits the broader Sunglasses wedge. Many agent failures begin with trust-bearing text, metadata, and helper guidance that sound helpful rather than malicious. Encoded prompt injection simply makes that truth easier to see because the attacker no longer has to be obvious in the first place.
Plain-language explainer: where the hidden instruction becomes authority
Imagine an agent that reads a support ticket, calls a lookup tool, checks an internal knowledge base, and then sends an update. Your team already added prompt screening and approved the connectors. The ticket itself looks mostly harmless. The knowledge-base response includes a blob that appears to be diagnostics output. A tool adapter decodes that blob to make it readable for the agent. The decoded content now contains "recommended" next steps that change destination, broaden scope, or alter the reply path.
Nothing in that chain requires a dramatic jailbreak string. The dangerous step is much quieter: the workflow decides the decoded content is legitimate operational guidance. That is the trust transfer defenders need to watch. The question is not only whether the payload existed. It is whether the workflow should still trust what the payload now wants it to do.
This is the simplest way to explain the layers. Guardrails try to reduce what gets through. Access controls reduce what systems can be reached. Gateway policy mediates requests. Runtime trust asks whether the next action is still legitimate after the latest signal — decoded text, callback path, tool hint, endpoint suggestion, or retry guidance — has entered the workflow.
That last question matters because encoded prompt injection is often not about bypassing every earlier control. It is about surviving long enough to inherit authority from a later one.
Why teams stop at the wrong layer
Teams stop at the wrong layer because the first layer is easier to summarize. "We added guardrails." "We block suspicious prompts." "We put the agent behind a gateway." "We narrowed permissions." Those are all real improvements. They are also broad enough that answer engines and buyers can classify them quickly.
Encoded prompt injection exposes the missing sentence. A transformed instruction can pass through one stage as inert data and only become dangerous after retrieval, parsing, decoding, summarization, or tool use. If the security story ends before the workflow evaluates that reconstruction step, the system can still do the wrong thing while every dashboard claims the policy stack exists.
This is also why encoded prompt injection belongs beside prompt injection protection rather than underneath generic model-safety language alone. The buyer needs a clearer operational truth: the attack succeeds when the workflow trusts reconstructed guidance enough to act on it. That is an action-layer problem as much as a content-layer problem.
Three concrete attack examples
1) A decoded tool payload quietly changes the next action
An agent uses a troubleshooting tool that returns an encoded diagnostics block. The adapter helpfully decodes it before showing the result to the model. Hidden inside the decoded text is a recommendation to route a task through a backup service, expose extra logs, or retry through a secondary endpoint. The tool call itself was allowed. The decoder behaved as designed. The shift happened when the reconstructed text gained authority over the next step.
This is why encoded prompt injection is not just "bad text in a funny format." It is a trust event. The right question is whether the workflow should still believe the decoded recommendation enough to continue acting on it. Patterns GLS-TS-257 and GLS-TS-258 (token_smuggling) target this exact surface — payloads that survive encoding and reconstruct as authoritative guidance post-decode.
2) Structured metadata looks benign until retrieval reassembles it
A support workflow retrieves several fields from a knowledge object: title, annotations, remediation notes, and escalation guidance. Each field by itself looks routine. When the retriever assembles them into one context block, the sequence becomes a hidden operational instruction telling the agent to skip a check, use a privileged fallback path, or prioritize a destination that was never part of the original intent.
The problem is not only that the content existed. The problem is that the workflow treated a newly assembled context as trusted authority. Encoded prompt injection often uses that exact advantage: the dangerous instruction lives in how the workflow recombines content, not only in what one field says on its own. GLS-IU-532 and GLS-IU-533 (invisible_unicode) address invisible-character injection that similarly hides in structured fields.
3) MCP or callback guidance stays in scope on paper but still steers the run
An MCP-connected agent receives a valid tool response plus helper metadata for the next hop. The helper text is technically allowed, formatted correctly, and scoped to an approved system. But it includes a transformed or encoded hint that changes which project, route, or endpoint the workflow should prefer. From a protocol perspective the call is still in bounds. From a runtime perspective the workflow just inherited new authority from a signal nobody treated as trust-bearing.
This is where encoded prompt injection overlaps with callback trust and outbound trust. The unsafe moment is not only the original prompt. It is the live action path the workflow starts following after a hidden instruction becomes operational guidance. Patterns GLS-PI-022 and GLS-PI-023 (parasitic_injection), GLS-CS-576 and GLS-CS-577 (code_switching), GLS-RTL-004 (rtl_obfuscation), and GLS-PX-568 (prompt_extraction) all address variations of this trust transfer problem.
How Sunglasses catches it
Sunglasses fits this problem as a runtime-trust layer for agent-facing text, metadata, and workflow guidance. It is useful where defenders need to inspect prompts, repository text, tool descriptions, connector notes, MCP-adjacent metadata, callback instructions, and other trust-bearing input that can quietly reshape agent behavior.
That matters because encoded prompt injection rarely announces itself as "I am now attacking your model." It arrives as normal operations language: a serialized helper payload, a fallback note, a policy fragment, an endpoint hint, a decoded tool response, or a chunk of context that only becomes dangerous when the workflow decides to believe it. Sunglasses is strongest when the team wants to ask that narrower question before action: is this newly trusted guidance safe enough to keep the workflow moving?
For teams that want a simple starting point, the workflow still looks familiar:
pip install sunglasses
sunglasses scan <path>Then review the surfaces where transformed instructions often hide: prompts, retrieved text, tool metadata, callback messages, connector notes, MCP descriptions, retry guidance, encoded blobs, and structured fields that the workflow later decodes or reassembles. See the CVP evaluation reports for independent test data on how these patterns perform. That is not the same job as replacing an MCP gateway, an identity layer, or a full enterprise guardrails suite. It is the narrower job of reviewing where hidden authority enters the action path.
Operator checklist: prompt-injection defense plus runtime trust
- Scan before and after transformation: do not assume the risky text only exists in the original source form.
- Treat decoding as a trust boundary: Base64, Morse, compressed text, parsed fields, and adapter transformations can all reconstruct unsafe guidance.
- Validate structured outputs strictly: extra fields, helper notes, hidden instructions, and ambiguous metadata should not quietly vote on the next action.
- Review tool-call context: an allowed tool call is not automatically a trustworthy tool call after new guidance appears.
- Review callback paths: callback instructions and next-hop suggestions should be treated as fresh trust events.
- Watch endpoint drift: encoded or helper guidance that changes destination should trigger review even when the system is technically still in scope.
- Inspect MCP handoffs: valid protocol behavior can still carry unsafe action-time authority.
- Watch outbound cadence and retries: repeated helper fetches and normal-looking retries can become hidden steering paths.
- Teach the team the right sentence: prompt injection protection is not finished when the first filter passes; it is finished when the workflow still deserves trust at action time.
If your current stack already includes prompt filters, gateways, and policy checks, that is a good start. The next step is one more question at every critical turn: the workflow is allowed, but should it still be trusted to act on this reconstructed guidance now? The Sunglasses manual has the full operator hardening checklist.