Deploying Panovista as a Sidecar

When routing real-time AI agent traffic via the Model Context Protocol (MCP), introducing network hops to a centralized security appliance adds unacceptable latency. Panovista solves this by deploying as a Sidecar Container directly alongside your core AI application.

By running in the same network namespace as your AI agent, Panovista acts as a localized, ultra-fast loopback proxy.

Why the Sidecar Pattern?

Zero-Trust by Default: Because Panovista intercepts traffic at localhost within the pod or task definition, no uninspected packets can ever leave the application environment.
Sub-Millisecond Overhead: Written in highly optimized Go, Panovista adds less than <1ms of latency to your JSON-RPC payloads. It processes data locally before initiating the outbound TLS connection to the LLM provider.
Granular Scaling: As your AI agents scale horizontally to handle increased load, the Panovista sidecar scales perfectly with them, ensuring no security bottlenecks.

Kubernetes (EKS/GKE) Integration

In a Kubernetes environment, Panovista deploys via a standard Pod configuration. Your primary agent container communicates with Panovista over 127.0.0.1, while Panovista handles the external egress routing and enforces the schema rules.

# Example snippet of a Panovista Sidecar in a Pod
apiVersion: v1
kind: Pod
metadata:
  name: internal-sales-agent
spec:
  containers:
  - name: ai-agent-app
    image: my-internal-agent:v2
    env:
      - name: MCP_ENDPOINT
        value: "[http://127.0.0.1:443](http://127.0.0.1:443)" # Routes to Panovista
  - name: panovista-proxy
    image: panovista/proxy:latest
    ports:
      - containerPort: 443
      ```