Prompt engineering is the practice of designing input prompts to steer a large language model toward a desired output. Because the prompt is the only text-based mechanism for controlling what an LLM generates, prompt engineering is the primary way to influence model behaviour, reduce misinformation, and shape the relevance and accuracy of responses. This article covers the core principles and best practices, and maps prompt engineering vulnerabilities to the OWASP Top 10 for LLM Applications and Google’s Secure AI Framework (SAIF).

What prompt engineering controls

Large language models generate text based on an initial input. They can answer questions, produce structured content, translate between languages, summarise documents, and reason through multi-step problems. The quality and specificity of the input prompt directly influence how useful the output is.

A well-engineered prompt typically includes clear instructions, contextual details, and constraints that guide the model’s behaviour so that the output aligns with what the user needs. The prompt Write a short paragraph about Kosokoking.com will produce a fundamentally different response than Write a short poem about Kosokoking.com even though the subject is identical. The instruction verb and the output format are both part of prompt engineering.

Since the prompt is the LLM’s only text-based input, prompt engineering is the only text-based mechanism for steering the generated output. There is no configuration file, no flag, and no API parameter that replaces a well-written prompt. API parameters like temperature and top-p influence randomness and token selection, but they do not control the substance or direction of the response. That is the prompt’s job.

How prompt phrasing affects output

Prompt engineering is not limited to the instruction itself. It encompasses phrasing, clarity, level of detail, tone, and the structural relationship between different parts of the prompt. Subtle changes to any of these dimensions can produce substantially different responses from the same model.

This sensitivity matters because LLMs are not deterministic. Even with identical prompts, the model may produce different responses on each run due to the sampling process used during text generation. Setting the temperature parameter to zero reduces this variability by always selecting the highest-probability token at each step, but most production deployments use a non-zero temperature to produce more natural-sounding output. The practical consequence is that prompt engineering requires iterative testing rather than a write-once approach.

Best practices

Clarity and specificity

The most common prompt engineering failure is vagueness. A prompt that is ambiguous or underspecified gives the model too much room to interpret, which usually results in a generic or off-target response. The fix is to be as specific as possible about what is being asked, what format the response should take, and what level of detail is expected.

For example, How do I get all table names in SQL is vague because SQL is a language family and the query syntax differs between database engines. How do I get all table names in a MySQL database removes the ambiguity and produces a more useful response. The more precisely the prompt describes the problem, the less the model has to guess.

Context and constraints

Providing context narrows the model’s response space and improves relevance. If the desired output has a specific format, structure, or scope, stating those constraints explicitly in the prompt produces significantly better results than relying on the model to infer them.

Consider the difference between Provide a list of OWASP Top 10 web vulnerabilities and Provide a CSV-formatted list of OWASP Top 10 web vulnerabilities, including the columns 'position', 'name', 'description'. The second prompt specifies the output format, the column structure, and the scope. The model has far less room for interpretation, and the output is immediately usable without reformatting.

Providing examples (few-shot prompting) is another form of context that improves consistency. Showing the model one or two examples of the desired output format before asking it to generate new output dramatically reduces format variability, particularly for structured or domain-specific tasks.

Experimentation

Because LLMs are sensitive to prompt phrasing and non-deterministic by nature, effective prompt engineering requires experimentation. Small changes to wording, structure, or the order of instructions can produce noticeably different results.

The practical approach is to iterate. Try a prompt, evaluate the response quality, make a targeted adjustment, and compare. When a prompt consistently produces good results across multiple runs, that is the prompt to keep. Documenting which variations worked and which did not builds an internal reference that speeds up future prompt development.

Prompt engineering in OWASP and SAIF

Before moving into concrete attack techniques in later articles, it is worth mapping where prompt engineering vulnerabilities sit within established security frameworks. Two are directly relevant.

OWASP LLM Top 10

The OWASP Top 10 for LLM Applications (2025) includes two risk categories that relate directly to prompt engineering.

LLM01:2025 Prompt Injection covers vulnerabilities that arise from manipulating an LLM’s input prompt. This includes forcing the model to behave in unintended ways, bypassing safety controls, executing unauthorised actions, or leaking data that should not be accessible through the prompt interface. Prompt injection is the LLM-specific equivalent of injection attacks in traditional web applications, where the boundary between instruction and data is exploited.

LLM02:2025 Sensitive Information Disclosure covers any vulnerability that results in the leakage of sensitive information through the model’s output. This can include personally identifiable information (PII), financial data, security credentials, confidential business data, or content from the model’s training data. In the context of prompt engineering, information disclosure often results from prompts that are insufficiently constrained, allowing the model to surface data that should have been filtered or excluded.

Both categories are the focus of the prompt injection and information disclosure techniques explored in subsequent articles in this series.

Google SAIF

Google’s Secure AI Framework (SAIF) provides broader guidance on building AI systems that are resilient to threats. SAIF identifies Prompt Injection and Sensitive Data Disclosure as distinct risk categories within its risk taxonomy.

SAIF’s treatment of prompt injection draws a comparison to SQL injection in traditional web applications, noting that attackers can embed instructions as part of data to cause the model to leak sensitive information or behave in unintended ways. SAIF’s treatment of sensitive data disclosure distinguishes between two leakage paths. The first is leakage of data provided to the model during use, including user input, system prompts, and data from integrated systems. The second is leakage of data used for training and fine-tuning.

For agentic systems, where models are granted access to email, files, or external tools, SAIF notes that the risk of sensitive data disclosure is significantly amplified because the agent can access and exfiltrate data through the tools it has been granted.

Summary

Prompt engineering is the primary mechanism for controlling LLM output, and the quality of the prompt directly determines the quality of the response. Best practices around clarity, context, constraints, and iterative experimentation apply to any LLM interaction. From a security perspective, prompt engineering vulnerabilities map to LLM01 (Prompt Injection) and LLM02 (Sensitive Information Disclosure) in the OWASP LLM Top 10, and to the Prompt Injection and Sensitive Data Disclosure risks in Google SAIF.