Chapter 07 · Execution Safety

Content Safety & Injection

This is layer 6: screening the text flowing in and out of the model — blocking prompt injection on the way in, and leaked secrets and exfiltration URLs on the way out. Everything the model reads or writes is treated as untrusted, and the screening is done by deterministic code that never relies on the model "choosing" to be safe.

The core problem: one channel for instructions and data

A normal program keeps its code and its data in separate places — the code is what you wrote, the data is what flows through it. An LLM agent collapses that separation. The model's instructions and the data it reads arrive over the same channel: plain text. When the model reads a web page, a tool's output, a retrieved document, or a stored memory, any sentence in there could be a smuggled command — and the model has no built-in way to tell a genuine instruction from a hostile one.

Because of that, the harness treats all model-adjacent text as untrusted and screens it with deterministic controls. It does not trust the model to recognize an attack and decline. Three checkpoints sit around every request:

Checkpoint	When it runs	What it screens
Input content safety	Before the handler (request goes in)	The incoming content, for unsafe material — blocked before it reaches the LLM
Prompt-injection scan	Before the handler (request goes in)	The content, for hostile instructions hidden in what the agent will read
Output sanitization	After the handler (response comes out)	Tool output, for leaked secrets, embedded injection payloads, and exfiltration URLs

All three are MediatR pipeline behaviors — they wrap the request handler so the screening happens automatically, in a fixed order, on every request that opts in. The rest of this page walks each checkpoint, then shows how they combine against a real attack.

Input content safety

The first checkpoint screens incoming content before the handler runs, so unsafe text never reaches the model.

If the screen comes back unsafe, the request is stopped right there: the behavior returns Result.ContentBlocked() (or throws ContentSafetyException), so the request never reaches the LLM. Every outcome — blocked or allowed — is recorded to metrics via ContentSafetyMetrics.Evaluations, so you can see screening rates and block rates in your dashboards.

Prompt-injection scanning

The second input checkpoint looks specifically for hostile instructions hidden in the content the agent is about to read.

The scanner is a deterministic pattern-matcher. It does not call another model to decide whether the text is hostile — it matches against known injection patterns directly. That choice matters for two reasons:

Output / response sanitization

The third checkpoint is the most important one for stopping indirect injection, and it runs after the handler — on the way back out. This is where tool output gets cleaned before it is allowed to flow back into the model's context.

The composite sanitizer lives at src/Content/Infrastructure/Infrastructure.AI.Governance/Adapters/CompositeResponseSanitizer. It chains three sanitizers in a fixed order, each handling a different exfiltration risk:

Order	Sanitizer	What it catches
1	Credential-leak sanitizer	Redacts secrets and API keys that appear in the output
2	Prompt-injection sanitizer	Detects injection payloads embedded in tool output, so a malicious tool result can't hijack the next turn
3	Exfiltration-URL sanitizer	Blocks URLs that look like attempts to exfiltrate data

The composite returns a SanitizationResult — a list of findings plus the highest threat level seen across all three sanitizers. If that highest threat level is greater than or equal to GovernanceConfig.ResponseBlockThreshold, the behavior returns a GovernanceBlocked failure rather than letting the tool output continue. Findings are counted in GovernanceMetrics.ResponseSanitizations (broken down by category and by tool name) and can optionally be written to the governance audit trail.

The full attack scenario

Here is how the three sanitizers fire together against a single poisoned tool result.

The deterministic pipeline order

These checks are not scattered through the codebase — they are MediatR pipeline behaviors, registered in src/Content/Application/Application.AI.Common/DependencyInjection.cs. Registration order is the execution order: the behaviors registered first wrap the ones registered after them, so they run outermost on the way in and (for the post-execution ones) last on the way out.

For the agent request path, the verified order is:

1. AuditTrail — records the request as it enters
2. ContentSafety — input screening (this page)
3. PromptInjection — input injection scan (this page)
4. … the request handler runs …
5. ResponseSanitization — output sanitization on the way back out (this page)

The shape to take away: screening-in happens before the handler, and sanitization-out happens after it. Input safety and the injection scan both run before the model is ever called; the response sanitizer runs on the result the handler produced, on the way back to the caller.

Untrusted text is everywhere — not just here

Content safety is layer 6, but the "treat model-adjacent text as untrusted" habit shows up in other layers too. A few related habits worth knowing:

• System prompts never embed raw user input. User text is kept as data, not spliced into the instructions the model is given — so a user can't rewrite the agent's standing orders just by phrasing a request a certain way.
• Subprocess arguments use ArgumentList. When the harness runs a child process, arguments are passed as a list, not a shell string, so there is no shell to interpret and nothing to inject. See Sandbox & Execution.
• RAG documents and stored memory are untrusted too. Retrieved content and recalled memory can be poisoned just like a tool result, which is why provenance tracking matters. See Data Protection & Privacy.

What you control as an operator