Agent Fleet & Insider Risk
Conventional insider-risk and endpoint-DLP tools watch people moving files. They have no visibility into an AI agent — the API calls it makes, the tools it invokes, and the outputs it produces. AgentWatch governs that non-human actor surface directly.
How are agents deployed into the fleet?
Section titled “How are agents deployed into the fleet?”The AgentWatch agent runs in a sidecar or per-node mode built for Kubernetes pods and Linux virtual machines (RHEL, CentOS, Ubuntu, Debian). Rather than intercepting traffic, it exposes explicit endpoints that application containers opt into: an OpenAI-compatible endpoint and a forward proxy. It stamps user attribution and gateway authentication onto outbound traffic, reports a heartbeat tagged with Kubernetes node, pod, and namespace context, and fails open — if the gateway is unreachable the workload’s traffic passes straight through rather than blocking.
Deployment artifacts include a multi-architecture container image, a per-node DaemonSet manifest, a sidecar-injection example, a parameterized Helm chart, and a one-line VM installer served by the gateway itself. The console renders fleet coverage as a health grid with one cell per deployed agent, plus an inventory table and version distribution.
Can agents optimize their own traffic?
Section titled “Can agents optimize their own traffic?”Optionally. Each deployed agent can enable an in-process optimization stage that runs before egress: an exact and semantic response cache (a hit is served locally and the provider call is skipped entirely) and prompt and token compression for large repeated history and tool payloads. Optimization is off by default, opt-in per agent, and fails open — any error or timeout passes the request through untouched.
Each agent reports cache hits, baseline tokens, and tokens actually forwarded, which the console aggregates into a direct-versus-optimized comparison: model calls avoided, tokens saved as a percentage, cache hit rate, and estimated cost saved.
How are MCP tools governed?
Section titled “How are MCP tools governed?”AgentWatch includes an MCP proxy that aggregates external MCP servers behind one governed endpoint, with a server registry as the mandatory access path. Tool discovery is filtered by the requesting user’s permissions, so users only see the tools they are allowed to invoke, and every invocation is logged with caller identity, DLP-scanned arguments, and response. Per-server access-control lists, per-server and per-tool rate limits, and connection testing are all built in.
MCP observability is tracked independently of model execution — per-server uptime, request volume, latency, and error rate — so a failure inside a tool server can be debugged without disentangling it from model errors.
What is Insider Risk for AI agents?
Section titled “What is Insider Risk for AI agents?”A risk-scoring and enforcement layer over the agent surface. AgentWatch computes agent risk indicators live from DLP events, tool-approval decisions, and usage, across four categories:
| Category | Example indicators |
|---|---|
| Exfiltration | Blocked data exfiltration; PII or payment data in agent traffic; sensitive design or proprietary IP |
| Manipulation | Prompt-injection attempts; jailbreak and policy-evasion attempts |
| Boundary | Unauthorized tool invocation; high-risk tool requested |
| Anomaly | Off-hours agent activity |
Organizations can author custom indicators in the UI with their own name, category, severity, weight, and matcher, and can disable built-ins that do not apply. Custom hits fold into the same risk score.
What can AgentWatch do about a risky agent?
Section titled “What can AgentWatch do about a risky agent?”Enforce, inline. A configurable policy maps an agent’s risk score to an action at three thresholds:
- Warn — annotate and log, traffic continues.
- Step up — require human approval before the call proceeds.
- Block — refuse the request before it reaches the provider, returning a distinct refusal that names the policy and the score.
Enforcement runs in the gateway path itself, is cached for speed, fails open so a policy-evaluation fault never takes down traffic, and applies immediately when a policy is saved. Every decision is written to a persisted audit log. Enforcement is off by default — normal traffic is unaffected until a policy is configured and enabled.
Is there case management for AI incidents?
Section titled “Is there case management for AI incidents?”Yes. Risky actors surface with an organization-level risk score and their top contributing indicators, along with data-access visibility showing which resources and models agents read from and write to, with a sensitivity flag. Incidents open as cases that can be assigned, investigated, and closed against a persisted evidence timeline, and an actor can be added to a watchlist for heightened scrutiny.
Sources and references
Section titled “Sources and references”- Detection engines that feed risk indicators: Data protection and guardrails.
- Fleet dashboards: Observability and insights.