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?

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?

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?

AgentWatch includes an MCP proxy that aggregates external MCP servers behind one governed endpoint, with a server registry as the mandatory access path. Per-server access lists decide who may use a server, per-tool rules decide which individual tools each caller may use (a blocked tool is also removed from that caller’s tool list), and tool arguments are DLP-scanned before they leave. Every call — allowed or refused — is recorded in the Usage Insights audit trail with caller identity and reason. Requests are rate-limited per caller. See MCP Tool-Call Policy for setup, rule semantics and the log entries.

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?

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?

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?

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.

How do I deploy a fleet agent?

The agent runs as a Kubernetes sidecar, a per-node DaemonSet, or a VM service. It exposes explicit opt-in proxy endpoints rather than intercepting traffic, and fails open — a workload never blocks because the gateway is unreachable.

# VM or bare-metal node — run as a normal user with sudo rights
export AGENTWATCH_SERVER_URL="https://<your-agentwatch-host>"
export AGENTWATCH_EMAIL="john.doe@acme.com"
export AGENTWATCH_API_KEY="ak_…"
curl -fsSL "$AGENTWATCH_SERVER_URL/agent/install.sh" | sudo -E sh

Verification and troubleshooting for the Linux installer are in Endpoint enrollment.

For Kubernetes, a DaemonSet manifest, a sidecar-injection example and a Helm chart ship with the agent. Deployed agents report node, pod and namespace, and appear in the console’s fleet health grid.

How do I see agent risk?

curl -s "https://<your-agentwatch-host>/admin/api/observability/insider-risk/overview?window=30d" \
  -H "Authorization: Bearer <tenant-admin JWT>"
curl -s https://<your-agentwatch-host>/admin/api/observability/insider-risk/indicators \
  -H "Authorization: Bearer <tenant-admin JWT>"

Indicators are computed from real DLP events, tool-approval decisions and usage. The built-in catalogue always exists, so judge the hit counts, not the presence of an indicator — a catalogue with every count at zero means nothing has triggered, which is the good outcome.

How do I enforce on a risky agent?

Adaptive enforcement maps a risk score to warn, step-up or block thresholds, applied inline so a risky agent is stopped before it reaches a provider. It is off by default.

Turn it on the way you would any blocking control: set the thresholds in warn mode first, watch which agents would have been affected for a week, then move the top band to block. An enforcement policy that fires on day one against real agents is how a rollout gets reverted.

Why does the fleet grid show an agent as unhealthy?

State	Meaning	Check
Not reporting	The agent cannot reach the gateway	Egress from that node; the agent fails open, so traffic still flows
Reporting, no traffic	Nothing is routed through its proxy endpoints	The workload must opt in — sidecar mode does not intercept
Version drift	Older agents across the fleet	Update centrally; the grid shows the spread

Sources and references

• Detection engines that feed risk indicators: Data protection and guardrails.
• Fleet dashboards: Observability and insights.