The enforcement loop

One loop, five stages.

Every request crosses four surfaces. Each is scanned, decided and recorded. Select a stage.

Architecture

The full capability map.

Each package exposes focused capabilities. Select a card for the contract and a sample.

CurrentPlannedContext

Quick start

Two lines. Policy in config.

Add the middleware, then let security teams own the YAML. No redeploy to change a rule.

Program.cs

// register
builder.Services.AddSentinelAI(o =>
{
    o.EnablePromptInjectionDetection();
    o.EnablePiiProtection();
    o.EnableToolAuthorization();
    o.EnableOpenTelemetry();
});

// enforce
app.UseSentinelAI();

sentinel.yaml

security:
  promptInjection:
    action: block
    threshold: 0.85
  pii:      { action: redact }
  secrets:  { action: block }
  toolCalls:
    delete_customer:
      action: require_confirmation

Why Sentinel

Not another scanner. The missing layer.

Strong tools already exist for detection, testing and observability. None combine .NET-native enforcement, a gateway and a tool firewall.

Tool	Strength	What Sentinel adds
Promptfoo	Red teaming and CI testing	Production runtime enforcement
LlamaFirewall	Runtime scanners	Runs as a pluggable scanner behind policy
NeMo Guardrails	Input, output and tool rails	.NET-native, no Python service to run
Langfuse · OpenLLMetry	LLM observability	Security decisions on the same traces
YARP · Extensions.AI	Proxy and AI abstractions	Built on top of both

Roadmap

Narrow first, then wider.

v0.1

Core gateway

Middleware, YARP, YAML policy, regex/PII/HTTP scanners, OTel events.

v0.2

Tool firewall

Per-tool authorization, argument validation, approval workflow.

v0.3

Scanner adapters

PromptGuard, LlamaFirewall, Azure Content Safety, ONNX.

Later

Client SDK

Optional Angular telemetry. Deliberately outside the MVP.

Put a checkpoint in front of your agents.

dotnet add package SentinelAI.AspNetCoreStar on GitHub ↗

SentinelAI.NET

Secure every AI call before it does damage.