Context engineering refers to the practice of dynamically assembling an AI agent's context window at inference time, drawing on retrieval systems, memory stores, tool outputs, and messages from other agents. This is a departure from traditional prompt engineering, where a human author writes a fixed prompt in advance and the model responds only to that static text. In a context-engineered system, the actual content the model sees is decided at runtime, often by orchestration logic that has no fixed, reviewable form until the moment of execution.
What Context Engineering Is and How It Differs from Prompt Engineering
Prompt engineering treats the prompt as the unit of control: a person or team designs it, tests it, and can review exactly what the model will see before it runs. Context engineering removes that guarantee. The final context is a composite, built from whatever the retrieval system returns, whatever the memory store has persisted, and whatever the invoked tools happen to output at that moment. Nothing about this process is inherently unsafe, but it does mean that governance controls designed around static prompts, such as manual prompt review, do not transfer cleanly to systems where the content is assembled on the fly.
Why Dynamic Assembly Expands the Trust Boundary
When a prompt is static and authored, the trust boundary is narrow: the author and the model. Dynamic context assembly extends that boundary to every system that can contribute content, including third-party APIs, shared memory stores, and other agents. Any one of those sources can introduce untrusted or manipulated content into the context window without a human ever reviewing it before the model acts on it. This is the core governance shift: risk no longer originates only from how a prompt is written, it originates from how many systems are trusted to feed content into that prompt at runtime.
The Role of Model Context Protocol and Its Security Implications
Model Context Protocol (MCP) and similar standards are increasingly used to connect agents to external tools and data sources in a structured way. These protocols make it easier to wire up new context sources, which is useful for capability but also expands the number of trust domains an agent depends on. Each MCP server an agent connects to should be treated as its own access boundary, since a compromised or misconfigured server can inject malicious content or expose data the agent should not have access to, without necessarily triggering any alert in systems built for static prompt review.
Excessive Agency and Unauthorized Tool Invocation
Agents that can invoke tools based on dynamically assembled context are exposed to a related risk: excessive agency, where the agent takes actions beyond what a given task actually requires. If tool permissions are broad rather than scoped to the specific task at hand, content injected into context (whether from a compromised retrieval source or a manipulated tool output) can influence the agent to invoke tools it should not use, or use permitted tools in unintended ways. Least-privilege scoping of tool access is a direct mitigation for this class of risk.
Multi-Agent Context Sharing and Memory Persistence
In multi-agent systems, one agent's output frequently becomes another agent's input context. This creates a chain where a governance gap in one agent (an injected instruction, a leaked credential, an unvalidated data source) can propagate to every downstream agent that consumes its output. Persistent memory stores compound this risk over time, since content written into memory during one session can resurface as context in a later, unrelated session, long after the original source of that content is no longer visible to whoever is reviewing agent behavior.