What is LLM security middleware?

Intercept layers in your application — route handlers, agent loops, retrieval pipelines — that call guardrail APIs and branch on verdicts before the next step runs.

Where should guardrail middleware call Unified Guard?

Before the LLM on assembled prompts, after inference on completions, and before tool execution with agent_action payloads. RAG may add separate ingest and retrieve middleware.

Is Unified Guard a mandatory LLM proxy?

No. IdenticAPI Unified Guard is API middleware you invoke from your code. Model provider calls remain under your existing HTTP clients and data processing agreements.

Should guardrail API keys be used in the browser?

No. Call POST /api/v1/guard only from server-side middleware. Client-side checks are bypassable and expose credentials.

What response fields should middleware parse?

decision, checks with per-check verdict and findings, request_id for audit, processing_time_ms for observability, and usage_units for metering.

LLM Security Middleware: Where Guardrails Fit

LLM security middleware is the code that runs between your application logic, the model provider, tools, and users — enforcing policy at each hop. Guardrails are the security checks that middleware executes: injection screening, PII detection, output safety, and agent action evaluation.

Understanding where middleware sits prevents two common mistakes: treating a model proxy as complete security, and bolting detectors onto the wrong side of the inference call. For guardrails basics, see What Are AI Guardrails?. For firewall vs application controls, see AI Firewall vs AI Guardrails.

What counts as middleware

In LLM stacks, "middleware" includes any intercept layer that can inspect or transform data in flight:

Middleware location	Examples
HTTP API layer	Express/FastAPI middleware, Next.js Route Handlers
Orchestration framework	LangChain/LlamaIndex hooks, custom agent loops
Retrieval pipeline	Pre-embed scanners, post-retrieve filters
Client edge	Rarely appropriate for secrets — keys must stay server-side

Security middleware calls policy engines (your code or a guardrails API) and branches on verdicts before the next step runs.

Architecture map

┌─────────────────────────────────────────────────────────────────┐
│                     Your application                             │
│                                                                  │
│  ┌────────────┐    ┌─────────────────┐    ┌────────────────┐ │
│  │ Route /    │    │ Security        │    │ Model client   │ │
│  │ controller │───▶│ middleware      │───▶│ (OpenAI, etc.) │ │
│  └────────────┘    │                 │    └────────────────┘ │
│                    │  • input guard  │           │            │
│                    │  • output guard │           ▼            │
│                    │  • action guard │    ┌────────────────┐ │
│                    └────────┬────────┘    │ Completions    │ │
│                             │             └────────┬───────┘ │
│                             ▼                      │         │
│                    ┌─────────────────┐           │         │
│                    │ Policy router   │◀──────────┘         │
│                    │ allow/review/   │                     │
│                    │ block           │                     │
│                    └────────┬────────┘                     │
│                             ▼                               │
│                    ┌─────────────────┐                     │
│                    │ Render / tools  │                     │
│                    └─────────────────┘                     │
└─────────────────────────────────────────────────────────────────┘
         ▲                                    │
         │                                    ▼
   Guardrails API                      Tool integrations
   (optional external)                 (DB, email, HTTP)

Middleware owns when to call guardrails. The guardrails API owns how to classify risk.

Guardrails API vs full proxy gateway

Some vendors position themselves as inline gateways — all model traffic routes through their proxy. Others provide caller-side APIs your middleware invokes while you retain the model HTTP client.

IdenticAPI Unified Guard is the second pattern. You call POST /api/v1/guard from your middleware with text, checks, and optional agent_action. IdenticAPI does not require replacing your OpenAI or Anthropic client with a full proxy path. Your application still:

Assembles prompts (including RAG and history)
Calls the model provider directly
Invokes guardrails at the hooks you define

This matters for:

Latency — one additional API call per hook, not double proxy hops to the model
Context — you send the exact assembled string your model will see
Agent tools — action checks run in your orchestration loop, not at a model-only gateway
Compliance — model provider relationships and data processing agreements stay under your existing contracts

Unified Guard orchestrates IdenticAPI detectors; it is not a substitute for auth, network segmentation, or WAF rules. It complements them as defense in depth.

Where to insert guardrail middleware

Before the LLM (input stage)

