> ## Documentation Index
> Fetch the complete documentation index at: https://docs.beyondguard.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# BeyondGuard Architecture: Layers, Services, and Request Flow

> BeyondGuard runs as a containerized microservice stack that inspects every AI interaction inline, organized into six cooperating layers and deployable fully on-premise.

BeyondGuard is deployed as a **containerized microservice stack** that sits inline in your AI traffic and inspects every interaction before it reaches a model, a tool, or a user. The platform runs **fully on-premise** with no cloud dependency — no data has to leave your environment — and is organized into six cooperating layers, each with a distinct role.

## The six layers

| Layer | Role | Key components |
| - | - | - |
| **Adapter** | Normalizes heterogeneous input protocols into a single internal format | File, RAG, AI, Context, Agent/MCP, ICAP, IMAP, Exchange, and POP adapters |
| **Gateway** | First line of traffic control and filtering | Rate Limiter, Gateway, ICAP Server, Mail Server |
| **Core** | Orchestrates inspection and policy evaluation | Service Engine, Policy Engine, Cache Manager, OCR Service, Rule Checker |
| **Proxy** | Routes traffic to the correct model and vector store | AI Router, RAG Router |
| **Artificial** | Local inference and external integration | Embedded BG Model, adapter plugins for SIEM / OSSIM / OTIM |
| **Data** | Persistent state, audit, and eventing | Configuration DB, Log DB, Event Manager, Cache Manager |

The **Core Layer** runs a pool of dedicated guard workers that execute the platform's inspection controls in parallel — one worker per control in the [Controls Catalog](/concepts/controls-catalog) — backed by an OCR service (Tesseract plus vision-language models) that extracts text from images and scanned documents before inspection.

The **Artificial Layer** hosts the embedded **BG Model**: an on-device security model, served locally via vLLM, that performs threat scoring, classification, and response shaping without any external API call. This is what keeps detection independent of the model being protected.

## End-to-end request flow

<Steps>
  <Step title="Client request">
    A chat, LLM, RAG, agent, proxy, or mail request arrives at the system boundary.
  </Step>

  <Step title="Adapter normalization">
    The matching adapter normalizes the request into the standard internal format.
  </Step>

  <Step title="Gateway">
    Rate limiting is applied and traffic is dispatched to the Core Layer via the Gateway, ICAP Server, or Mail Server.
  </Step>

  <Step title="Core processing">
    The Service Engine distributes work across the guard workers; the cache, OCR, policy engine, and rule checker are evaluated in parallel.
  </Step>

  <Step title="Routing decision">
    The AI Router and RAG Router select the target — cloud LLM, on-prem LLM, cloud vector DB, or on-prem vector DB — based on routing policy, compliance rules, and data-residency requirements.
  </Step>

  <Step title="Response and logging">
    The result is returned to the caller; events are logged to PostgreSQL, streamed via Kafka, cached in Redis, and forwarded to your SIEM.
  </Step>
</Steps>

## Deployment targets

The stack is fully containerized and runs on:

* **Red Hat OpenShift** — Helm chart deployment, Route & Ingress support, OpenShift OAuth, SCC/SCM compliance, built-in image registry.
* **Kubernetes** (vanilla K8s, EKS, GKE, AKS) — Helm 3 chart, namespace isolation, HPA auto-scaling per service, ConfigMap/Secret management, NetworkPolicy, Persistent Volumes.
* **Docker Compose** — single-node deployment with a provided `docker-compose.yml`, volume mounts, and health-check/restart policies.
* **Google Cloud Anthos** — Config Management, multi-cluster fleet support, Workload Identity, OPA Policy Controller, Anthos Service Mesh.

## Built-in Red Team Worker

A Celery-powered adversarial-testing subsystem is built into the pipeline for continuous security validation. It runs a five-stage loop — scenario **Builder**, **Test Builder**, **Runner**, **Evaluator**, and **Reporter** — executing attack suites against the live pipeline, scoring policy effectiveness, and pushing findings to the Log DB and SIEM integrations. See [Red Teaming](/guides/red-teaming).

## Related

<CardGroup cols={2}>
  <Card title="On-Prem Requirements" icon="server" href="/deployment/on-prem-requirements">
    Backing services, network, storage, and GPU prerequisites.
  </Card>

  <Card title="Infrastructure Sizing" icon="gauge" href="/deployment/infrastructure-sizing">
    Reference CPU, memory, and GPU sizing.
  </Card>

  <Card title="ICAP & Proxy" icon="network-wired" href="/deployment/icap-proxy">
    Inline inspection as a proxy via ICAP.
  </Card>

  <Card title="The Six Guards" icon="shield-halved" href="/concepts/guards">
    How the layers map to the guard model.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.