Context engineering is the practice of dynamically assembling the full set of inputs an AI agent reasons over at runtime, rather than relying on a single, hand-crafted prompt. Where prompt engineering focuses on the wording and structure of a static instruction, context engineering addresses the broader problem of what information the model sees at the moment it acts: retrieved documents, persistent memory, tool and API outputs, prior conversation turns, and increasingly, state shared between multiple agents.
Retrieval-augmented generation (RAG) is one component within this broader practice, not a synonym for it. A RAG pipeline supplies retrieved documents into context, but context engineering also covers memory persistence across sessions, the outputs of tool calls the agent makes mid-task, and state passed between agents in multi-agent systems. The distinction matters for governance because each of these input types represents a separate origin, a separate trust level, and a separate opportunity for something to go wrong before the model ever generates a response.
Why This Introduces Governance Blind Spots
The core governance problem is that context is assembled per session, at runtime, often from multiple systems that were never designed to interoperate under a shared security model. Standardization efforts such as Anthropic's Model Context Protocol (MCP) formalize how agents connect to external context sources through a client-server architecture, where servers expose resources, tools, and prompts that get pulled into the model's context window on demand. This is a meaningful step toward interoperability, but it also means an agent's effective instructions can originate from a server the governance team may not have direct visibility into.
MCP's specification includes provisions for user consent and authorization before a client invokes a server's tools or accesses its resources, but the specification explicitly leaves implementation of those controls to the host application. In practice, this means the strength of context source authorization varies significantly by vendor and deployment, and cannot be assumed as a baseline property of MCP-based systems.
The Injection Vector Governance Teams Must Account For
OWASP's Top 10 for LLM Applications ranks prompt injection, including indirect injection, as the top vulnerability category for LLM-based applications. Indirect injection occurs when untrusted content from external sources, such as a retrieved document, a website, or a tool output, is incorporated into the model's context and used to manipulate its behavior. This differs from direct injection in a way that matters operationally: the malicious instruction never passes through the user-facing input, so input-side filtering alone will not catch it.
MITRE ATLAS catalogs adversarial techniques against AI systems that include manipulating model inputs through indirect means, such as poisoned retrieval sources or manipulated tool outputs. Together with OWASP's framing, this establishes indirect injection as a recognized vulnerability class rather than a theoretical concern, even though the research reviewed here did not surface a confirmed, publicly documented enterprise breach tied specifically to context or memory injection in the past 12 months. The risk is substantiated by vulnerability classification, and governance programs should treat it accordingly rather than waiting for a case study.
Data Leakage Through Retrieved and Persistent Context
OWASP separately identifies sensitive information disclosure as a distinct risk category, and it applies directly to context engineering. If a retrieval index or a persistent memory store contains regulated data such as PII, credentials, or confidential records, that content can surface in an agent's output to a user who was never authorized to see it, simply because it was pulled into context to answer a query. This risk compounds with memory persistence: context injected or leaked in one session can carry forward into future sessions and future users if memory scoping and retention are not deliberately controlled.
Context window size limits add a second-order problem. When assembled context exceeds available window space, truncation or summarization logic decides what gets dropped or condensed. That logic is rarely built with governance in mind, and it can silently remove or alter content that a compliance or security review would have flagged.
Why Existing Security Tooling Falls Short
Most AppSec and DLP tooling was built around static prompts, fixed API payloads, or network traffic patterns. Context engineering breaks that model because the actual input to the AI system is assembled dynamically, per session, from sources that may not be visible to network-layer monitoring at all. NIST's AI Risk Management Framework identifies transparency and traceability of AI system inputs as core trustworthiness characteristics that should be maintained throughout the AI lifecycle, and explicitly recommends documenting data provenance and lineage for inputs used in decision-making.
Most current agent architectures cannot meet that bar. They log the user's prompt and the model's final output, but not the full assembled context (retrieved documents, memory entries, and tool results) that actually influenced the decision. Without that record, a governance team investigating an incident has no way to reconstruct what the agent actually saw.
Where Trussed AI Fits
Trussed AI provides runtime governance and security for enterprise AI agents, applying policy enforcement, monitoring, and audit logging at the point context and tool calls actually occur rather than relying solely on pre-deployment review. This includes agent identity and permissions, least-privilege enforcement, tool approval workflows, and MCP security controls that address the authorization gap left open by protocol-level consent provisions. Runtime governance is a complement to context engineering, not a substitute for the architectural work of building sound retrieval and memory systems. It closes the specific gap where context assembled dynamically at runtime falls outside what static, pre-deployment security review can see.