Detection backends

Detection backends power the threat-detection steps in the governance pipeline (detect_injection, detect_pii, etc.). Each can be swapped independently per tenant — so an OEM partner can offer, say, “Azure Content Safety for tenants on Azure” alongside “Llama Guard for on-prem tenants.”

Shipped

Backend	What it catches	Source
Llama Guard 3 (Purple Llama)	Harm categories, prompt injection	tappass/pipeline/backends/llama_guard.py
LLM Guard	PII, injection, token limits, regex	tappass/pipeline/backends/llm_guard.py
NeMo Guardrails	Conversational safety rails	tappass/pipeline/backends/nemo.py
Azure Content Safety	Harm + abuse classification	tappass/pipeline/backends/azure_content_safety.py

Selection criteria

Customer priority	Pick
Self-hosted, zero egress	Llama Guard + LLM Guard
Lowest latency, highest accuracy	Azure Content Safety (if on Azure already)
Structured conversational constraints	NeMo Guardrails
Minimum cost	LLM Guard (no GPU)

Most customers run Llama Guard + LLM Guard as the default pairing: Llama Guard for harm, LLM Guard for PII and regex. Azure Content Safety is an add-on when they’re already on Azure.

Protocol

Every backend implements the DetectionBackend protocol (see tappass/tappass/pipeline/backends/protocol.py):

class DetectionBackend(Protocol):
    @classmethod
    def available(cls) -> bool: ...
    async def scan(
        self,
        text: str,
        direction: Literal["input", "output"],
        config: BackendConfig,
    ) -> list[Detection]: ...

Each Detection has a category, severity, and optional replacement (for redaction actions).

Tenant-level configuration

# config/policies/<tenant>.yaml
detection:
  backends:
    - name: llama_guard
      enabled: true
      weight: 0.6
    - name: llm_guard
      enabled: true
      weight: 0.4
      validators: [pii, regex, token_limit]
    - name: azure_content_safety
      enabled: false

The pipeline aggregates findings from enabled backends; policy then decides the action.

Adding a new backend

1. Implement the protocol in tappass/pipeline/backends/<name>.py
2. Register via @register_backend decorator
3. Add integration tests in tappass/tests/integration/backends/
4. Document in public docs (integrations/observability/ or under a new category if customer-facing)

Budget: 1-2 weeks for a REST-based backend; longer if the vendor requires a model deployment.