AAgentic.NET
.NETAI AgentsSecurityGuardrails

Content Moderation and Guardrails for .NET AI Apps

User input and AI output both need checking. How to add content moderation and guardrails to a .NET AI app — filtering unsafe input, output, and enforcing scope.

MB
Manikandhan Balakrishnan
·3 min read

The moment your AI app faces real users, two things become non-negotiable: you can’t let users send abusive or malicious input into the model unchecked, and you can’t let the model emit unsafe or off-brand content back. That’s guardrails — the safety layer around your AI. This article covers building them in .NET.

The three places guardrails live

Think of guardrails at three checkpoints:

  1. Input — before the user’s text reaches the model.
  2. Output — before the model’s response reaches the user.
  3. Scope — keeping the model on-topic and refusing what it shouldn’t do.

You want all three; skipping any leaves a gap.

Input moderation

Before calling your model, screen the input for abuse, harmful requests, or prompt injection attempts. A content-safety service (Azure AI Content Safety, OpenAI’s moderation endpoint, or similar) gives you category scores you can threshold:

var result = await moderator.AnalyzeAsync(userInput);
if (result.Categories.Any(c => c.Severity >= threshold))
{
    return "Sorry, I can't help with that request.";
}
// safe — proceed to the model

This also protects your bill: you don’t spend tokens processing input you’re going to reject anyway.

Output moderation

The model can produce problematic content even from benign input. Screen the response before it’s shown:

var reply = await agent.RunAsync(userInput);
var check = await moderator.AnalyzeAsync(reply.ToString());
if (check.IsUnsafe)
{
    return "I'm not able to provide a response to that.";
}
return reply;

For streaming responses, this is trickier — you may moderate in chunks or buffer to a checkpoint. Decide based on how strict your requirements are.

Scope guardrails

Keep the model doing its job and nothing else. Two layers:

  • Instruction-level — a firm system prompt: “You only answer questions about Contoso products. Politely decline anything else.” (See prompt engineering.)
  • Code-level — because prompts aren’t a hard boundary, enforce the real limits in code: validate tool arguments, require confirmation for high-impact actions, and never let the model’s output bypass your authorization checks.

Don’t rely on the prompt alone

The critical principle: a system prompt is a strong default, not a security control. A determined user can often talk a model past its instructions. So your guardrails must include code-enforced checks — input/output moderation and tool validation — not just careful wording. This is the same message as securing AI agents: enforce in code where you’re in control.

Log what you block

Record blocked inputs and outputs (minus sensitive data). It gives you an audit trail, shows you what users actually try, and lets you tune thresholds — too strict and you frustrate real users, too loose and things slip through. Pair it with observability so a spike in blocks is visible.

Note: specific moderation services and their APIs vary by provider and change over time; verify against your chosen service’s docs. The architecture — moderate input, moderate output, enforce scope in code, and log — is stable and provider-independent.

Takeaway

Guardrails for a .NET AI app live at three checkpoints: screen user input before the model, screen the model’s output before the user, and keep the model in scope with both a firm system prompt and code-enforced limits. Use a content-safety service for the moderation, validate tool arguments in code, log what you block, and never treat the prompt as your only defense. That’s the difference between a demo and something you can safely put in front of real users.

Have a correction or a topic you want covered? Email mani.bc72@gmail.com.

Related articles