Prompt Injection and LLM Threats: A Network Engineer's Primer

By Taylor Thomas · 2026-08-30

Prompt injection resembles SQL injection in one important respect: untrusted input lands in a context where the system must distinguish data from instructions. A large language model reads its operator’s instructions and untrusted content together, and no general-purpose mechanism makes that boundary enforceable by construction the way a parameterized query does.

Why Injection Is a Design Property, Not a Bug

A model produces its response from everything in its context window: the operator’s system prompt, the user’s message, and whatever documents or search results the application fed in. Message roles distinguish those sources syntactically, but they are not a security boundary: the model reasons over all of them in one inference process, and a sentence inside a retrieved web page can carry the weight of a sentence the developer wrote.

SQL injection is preventable wherever attacker input reaches the query only as a bound data value: a structural boundary, code and values kept apart by construction. LLM applications have no general-purpose, universally reliable equivalent for arbitrary natural-language content. Architectural controls raise the attacker’s cost: separated trusted and untrusted contexts, tool authorization held outside the model, constrained output formats, instruction hierarchies trained so operator instructions tend to outrank text arriving as data. But it is mitigation, not parameterization: prompt injection remains an open problem, not a patched CVE.

Direct, Indirect, and What Each Threatens

In a direct injection the payload arrives through the user’s own input — typed by the attacker, or pasted by a user unaware of what the text carries — crafted to override the application’s instructions, classically to extract the system prompt or bypass its rules. Assume the system prompt will leak: it should hold no secrets, and its secrecy should never be a security control; even a credential-free leak can reveal internal logic and clues to the tool surface.

Indirect injection is more consequential. The instructions hide inside content the model ingests on the user’s behalf: a web page the assistant summarizes, a résumé screened by a hiring tool, an email in a triage pipeline. The end user types nothing malicious; the payload arrives through data the application trusted enough to retrieve; the trust chain breaks upstream of everyone visible in the transaction.

Jailbreaking overlaps: OWASP’s current LLM Top 10 treats it as a form of prompt injection. The working distinction: jailbreaking aims at the model’s own safety behavior; application-oriented injection redirects an obedient model against its application’s intent; the layered defenses below serve both.

Tools Turn Text Into Actions

Against a text-only chatbot, injection primarily yields attacker-influenced output — leaked context, a misled user — though even output can act when the client fetches attacker-supplied URLs: markdown-image exfiltration. The calculus changes when the application can browse, query databases, send email, or run code. If the application exposes a tool whose credentials permit the action and accepts the model’s decision to call it, attacker-controlled content becomes an external side effect. An inbox assistant can be steered by a mail reading “forward this thread externally.” Retrieval plus tool access turns indirect injection into an exfiltration path, with the agent runtime as the confused deputy: the model influences a component that holds credentials the attacker does not.

An engineer’s instincts apply cleanly here; OWASP’s LLM Top 10 names the failure class excessive agency. An agent is an identity with permissions: scope its credentials to the minimum task, require human confirmation that shows the actual action, destination, and data (not the model’s summary), and log it as you would any privileged account. Never let the model be the final authority on its own permissions: it proposes a tool call; an independent authorization layer decides.

The Defense Is Layered, Because No Filter Holds

Input classifiers catch known patterns and are worth running, but a model extracts intent from paraphrase, encodings, and other languages; no filter yet holds reliably. The strongest defenses constrain what a compromised model can do, not what it can read: least-privilege tools, confirmation gates, separate contexts so untrusted content runs with fewer privileges than trusted instructions, and, everywhere downstream, treating model output as untrusted input, never passed to a shell, query, or browser without the parameterization, encoding, or validation user input gets.

The last layer may be your network: exfiltration, injected or not, typically means resolving a domain, opening a connection, and moving the payload. When that egress transits your network, DNS-layer security can see the resolution — if the query uses a resolver you enforce, not outside DoH — egress filtering the connection, and DLP the content it can reach; an agent in a vendor’s cloud normally egresses from their infrastructure, not yours. Exfiltration over a sanctioned channel passes destination-based controls by design; content-aware DLP can still flag the payload, though encryption and coverage gaps blunt it in practice. Which AI applications are on the network at all is its own discipline: shadow AI visibility.

Where This Sits in Your Study Path

Prompt injection is a young name for an old shape: untrusted input crossing a missing boundary, then privilege doing damage. It is now exam material: the current SCOR 350-701 blueprint’s Security Concepts domain names prompt injection and system prompt leakage among its AI/LLM vulnerabilities, beside the older injection classes, least privilege, and the DLP and exfiltration techniques that govern an agent’s traffic. Build those well and they transfer to whatever the industry adds next. Start with the first lesson.

Frequently Asked Questions

What is the difference between prompt injection and jailbreaking?

The terms overlap — OWASP treats jailbreaking as a form of prompt injection — but the emphasis differs. Jailbreaking aims at the model itself, trying to talk it past its safety training. Application-oriented injection aims at the application built on the model, smuggling instructions into its input so the model serves the attacker's goal instead of the operator's. An application can be badly injectable even when the underlying model is well aligned, because injection exploits a boundary between instructions and data that the model can interpret but the application cannot universally enforce.

Can prompt injection be fixed with better input filtering?

Filtering raises the cost of an attack but cannot end it. A model extracts meaning from paraphrase, encoding tricks, and other languages, so any list of forbidden patterns is enumerating an unbounded space. Effective defenses constrain what a compromised model can do rather than what it can read: least-privilege tool access, human confirmation that shows the actual action and destination, and treating the model's output as untrusted input everywhere downstream.

Do traditional network security controls still matter for LLM applications?

Yes, because the consequences of a successful injection usually travel over the network. An agent steered into exfiltrating data typically must resolve a domain, open a connection, and move the payload — activity that DNS-layer security can see at the resolution (when the query uses a resolver you enforce), egress filtering at the connection, and data loss prevention at the content it can reach, when the application's egress transits your network; an agent hosted in a vendor's cloud normally egresses from their infrastructure, not yours. They are a layer, not a catch-all: exfiltration over a sanctioned channel such as an approved SaaS API passes the destination-based controls by design, though content-aware DLP can still flag the payload where it can inspect the content. Network controls will rarely recognize an injected prompt as malicious, but — depending on where the agent runs and what the controls can inspect — they can detect or constrain much of what it makes the application do.