What is the difference between build-time sanitization and run-time protection in AI security?

Why This Matters for Security Teams

Build-time sanitization and run-time protection solve different failure modes, so treating them as interchangeable leaves a gap that attackers can exploit. Build-time controls reduce the chance that poisoned documents, unsafe instructions, or malformed metadata are embedded into retrieval layers. Run-time controls reduce the chance that a live prompt, tool call, or generated response triggers data leakage, policy bypass, or unsafe execution. That distinction matters because AI applications often combine content ingestion, retrieval, and action in one workflow.

Security teams also need to separate content hygiene from decision enforcement. Build-time filtering can improve the quality of what enters a knowledge base or vector store, but it cannot stop a malicious user from crafting a prompt that changes model behaviour at inference time. Run-time protection is where policy checks, prompt validation, output filtering, and tool-allowance decisions happen. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces the need to manage risk across the full lifecycle, not only at deployment.

In practice, many security teams discover the boundary between ingestion controls and inference controls only after a retrieval chain has already exposed untrusted content to a live agent.

How It Works in Practice

Build-time sanitization happens before data is made available to the model or retrieval system. It typically includes source allowlisting, file parsing validation, malware scanning, deduplication, metadata normalisation, and removal of content that is unsafe, irrelevant, or overly privileged. In a RAG pipeline, this stage should also decide whether a document is suitable for indexing at all, because once it is embedded, later detection is harder and less reliable.

Run-time protection operates on live traffic. It checks the user prompt, the retrieved context, the tool request, and the model output against policy. That may include prompt-injection detection, sensitive-data redaction, instruction hierarchy enforcement, output validation, and limits on what an agent can execute. Where tools are involved, run-time controls should also inspect the action itself, not just the text that preceded it. Current guidance suggests this is essential for agentic systems, because a model can be technically accurate while still taking an unsafe action.

• Use build-time sanitization to keep untrusted or low-quality material out of the index.
• Use run-time protection to stop live abuse, policy violations, and unsafe tool execution.
• Log both stages so investigators can trace whether a failure started at ingestion or inference.

Frameworks such as CSA MAESTRO agentic AI threat modeling framework are helpful because they encourage teams to model the full attack path from data source to action. Anthropic’s Project Glasswing is also relevant as an example of the industry’s growing focus on runtime safeguards for agentic workflows. These controls tend to break down when retrieval sources are highly dynamic and tool access is broad, because the system can ingest new risk faster than policy checks are updated.

Common Variations and Edge Cases

Tighter build-time sanitization often increases operational overhead, requiring organisations to balance content quality against ingestion speed and false rejections. That tradeoff becomes sharper in fast-moving environments such as customer support knowledge bases, shared collaboration spaces, and continuously updated threat intelligence feeds.

Best practice is evolving for whether some checks belong strictly at build time or should be repeated at run time. For example, a document may pass ingestion screening yet still become risky once paired with a user-specific query or a privileged tool. Likewise, output filtering can reduce leakage, but it cannot fully compensate for an agent that already received excessive context or permissions.

The most common edge case is a hybrid system where the same content is both stored and streamed. In that design, sanitization must be applied before indexing and again before use, especially when content comes from external sources or user uploads. Another edge case appears when teams rely on the model to decide what is safe. That is not enough on its own, because policy enforcement should sit outside the model whenever possible. The right pattern is layered control, with separate checks for ingestion, retrieval, prompting, output, and action.

Related resources from NHI Mgmt Group

• What is the difference between build-time interoperability and run-time interoperability for AI agents?
• What is the difference between build-time and runtime security for AI agents?
• What is the difference between one-time AI risk assessment and continuous runtime protection for agents?
• What is the difference between AI agent security and standard service account management?