June 3, 2026 · 8 min read · AGENTIC SECURITY · Part 4 of 5 — Agentic AI Security cluster

Endpoint Detection for Agent Fleets with Wazuh

An agent fleet isn't a human endpoint — it's dozens of autonomous processes running 24/7 with API access, filesystem writes, and no user to observe anomalies. Wazuh with custom agent-fleet rules is the SIEM layer that watches when no one else is.

TL;DR

Three ATT&CK techniques dominate agent fleet endpoint risk: T1078 (Valid Accounts — agent service accounts compromised), T1059 (Command and Scripting Interpreter — agents shell out to bash), and T1190 (Exploit Public-Facing Application — agent API endpoints). Wazuh with custom decoders for Python agent processes covers all three. Maps to NIST AI RMF GOVERN-1.1, MEASURE-2.7, MANAGE-3.1, and NIST CSF DE.CM-01.

Why standard EDR tuning doesn't fit agent fleets: most endpoint detection is tuned for human behavioral baselines — normal login hours, normal process tree, normal file access patterns. An agent process that runs 24/7, shells out to bash on every task, and writes files continuously looks exactly like malware to default Wazuh rules. Agent-specific tuning isn't optional — it's the difference between useful alerts and alert fatigue that trains operators to ignore everything.

The three ATT&CK techniques most relevant to agent fleets

Technique	ID	How it manifests in agent fleets
Valid Accounts	T1078	Agent service accounts often have broad permissions and no MFA. A compromised agent account gives the attacker persistent, privileged access that looks like normal agent traffic.
Command and Scripting Interpreter	T1059	Agents legitimately shell out to bash for tool execution. An injection-compromised agent uses the same subprocess path for attacker commands. Default Wazuh rules can't distinguish the two without agent-specific context.
Exploit Public-Facing Application	T1190	Agents expose REST endpoints for health checks, webhook triggers, and peer-to-peer comms. Unauthenticated endpoints or endpoints with debug traces are the entry point for initial access.

Wazuh configuration for agent fleets

Step 1: Deploy a Wazuh agent on every fleet host

Install a Wazuh agent on every server running agent processes. Configure the agent to monitor:

The agent process directory (/home/user/Project/TheBaby_Agents/) for unexpected file modifications
The .env file and credentials directory for any read access by non-authorized processes
All outbound network connections from agent processes — an agent that suddenly contacts an unknown IP is T1078 post-exploitation
The systemd journal for agent service restarts — unexpected restarts are an indicator of exploit attempts against T1190

Step 2: Custom decoder for Python agent processes

Standard Wazuh decoders don't understand Python agent log formats. A custom decoder extracts structured fields from agent log lines:

<!-- /var/ossec/etc/decoders/agent_fleet_decoder.xml -->
<decoder name="agent_fleet">
  <prematch>^\d{4}-\d{2}-\d{2}.*agent_id=</prematch>
  <regex>^(\S+) .* agent_id=(\S+) tool=(\S+) status=(\S+)</regex>
  <order>timestamp,agent_id,tool_name,status</order>
</decoder>

Step 3: Custom rules for agent-specific anomalies

<!-- /var/ossec/etc/rules/agent_fleet_rules.xml -->

<!-- T1078: Agent service account used from unexpected IP -->
<rule id="100200" level="12">
  <if_sid>5501</if_sid>  <!-- authentication success -->
  <srcip>!10.0.0.0/8</srcip>
  <description>ATT&CK T1078: Agent service account login from external IP $(srcip)</description>
  <group>attck_t1078,agent_fleet</group>
</rule>

<!-- T1059: Bash subprocess spawned outside expected tool list -->
<rule id="100201" level="10">
  <if_sid>5900</if_sid>  <!-- process creation -->
  <match>bash -c</match>
  <field name="process.parent_name">python3</field>
  <field name="process.cmdline">!^(pytest|pip|uv|git)</field>
  <description>ATT&CK T1059: Unexpected bash subprocess from python3 agent</description>
  <group>attck_t1059,agent_fleet</group>
</rule>

<!-- T1190: Agent endpoint returns 500 with traceback -->
<rule id="100202" level="8">
  <decoded_as>agent_fleet</decoded_as>
  <field name="status">500</field>
  <field name="message">Traceback</field>
  <description>ATT&CK T1190: Agent endpoint error with traceback leak ($(agent_id))</description>
  <group>attck_t1190,agent_fleet</group>
</rule>

Step 4: Baseline normal agent behavior, then alert on deviations

The most powerful Wazuh rule type for agent fleets is the statistical anomaly rule — flag when a metric deviates more than 3 standard deviations from the agent's own historical baseline. This catches T1059 variants that an attacker has carefully crafted to stay below static thresholds:

<rule id="100210" level="9" frequency="15" timeframe="300">
  <decoded_as>agent_fleet</decoded_as>
  <field name="tool_name">bash</field>
  <description>Agent $(agent_id) bash usage spike: 15+ in 5 min</description>
  <group>attck_t1059,agent_fleet,anomaly</group>
</rule>

Integrating with the agent fleet's own observability

Wazuh works best when it consumes the fleet's own structured event stream, not just OS-level logs. At BlindOracle, the proof chain observability layer emits a structured JSON event for every agent action. Wazuh ingests this via a custom log file configuration and can correlate proof-chain events with OS-level indicators — giving you the "did the agent's proof chain show an anomaly at the same time the bash spike happened?" correlation that standalone SIEM can't provide.

This bidirectional integration maps to NIST AI RMF MEASURE-3.1 (measure AI system effectiveness in context) and NIST CSF RS.MA-01 (incident management alignment).

Framework mapping

Control	ATT&CK Technique	NIST AI RMF	NIST CSF
Service account login monitoring	T1078	GOVERN-1.1	DE.CM-01
Subprocess tree anomaly rules	T1059	MEASURE-2.7	DE.AE-02
Agent endpoint error monitoring	T1190	MANAGE-3.1	RS.MA-01
Statistical anomaly baselines	All three	MEASURE-2.7	DE.CM-01
Proof-chain + OS event correlation	All three	MANAGE-2.4	RS.MA-01
Agent context manipulation detection	AML.T0054 (Prompt Injection)	GOVERN-1.1	DE.AE-02

Wazuh deployment checklist for agent fleets:
✅ Wazuh agent installed on all fleet hosts; manager on dedicated host
✅ Custom decoders for Python agent log format
✅ ATT&CK-labeled rules for T1078, T1059, T1190
✅ Statistical anomaly rules with per-agent baselines
✅ Agent proof-chain events fed into Wazuh log pipeline
✅ Alerts correlated with audit attestation for incident response

Agentic AI Security series: Part 1 — API Key Security · Part 2 — LLM Guardrails · Part 3 — Supply Chain Attacks · Part 4 — Endpoint Detection (this page) · Part 5 — Memory Forensics

BlindOracle agents run with auditable observability by default

Every action produces a signed proof. Every proof is verifiable externally. No black-box agent behavior.

See the proof run