New in v2.1 — Observe Platform, AgentFleet, AgentKeel & Insider Risk
The v2.1 line adds a unified observability workspace (Observe Platform), a Kubernetes/VM-native fleet agent mode (AgentFleet), an embedded cost-optimization layer (AgentKeel), and an Insider Risk analytics + enforcement product built on the AI Agent. All four surfaces are additive: they layer on the existing gateway, usage, and DLP tables and ship as a plain image swap — no new SQL tables or columns are introduced (see §52.6).
52.1 Observe Platform
Section titled “52.1 Observe Platform”A themeable observability workspace embedded in the admin console as an expandable Observe Platform sidebar menu. The menu groups every operational view into nine expandable sections: AI, Services, Fleet, Optimize, Business, Security, Insider Risk, Delivery, and Logs. The console honors a dark/light theme selectable from a sidebar-footer toggle; the choice is persisted client-side.
Purpose: Give operators a single org-scoped analytics surface over gateway traffic — KPIs, time-series, model/provider breakdowns, prompt inspection, service topology, threats, and logs — without leaving the admin UI.
Console theme:
| Item | Value |
|---|---|
| Storage | localStorage key aw_theme (dark / light) |
| Control | Sidebar-footer theme toggle |
| Scope | Per-browser (client-side only; no server round-trip) |
Endpoints — all under /admin/api/observability, all GET, all org-scoped, all accept optional start / end date-range query params:
| Method | Path | Description |
|---|---|---|
| GET | /admin/api/observability/kpis |
Headline KPI tiles (requests, tokens, cost, latency, error rate) |
| GET | /admin/api/observability/timeseries/requests |
Request-count time series |
| GET | /admin/api/observability/timeseries/tokens |
Token-volume time series |
| GET | /admin/api/observability/timeseries/cost |
Cost time series |
| GET | /admin/api/observability/timeseries/latency |
Latency time series |
| GET | /admin/api/observability/model-usage |
Per-model usage + cost breakdown |
| GET | /admin/api/observability/filters |
Available filter facets (models, providers, users, teams) |
| GET | /admin/api/observability/provider/keys |
Provider API-key inventory + status |
| GET | /admin/api/observability/provider/summary |
Per-provider rollup (calls, tokens, cost) |
| GET | /admin/api/observability/prompts |
Prompt / response preview inspection feed |
| GET | /admin/api/observability/topology |
Service / provider topology graph |
| GET | /admin/api/observability/threats |
Security threat feed (DLP + WAF + blocks) |
| GET | /admin/api/observability/logs |
Structured request/audit log stream |
| GET | /admin/api/observability/funnel |
Request-lifecycle funnel (received → routed → completed) |
| GET | /admin/api/observability/verify/last |
Last verification / orchestration run status |
Notes / defaults: All endpoints resolve the org from the authenticated session and constrain every query to that org. Omitting start/end falls back to the console’s default window. When Demo mode is enabled (§52.5) each endpoint returns realistic demo data.
52.2 AgentFleet — fleet agent (sidecar / daemonset)
Section titled “52.2 AgentFleet — fleet agent (sidecar / daemonset)”agentwatch-connect gains a sidecar mode purpose-built for Kubernetes pods and Linux VMs, complementing the endpoint (desktop) agent of Section 29. In fleet mode the agent exposes an OpenAI-compatible API for in-cluster workloads and an HTTP(S) forward proxy for transparent capture, attributing traffic to a tenant via the configured user header.
Purpose: Put an AgentWatch data-plane next to server-side AI workloads (pods, VMs) so application traffic is governed and attributed without routing through a desktop agent.
Listeners:
| Port | Protocol | Surface |
|---|---|---|
8088 |
HTTP | OpenAI-compatible API + control — /v1/*, /healthz, /metrics |
7443 |
HTTP(S) | Forward proxy for transparent HTTP(S) capture |
Environment variables:
| Variable | Default | Purpose |
|---|---|---|
AGENTWATCH_SERVER_URL |
— | Central gateway base URL |
AGENTWATCH_EMAIL |
— | Identity the agent authenticates as |
AGENTWATCH_API_KEY |
— | Gateway API key (ak_…) |
AGENTWATCH_SIDECAR_PORT |
8088 |
OpenAI-compat + control listener port |
AGENTWATCH_PROXY_PORT |
7443 |
HTTP(S) forward-proxy listener port |
AGENTWATCH_DEPLOYMENT |
sidecar |
Deployment shape: sidecar or daemonset |
AGENTWATCH_NODE_NAME |
— | Kubernetes node name (attribution / telemetry) |
AGENTWATCH_POD_NAME |
— | Kubernetes pod name |
AGENTWATCH_NAMESPACE |
— | Kubernetes namespace |
AGENTWATCH_USER_HEADER |
X-Zscaler-User |
Request header carrying the attributed user email |
AGENTWATCH_FAIL_OPEN |
1 |
Fail open (pass traffic) when the gateway is unreachable |
AGENTWATCH_HEARTBEAT_MS |
30000 |
Heartbeat interval (ms) |
AGENTWATCH_OPTIMIZE |
0 |
Enable the AgentKeel optimization layer (see §52.3) |
Deploy artifacts (client-agent/deploy/):
| Artifact | Purpose |
|---|---|
Dockerfile |
Fleet-agent container image |
k8s/daemonset.yaml |
Node-level DaemonSet deployment |
k8s/sidecar-injection.yaml |
Sidecar-injection manifest for pod-level deployment |
helm/agentwatch-agent |
Helm chart for the fleet agent |
install.sh |
VM / bare-metal installer |
Endpoints:
| Method | Path | Description |
|---|---|---|
| GET | /agent/install.sh |
Server-hosted fleet-agent installer script |
| GET | /api/admin/agent-fleet |
Fleet rollup: totals, deploymentBreakdown, optimizer aggregate, agents[] |
| POST | /agent/heartbeat |
Liveness + telemetry, extended for fleet (see below) |
Heartbeat extensions: the fleet POST /agent/heartbeat body is extended with deployment (sidecar/daemonset), a kubernetes { node, pod, namespace } object, and a sidecar { … } block carrying listener/runtime state. The existing GET /api/admin/agent-fleet rollup (Section 28) surfaces the new deploymentBreakdown and optimizer aggregate alongside the per-agent list.
Notes / defaults: Fleet agents fail open by default (AGENTWATCH_FAIL_OPEN=1) so a gateway outage never blocks application traffic. The daemonset shape governs node-wide egress; the sidecar shape governs a single pod.
52.3 AgentKeel — optimization layer
Section titled “52.3 AgentKeel — optimization layer”An embedded cache + compression layer inside the fleet agent that reduces tokens sent upstream (and therefore cost) before a request reaches the provider. It is opt-in and off by default.
Purpose: Cut LLM spend and latency at the agent by serving cache hits, compressing/deduplicating prompt payloads, and reducing token volume — while reporting a direct-vs-optimized comparison to the fleet dashboard.
Environment variables:
| Variable | Default | Purpose |
|---|---|---|
AGENTWATCH_OPTIMIZE |
0 |
Master switch for the AgentKeel layer |
AGENTWATCH_OPTIMIZE_CACHE |
— | Sub-toggle: response cache |
AGENTWATCH_COMPRESS |
— | Sub-toggle: prompt/payload compression |
AGENTWATCH_SEMANTIC |
— | Sub-toggle: semantic (embedding-based) cache |
AGENTWATCH_CCR |
— | Sub-toggle: CCR (context/content reduction) |
AGENTWATCH_OPTIMIZE_DB |
— | Backing store path for the optimizer cache DB |
OPTIMIZER_COST_PER_MTOK |
0.30 |
Cost model — USD per million tokens, used to price tokens saved |
Metrics: the layer reports cache hits, tokens saved, tokens baseline (what a direct-to-provider call would have sent), and tokens sent (what actually egressed via AgentKeel). Savings are priced with OPTIMIZER_COST_PER_MTOK.
Endpoint:
| Method | Path | Description |
|---|---|---|
| GET | /api/admin/agent-fleet/optimizer |
Optimizer rollup — fleet-wide and per-agent direct-vs-optimized (baseline vs sent tokens, cache hits, cost saved) |
Notes / defaults: With AGENTWATCH_OPTIMIZE=0 the agent behaves as a pure governance data-plane and the optimizer endpoint reports zeroed aggregates. Sub-toggles let operators enable only the mechanisms (cache / compress / semantic / CCR) appropriate for their workload.
52.4 Insider Risk (AI Agent)
Section titled “52.4 Insider Risk (AI Agent)”An AI-driven insider-risk product surfaced under the Observe Platform Insider Risk menu. It scores actors and the organization on risk, maps who is accessing which data, manages AI incident cases, and can adaptively enforce policy inline at the gateway.
Purpose: Detect and respond to risky AI usage by employees — scoring behavior against a library of Agent Risk Indicators (ARIs), exposing data-access visibility, running case management, and (optionally) enforcing warn/step-up/block decisions inline.
Components:
- Agent Risk Indicators (ARIs) — a built-in indicator library plus custom ARI authoring. A custom ARI is a keyword matcher over a whitelisted set of fields only:
dlp.violation_type,dlp.scan_type,usage.query_preview,usage.response_preview,usage.model_id,usage.provider. - Risk scoring — per-actor risk scores plus an aggregate org risk score.
- Data-access visibility — which actors touched which data/providers/models.
- AI incident case management — open, annotate, and resolve cases.
- Adaptive enforcement — policy thresholds for warn / step-up / block, enforced inline at the gateway; fail-open so an enforcement-path error never blocks traffic.
- Watchlist — flag actors for heightened monitoring.
Endpoints — under /admin/api/observability/insider-risk:
| Method | Path | Description |
|---|---|---|
| GET | /admin/api/observability/insider-risk/overview |
Org risk score, top risky actors, indicator summary |
| GET | /admin/api/observability/insider-risk/indicators |
List ARIs (built-in + custom) |
| POST | /admin/api/observability/insider-risk/indicators |
Create a custom ARI |
| PATCH | /admin/api/observability/insider-risk/indicators/:id |
Update a custom ARI |
| DELETE | /admin/api/observability/insider-risk/indicators/:id |
Delete a custom ARI |
| GET | /admin/api/observability/insider-risk/data-access |
Data-access visibility (actor → data/provider/model) |
| GET | /admin/api/observability/insider-risk/cases |
List AI incident cases |
| POST | /admin/api/observability/insider-risk/cases |
Open a case |
| PATCH | /admin/api/observability/insider-risk/cases/:id |
Update / annotate / resolve a case |
| GET | /admin/api/observability/insider-risk/enforcement |
Current adaptive-enforcement policy + decisions |
| PUT | /admin/api/observability/insider-risk/enforcement/policy |
Set enforcement policy (warn / step-up / block thresholds) |
| POST | /admin/api/observability/insider-risk/watchlist |
Add an actor to the watchlist |
Persistence: all Insider Risk state (indicators, cases, enforcement policy, watchlist) is stored as JSON in the existing system_settings table under org-scoped keys of the form insider_risk_*:<orgId> — no schema change and no new tables/columns.
Notes / defaults: Custom ARI matching is deliberately constrained to the whitelisted fields above so authored indicators can only inspect governed metadata/previews. Inline enforcement is fail-open. (Note: the AgentKeel cost variable OPTIMIZER_COST_PER_MTOK is unrelated to Insider Risk scoring.)
52.5 Demo mode
Section titled “52.5 Demo mode”Every new v2.1 surface — Observe Platform views, AgentFleet rollups, AgentKeel optimizer metrics, and Insider Risk analytics — returns realistic demo data when demo mode is enabled, so a sales engineer or evaluator sees a fully populated workspace before wiring real traffic. Demo mode is per-user toggleable via POST /admin/demo-mode (see §15.2 for the underlying DemoModeManager).
52.6 Upgrade / persistence note
Section titled “52.6 Upgrade / persistence note”v2.1 introduces no new SQL tables and no new columns. Observe Platform reads existing usage / DlpEvent data; AgentFleet/AgentKeel telemetry flows through the existing agent-fleet + heartbeat plumbing; Insider Risk persists to system_settings JSON keys. Upgrading is therefore a plain image swap — docker compose pull && docker compose down && docker compose up -d — with no migration step required.