Production deployment

AgentGuard’s supported reference deployment is Docker on Kubernetes. The repository ships a server image, a console image, and a minimal Kustomize base under deploy/k8s. See the detailed Kubernetes operations, console deployment, and incident response guides alongside this overview.

Before deploying

1. Replace the example schema and policies in the agentguard-policies ConfigMap with reviewed policy files.
2. Create agentguard-secrets with a chain secret and agentguard-api-keys with the JSON API-key store expected by agentguard-server.
3. Create agentguard-console-env with the OIDC and session variables listed in frontend/README.md.
4. Put TLS at the ingress or service mesh. The PDP must not be exposed on a public network without authentication and encrypted transport.

Before applying the commands below, create the operator-owned, digest-pinned production overlay from the checked-in kustomization.yaml.example as described in the Kubernetes deployment guide. Registry names, image digests, and network/ingress policy depend on the target environment, so the template is intentionally not directly deployable.

The standalone PDP polls the API-key Secret content and reloads valid rotations/revocations without a process restart. After an update is visible at the mounted path it is checked every 250 ms; Kubernetes Secret projection itself is eventually consistent and depends on kubelet sync/cache settings. Invalid intermediate store content retains the last-known-good key set and is logged; check the server logs after credential updates.

kubectl apply -k deploy/overlays/production kubectl -n agentguard rollout status deploy/agentguard-pdp kubectl -n agentguard rollout status deploy/agentguard-console

The supplied manifests intentionally use one PDP and one console replica. Audit persistence is a ReadWriteOnce volume. Production console operation requires the Redis-compatible session and rate-limit stores; memory mode is development/e2e-only and never becomes an implicit production fallback. Multi-replica PDP operation is outside the shipped contract until a coordinated append-only audit backend is deployed.

Upgrade and rollback

Build and tag both images with the same release version, capture their registry digests, and deploy those digests from an operator-owned Kustomize overlay. Copy the checked-in production overlay template to deploy/overlays/production/kustomization.yaml, then replace its example registry names and digest placeholders and add environment-specific network policies. Do not deploy the template while placeholders remain, and never deploy the checked-in base directly for production because it uses sample tags. Apply the completed overlay, wait for readiness, then run an allow, deny, and audit verification smoke test. Roll back with kubectl rollout undo if readiness or audit checks fail. Keep the policy ConfigMap, secrets, and audit volume across application upgrades. The full smoke-test, backup, and rollback procedure is in Kubernetes operations.

Operational guarantees

• /healthz is liveness only.
• /readyz requires a loaded policy store and writable configured audit log.
• Standalone startup fails if the policy/schema watcher cannot be registered; runtime watcher errors are logged instead of being silently discarded.
• The audit destination must be a regular file, not a symlink, FIFO, or device node. On Unix the server enforces owner-only (0600) audit-file permissions at open, including for an existing file.
• Chained audit startup and append require durable chain-identity metadata; failure to persist its owner-only sidecar fails startup or withdraws readiness rather than silently opening a new chain identity.
• A configured audit append failure returns an error instead of allowing the decision to continue silently.
• Policy evaluation and audit append/fsync run on a bounded blocking pool. At most four PDP work items execute per process; saturation returns HTTP 503 or gRPC UNAVAILABLE instead of starving async workers or queueing unbounded work. Audit storage failures withdraw readiness until restart.
• A corrupted chained audit tail refuses startup instead of silently beginning a disconnected chain; restore or quarantine the damaged evidence first.
• The server stops accepting new work on SIGTERM and drains in-flight work; the deployment supervisor enforces the hard termination deadline.
• API-key authentication is required for non-loopback PDP listeners.
• The published PDP container defaults to API-key authentication; provide a populated key-store Secret before sending protected requests. Explicitly set AGENTGUARD_AUTH=disabled only for isolated local development or a smoke environment that cannot be reached by untrusted clients.

These guarantees depend on the adapter honoring decision == true. AgentGuard cannot protect an execution path that bypasses the PDP or ignores a denial.