Skip to content

AegisFlow Architecture

System Overview

AegisFlow is a single Go binary that acts as a reverse proxy, policy boundary, and control plane for AI/LLM traffic and tool-using agents. It intercepts requests between clients and providers, adding authentication, rate limiting, policy enforcement, routing, usage tracking, approvals, evidence, and observability.

The default path is fully local and cost-free: a mock provider, YAML policies, in-memory storage, local audit evidence, and Prometheus metrics. Real providers, Redis, PostgreSQL, Kubernetes, and external policy systems are optional integrations.

Local-First Runtime

graph LR
    App[App or coding agent] --> Gateway[AegisFlow gateway]
    Gateway --> Auth[API key auth]
    Auth --> Policy[YAML policy engine]
    Policy --> Router[Router]
    Router --> Mock[Mock provider]
    Router -. optional .-> OpenAI[OpenAI-compatible provider]
    Router -. optional .-> Anthropic[Anthropic provider]
    Router -. optional .-> Azure[Azure OpenAI provider]
    Gateway --> Audit[Local audit and evidence]
    Gateway --> Metrics[Prometheus metrics]
    Gateway --> Admin[Admin API and dashboard]

Nothing in the local path requires a hosted account. Optional providers only run when a user configures their own key.

Component Diagram

graph TB
    Client[Client / OpenAI SDK] -->|HTTP| Gateway

    subgraph AegisFlow
        Gateway[HTTP Server]
        Auth[Auth Middleware]
        RL[Rate Limiter]
        PolicyIn[Policy Engine - Input]
        Router[Router]
        PolicyOut[Policy Engine - Output]
        Usage[Usage Tracker]

        Gateway --> Auth --> RL --> PolicyIn --> Router
        Router --> PolicyOut --> Usage
    end

    Router -. optional .-> OpenAI[OpenAI API]
    Router -. optional .-> Anthropic[Anthropic API]
    Router --> Ollama[Ollama]
    Router --> Mock[Mock Provider]

    Usage --> Metrics[Prometheus /metrics]
    Usage --> Traces[OTel Traces]
    Usage --> Admin[Admin API :8081]
    Usage --> Audit[Audit / evidence]

Request Flow

sequenceDiagram
    participant C as Client
    participant G as Gateway
    participant A as Auth
    participant R as Rate Limiter
    participant P as Policy Engine
    participant RT as Router
    participant PR as Provider
    participant U as Usage Tracker

    C->>G: POST /v1/chat/completions
    G->>A: Extract API key
    A-->>G: Tenant identified

    G->>R: Check rate limit
    R-->>G: Allowed

    G->>P: Check input policies
    P-->>G: Clean (no violations)

    G->>RT: Route to provider
    RT->>PR: Forward request
    PR-->>RT: Response

    G->>P: Check output policies
    P-->>G: Clean

    G->>U: Record usage + cost
    G-->>C: Return response

Package Structure

Package Responsibility
cmd/aegisflow Entry point, dependency wiring
internal/config YAML configuration loading
internal/gateway HTTP handlers for /v1/chat/completions and /v1/models
internal/middleware Auth, rate limiting, logging, metrics middleware
internal/provider Provider interface and adapters (Mock, OpenAI, Anthropic, Ollama)
internal/router Model-to-provider routing with strategies and fallback
internal/ratelimit Rate limiting (in-memory and Redis)
internal/policy Input/output policy engine with keyword, regex, and PII filters
internal/usage Token counting, cost estimation, per-tenant usage aggregation
internal/telemetry OpenTelemetry initialization
internal/admin Admin API server (health, metrics, usage)
pkg/types Shared request/response types

Key Design Decisions

Single binary, not microservices. For the MVP, all functionality runs in one process. The internal package boundaries are clean enough to split later if needed.

OpenAI-compatible API. Any application using the OpenAI SDK can connect to AegisFlow by changing base_url. This is the most important adoption decision.

Provider interface. All providers implement the same 6-method interface. Adding a new provider requires zero changes to the gateway, router, or middleware.

Mock provider first. The mock provider is a real first-class route target. It keeps demos, tests, CI, and local development free and repeatable.

Optional external services. Paid providers, cloud secret managers, hosted tracing backends, Redis, and PostgreSQL are optional. The project must remain useful without them.

Middleware chain. Each cross-cutting concern (auth, rate limiting, logging, metrics) is an independent middleware that can be added or removed from the chain.

In-memory by default, Redis optional. Rate limiting works without any external dependencies. Redis is available for distributed deployments.

Circuit breaker per provider. Failed providers are temporarily removed from the routing pool to prevent cascading failures.