Runs on: user message, chat history, system prompt variables, retrieved chunks.

Checks: prompt_injection, pii_secrets (with optional redact).

Middleware responsibility: abort provider call on block; substitute redacted text on allow-with-redaction.

See Input vs Output Guardrails and Guardrails Before or After the LLM.

After the LLM (output stage)

Runs on: completion text (assembled for streaming).

Checks: output_safety, pii_secrets.

Middleware responsibility: replace blocked content with fallback; queue review outcomes.

See Moderate LLM Output.

Before tool execution (agent stage)

Runs on: structured tool proposal — not natural-language explanation alone.

Checks: agent_action with agent_action payload.

Middleware responsibility: allow execution, enqueue human approval, or reject.

See Runtime Security for AI Agents and Validate AI Tool Calls.

At retrieval boundaries (RAG middleware)

Separate middleware in ingest workers and query paths — scan chunks before embedding and before prompt injection. RAG Security covers retrieval-specific risks.

Example middleware flow (Node.js pseudocode)

async function handleChat(userId: string, message: string, history: string[]) {
  const assembledPrompt = buildPrompt(history, message, await retrieveChunks(message));

  const inputGuard = await fetch("https://www.identicapi.com/api/v1/guard", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.IDENTICAPI_API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      text: assembledPrompt,
      checks: ["prompt_injection", "pii_secrets"],
      redact: true
    })
  }).then((r) => r.json());

  if (inputGuard.decision === "block") {
    return { reply: SAFE_FALLBACK, request_id: inputGuard.request_id };
  }

  const promptForModel = pickRedactedText(inputGuard) ?? assembledPrompt;
  const completion = await callLlm(promptForModel);

  const outputGuard = await fetch("https://www.identicapi.com/api/v1/guard", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.IDENTICAPI_API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      text: completion,
      checks: ["output_safety", "pii_secrets"]
    })
  }).then((r) => r.json());

  if (outputGuard.decision === "block") {
    return { reply: SAFE_FALLBACK, request_id: outputGuard.request_id };
  }

  return { reply: sanitizeForHtml(completion) };
}

Adjust fail behavior on fetch errors per your policy — middleware must handle guardrail outages explicitly.

Unified Guard response contract

Middleware should parse stable fields:

{
  "request_id": "req_abc123",
  "api": "unified-guard",
  "decision": "review",
  "checks": [
    {
      "check": "prompt_injection",
      "verdict": "allow",
      "risk": "low",
      "findings": [],
      "reasons": ["No injection patterns detected"]
    }
  ],
  "usage_units": 2,
  "processing_time_ms": 45,
  "detector_version": "1.0.0"
}

Aggregate rule: block > review > allow. Log request_id with application trace IDs.

Full schema: Unified Guard docs.

Middleware vs business logic

Keep policy routing in middleware or a dedicated policy module — not scattered in UI components. Benefits:

Single place to update when detector versions change
Consistent behavior across web, mobile API, and batch workers
Easier testing with mocked guardrail responses

Business logic supplies context (tenant, user role); middleware supplies enforcement.

What middleware should not do

Store API keys in the browser — guardrail calls are server-side only
Trust client-reported verdicts — always re-check on the server
Skip assembly — scanning only message while history contains secrets defeats PII checks
Render before output guard — especially dangerous for streaming UIs

Choosing integration depth

Approach	Fit
Discrete detector APIs	Incremental adoption, one risk at a time
Unified Guard per hook	Parallel checks, one HTTP call per stage
Custom policy service wrapping Unified Guard	Large teams, centralized security ownership

Combine AI Security Guardrails shows multi-check requests. AI Guardrails API lists evaluation criteria for vendors.

Latency considerations

Each middleware hook adds network time. Parallel checks inside Unified Guard reduce multiple round trips to one. Co-locate app servers and guardrail regions when possible. Measure in your environment — AI Guardrails Latency.

Summary

LLM security middleware is where guardrails become enforceable policy — before inference, after inference, and before tools run. IdenticAPI Unified Guard fits as API middleware you invoke from that layer: real checks, aggregated decisions, no mandatory full proxy in front of your model provider.

Map your hooks, wire Unified Guard, and keep rendering and tool authorization in separate layers for true defense in depth.