Architecture
OpenBox is an enterprise AI agent governance platform — trust scoring, behavioral guardrails, policy enforcement, and cryptographic audit trails for autonomous AI agents.
This section covers how the platform is structured — components, protocols, and infrastructure integration. For install-flow docs, see Installation & Setup. For per-service specs, see Service Reference.
Three-plane model
OpenBox runs as three logical planes on Kubernetes:
| Plane | Purpose | Key services |
|---|---|---|
| Data plane | Orchestration, agent lifecycle, cryptographic attestation | openbox-core (5-container pod: server + 3 workers + scheduler) · openbox-core-codec · Temporal (server + web + Elasticsearch, optional variant) |
| Guardrails plane | ML-based prompt injection detection, content filtering | guardrails-api · model-host-detect-pii / -nsfw / -toxicity (CPU classifiers) · llamafirewall-server + vllm (Qwen3-8B on GPU) |
| Control plane | Platform CRUD, IAM, authorization | openbox-backend (REST :3000) · identity-service (Keycloak) · opa-app (OPA policy engine) |
All planes sit behind an Istio Gateway and (optionally) an ALB. Persistence: 3× PostgreSQL clusters (app / identity / temporal store) + Redis (session cache) + Elasticsearch (Temporal visibility) + S3 (OPA policy bundles) + KMS (envelope encryption).
Read this section
- Component diagram → — Mermaid flowchart of every service, ports, and dependencies
- Data flows → — traffic patterns, protocols, latency targets, failure modes
- Temporal variants → — self-hosted vs Cloud trade-offs + break-even math
- AWS integration surface → — what OpenBox binds to in AWS, and the customer decisions we don't opinionate on