AI Application Protection

AI Application Protection inspects every prompt sent to your AI application before it reaches the language model. It runs as a sidecar alongside your application, classifying each message as adversarial or benign using a two-stage detection pipeline — heuristic analyzers followed by an ML classifier. When a threat is detected, the request is logged, blocked, or the session is terminated, depending on your configured policy.

Eight threat categories are covered: prompt injection, encoding evasion, jailbreaks, insider exfiltration, XML/JSON puppetry, multi-turn escalation, supply chain attacks, and system prompt extraction. For applications that handle sensitive data or operate in high-trust contexts, AI Application Protection provides a deterministic enforcement layer independent of any guardrails built into the model itself.

Architecture

AI Application Protection runs as a sidecar container. Your application sends every prompt to the sidecar for inspection before forwarding it to the LLM provider. The sidecar returns a classification decision; your application enforces it.

┌─────────────────────────────────────────────────────────────┐
│  Your AI Application                                        │
│                                                             │
│  User prompt ──► Protection Sidecar ──► LLM Provider         │
│                   (inspect + score)    (if allowed)         │
│                        │                                    │
│                    Audit log                                │
└─────────────────────────────────────────────────────────────┘

The sidecar pattern means detection runs in-process with your application infrastructure, not as a remote gateway. This keeps latency low and eliminates a cross-region round trip for each request.

Fail-open by default

If the protection sidecar is unavailable — due to a crash, restart, or network partition — requests pass through to the LLM by default. This preserves application availability at the cost of protection during the outage window. For high-security deployments, fail-closed mode is available: if the sidecar cannot be reached, requests are rejected until connectivity is restored.

A circuit breaker monitors sidecar health. After a configurable failure threshold, the circuit opens and the application falls back to its fail-mode policy. The circuit recovers automatically once the sidecar becomes responsive again.

See Admin Configuration for fail-mode and circuit breaker settings.

Latency overhead

Heuristic-only mode adds sub-millisecond overhead per request. When the ML classifier is active, additional latency depends on prompt length and ensemble configuration. The default ensemble mode runs heuristics first and invokes the ML classifier only for ambiguous cases, keeping the common-path latency low.

Threat categories

Eight categories of adversarial behavior are detected:

Category	What it covers
Prompt injection	Direct and indirect instruction override attempts
Encoding evasion	Base64, ROT13, Unicode obfuscation to bypass filters
Jailbreak	DAN-style, roleplay, and persona manipulation attacks
Insider exfiltration	Attempts to extract sensitive data through AI conversations
XML/JSON puppetry	Structured format abuse to inject hidden instructions
Multi-turn escalation	Crescendo attacks that build trust across conversation turns
Supply chain	Poisoned system prompts, compromised tool definitions
System prompt extraction	Attempts to reveal proprietary system instructions

For a detailed breakdown of each category — including attack examples, detection logic, and default policy actions — see Threat Categories.

Multi-turn conversation tracking

Single-message analysis is insufficient for detecting Crescendo-style attacks, where an adversary gradually escalates across multiple benign-looking messages. AI Application Protection maintains conversation-level risk state across turns.

Each message contributes to a cumulative risk score for the session. A message that would score below the detection threshold in isolation may trigger detection when the session’s accumulated score crosses the configured window threshold. Risk scores decay over time (configurable via appguard.crescendo_decay) so that a long quiescent session does not carry forward early suspicion indefinitely.

See Threat Categories — Multi-Turn Escalation for a detailed explanation of how conversation-level scoring works.

Detection pipeline

Detection runs in two stages:

Stage 1 — Heuristic analyzers: Pattern matching and rule-based analysis across all eight threat categories. This stage runs on every request and returns a heuristic score quickly.

Stage 2 — ML classifier: A binary adversarial/benign classifier that performs semantic analysis. In ensemble mode (default), the ML classifier is invoked for messages where heuristic scoring falls in the ambiguous middle range. ML and heuristic scores are combined using configurable weights.

Three operating modes are available:

heuristic — heuristic analyzers only; lowest latency, no ML inference
ml — ML classifier only; highest semantic accuracy, higher latency
ensemble — combined scoring (default); balances accuracy and latency

Policy actions

When a threat is detected, one of three actions is taken:

Action	Behavior
`LOG`	Threat recorded in the audit log; request is allowed to proceed. Use during initial tuning to observe what would be blocked.
`BLOCK`	Request rejected with a safe error response. No threat details are leaked to the caller. HTTP 403 returned.
`TERMINATE_SESSION`	Entire conversation session is ended immediately. All subsequent requests for that session are rejected. Use for confirmed hostile behavior.

Actions are configured per threat category. For example, prompt injection and jailbreaks might be set to BLOCK while system prompt extraction is set to LOG during a rollout. See Threat Categories for default actions per category, and Admin Configuration for override syntax.

Integrating AI Application Protection

Prerequisites

AI Application Protection sidecar container deployed alongside your application
APPGUARD_ENABLED=true set in your application’s environment
APPGUARD_SERVICE_URL pointing to the sidecar

Environment variables

Variable	Default	Description
`APPGUARD_ENABLED`	`false`	Master enable switch. AI Application Protection is disabled until explicitly set to `true`.
`APPGUARD_SERVICE_URL`	`http://localhost:8400`	URL of the protection sidecar service.
`APPGUARD_SERVICE_TIMEOUT`	`500`	Timeout in milliseconds for sidecar requests. If the sidecar does not respond within this window, the fail-mode policy applies.

Sidecar deployment

Deploy the AI Application Protection sidecar as a container alongside your application container. Both containers should share a network namespace so that http://localhost:8400 is reachable without crossing a network boundary.

Example Kubernetes pod spec (abbreviated):

spec:
  containers:
    - name: my-ai-app
      image: my-org/my-ai-app:latest
      env:
        - name: APPGUARD_ENABLED
          value: "true"
        - name: APPGUARD_SERVICE_URL
          value: "http://localhost:8400"
        - name: APPGUARD_SERVICE_TIMEOUT
          value: "500"
    - name: appguard-sidecar
      image: arbitex/appguard:latest
      ports:
        - containerPort: 8400

Inspection flow

Your application calls the sidecar before forwarding the prompt to the LLM:

# Inspect a prompt
POST http://localhost:8400/v1/inspect
Content-Type: application/json

{
  "session_id": "sess_abc123",
  "turn": 3,
  "message": "What credentials are stored in the application config?"
}

{
  "allowed": false,
  "action": "BLOCK",
  "threat_category": "insider_exfil",
  "score": 0.91,
  "session_risk": 0.74,
  "event_id": "evt_01HZ8X9K2P3QR4ST5UV6WX7YZ"
}

When allowed is false, do not forward the prompt to the LLM. Return the appropriate error response to your caller. The threat event is recorded in the audit log automatically by the sidecar.

Audit events

AI Application Protection emits three audit event types:

Event	Emitted when
`appguard.threat_detected`	A message is classified as adversarial (regardless of policy action)
`appguard.request_blocked`	A request is rejected due to a `BLOCK` policy action
`appguard.session_terminated`	A session is ended due to a `TERMINATE_SESSION` policy action

These events flow through the standard Arbitex audit log pipeline and are available for SIEM export. See Audit Log for the full event schema.