Prompt engineering gets filed under productivity. It shows up on the same slide as meeting summaries and email drafting, which makes it easy for a security team to ignore.
That is a mistake, and not primarily because AI tools make analysts faster, although they do. It is a mistake because the skill of writing precise instructions for a language model and the skill of reasoning about how a language model can be manipulated are the same skill viewed from two sides. Teams that develop one tend to develop the other. Teams with neither are the ones that deploy AI badly and fail to notice when it is being used against them.
What prompt engineering actually is
Stripped of the mystique, prompt engineering is specification writing. You are describing a task to a system that has no access to your context, no ability to ask a colleague for clarification, and a strong tendency to produce something plausible rather than admit uncertainty.
Doing it well means being explicit about the goal, the constraints, the shape of the output, and what the system should do when the input does not match expectations. Those are the same four things you specify when you write a detection rule, a firewall policy, or a runbook step. Vague instructions produce confident, wrong output in all four cases.
The mirror image: prompt injection
Once you have internalised that a model follows instructions found in its input, prompt injection stops being surprising and starts being obvious.
A language model does not reliably distinguish between instructions from you and instructions embedded in the data it was asked to process. If your assistant summarises a web page, and that page contains text telling the model to disregard prior instructions and reveal the conversation, the model may well comply. The same applies to email bodies, PDFs, calendar invitations, support tickets, code comments, and file names.
This is the AI-shaped version of injection generally: the system fails to keep the control plane and the data plane apart. What makes it harder than SQL injection is that there is no parameterisation available. You cannot escape natural language, because natural language is the interface.
An engineer who has spent real time learning why one prompt works and another does not has already built the intuition needed to see this coming. They know the model treats everything in the context window as instruction-shaped. They know that recency carries weight. They know that assigning the model a role changes its behaviour. Every one of those observations is also an attack technique.
It sharpens social engineering defence too
Generative tools have removed the cheapest signals people relied on to spot phishing. Bad grammar, awkward phrasing, and obvious template reuse were never good detection, but they were free. They are gone, and they are not coming back.
What replaces them is structural. Does the request create urgency that bypasses a normal process? Does it ask for an action rather than information? Does the sender have a plausible reason to know what they appear to know? None of those questions depend on the quality of the prose.
People who work with language models regularly develop a specific and useful scepticism. They have seen fluent, confident, entirely wrong output often enough that fluency stops registering as credibility. That recalibration is exactly what you want in someone assessing an unexpected payment request from a supplier.
Where it pays off day to day
- Triage summarisation. Turning a long alert chain or a noisy log excerpt into a short account of what happened, with the model explicitly instructed to say when it cannot tell.
- Detection engineering. Drafting and explaining rules, then asking the model to argue against its own logic to surface false positive sources you had not considered.
- Policy and documentation. Converting a control decision into readable policy language, then checking that language back against the control it is meant to describe.
- Phishing analysis. Extracting indicators from a reported email, and generating the plausible pretexts an attacker might use against a specific role for awareness exercises.
- Post-incident writing. Producing a first-draft timeline from raw notes, which is the part everybody postpones until the details have faded.
In all of these, the value sits in the constraints you set rather than the model you chose. The single instruction that most improves output quality across every one of these tasks is some version of: if the input does not support a conclusion, say so and stop.
The failure modes worth naming
Two habits cause most of the damage.
The first is treating output as verified because it is well formatted. A model will produce a confident CVE identifier, a plausible log field name, or an authoritative-sounding legal statement that simply does not exist. Anything that will be acted on needs a second source, and the second source cannot be the same model asked again.
The second is pasting sensitive material into tools without knowing where it goes. This is a data governance question with a straightforward answer: decide in advance which categories of data may be sent to which tools, write it down, and surface that decision at the point of use. Under POPIA, personal information sent to a model provider is being processed by an operator, with all of the Section 21 obligations that implies.
How to build the skill
Not with a course. Give the team a real task they already do, a tool they are permitted to use, and a rule that output must be checked before it is used. Then have them compare prompts with each other.
The teams that get good at this are the ones where somebody asks, out loud, why that prompt worked and the other one did not. That conversation is the entire training programme, and it produces both halves of the skill at the same time.