Notifications
Clear all
Topic starter
05/07/2026 6:46 pm
TL;DR: In-context learning lets pretrained LLMs perform new tasks from examples in the prompt without parameter updates, which is why prompt engineering can change behaviour at inference time, according to Lakera. The governance issue is that access control around AI systems must account for what they can do inside a session, not just what they were allowed to see before it began.
NHIMG editorial — based on content published by Lakera: What is In-context Learning, and how does it work: The Beginner’s Guide
Questions worth separating out
Q: How should security teams govern prompts in production AI systems?
A: Treat prompts, examples, and retrieval context as governed production inputs.
Q: Why do AI models create governance risk even without retraining?
A: Because behaviour can change at inference time when the model sees new context, examples, or instructions.
Q: What do security teams get wrong about prompt engineering?
A: They often treat prompt engineering as a purely quality or UX activity.
Practitioner guidance
- Classify prompts as governed inputs Review prompt templates, examples, and retrieved context the way you review other production control inputs.
- Test for behaviour drift under prompt variation Run structured evaluations that change example order, wording, and context length to see where the model’s output changes materially.
- Separate sensitive data from prompt context Keep confidential data out of prompt text wherever possible and rely on controlled retrieval, redaction, and data minimisation instead.
What's in the full article
Lakera's full article covers the conceptual mechanics this post intentionally leaves at a higher level:
- A step-by-step explanation of Bayesian inference and how latent concepts are inferred from prompt examples.
- A deeper walkthrough of few-shot, one-shot, and zero-shot in-context learning patterns.
- Discussion of prompt engineering as a practical technique for shaping model output quality.
- Additional examples of real-world LLM applications and research directions that influence implementation choices.
👉 Read Lakera's guide to in-context learning in large language models →
In-context learning and AI control gaps: what IAM teams miss?
Explore further
05/07/2026 7:03 pm
In-context learning creates a runtime policy problem, not just a model behaviour problem. The article shows that prompts can alter outputs without retraining, which means the security boundary moves from model weights to session context. That is especially relevant for AI systems that touch identity, data, or enterprise workflows, because what they are shown can materially change what they do. Practitioners should treat prompt context as governed input, not incidental text.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
A question worth separating out:
Q: How do you know if an AI workflow is too dependent on context?
A: Look for workflows where small prompt changes create large output shifts, especially when sensitive data, code, or operational instructions are included. If the model’s behaviour is fragile, the workflow is overexposed to context risk. That is a sign the system needs tighter data minimisation, prompt testing, and stronger execution boundaries.
👉 Read our full editorial: In-context learning shows why prompt control is not enough
