Autonomous Cloud & Infrastructure SecOps: Integrating Wazuh SIEM/XDR, HashiCorp Vault, and Agentic AI Across AWS, GCP, and Proxmox Fleets

Modern enterprise infrastructure rarely lives inside a single trust boundary. A typical production environment spans Google Cloud Platform (GCP) GKE clusters and Shared VPCs, Amazon Web Services (AWS) Transit Gateway spokes and EC2 workloads, perimeter Juniper SRX / Cisco ASA security zones, and on-premises Proxmox VE and Kubernetes bare-metal nodes. While open-source Wazuh SIEM & XDR provides exceptional unified visibility across all of these environments, traditional security operations workflows break down at scale for two reasons: alert fatigue and LLM context-window bloat.

If you feed raw OpenSearch JSON alert documents or unfiltered vulnerability indices directly into an AI coding or operations agent, a single query can consume 40,000+ tokens—causing high latency, hallucinated package names, and missed stale-index edge cases. In this architectural deep dive, we walk through how we engineered a zero-dependency, sub-150-token Wazuh SIEM/XDR CLI and Model Context Protocol (MCP) bridge backed by HashiCorp Vault, and how our two-tier Agentic AI (ai-ops) platform correlates hybrid cloud telemetry (AWS GuardDuty/CloudTrail, GCP Cloud Audit Logs, and Linux/Kubernetes XDR agents) into deterministic Ansible and Terraform remediation pipelines.

1. Why Traditional SIEM Workflows Fail Agentic AI

Wazuh v4.x separates security operations across two distinct API planes:

• The Wazuh Server REST API (55000/tcp): Manages JWT authentication (/security/user/authenticate), agent enrollment and health (/agents), CIS Security Configuration Assessment (SCA) pass/fail ratios (/sca/<agent_id>), and active-response firewall blocks.
• The OpenSearch Indexer API (9200/tcp): Stores real-time MITRE ATT&CK security alerts in wazuh-alerts-4.x-* and per-package CVE vulnerability states in wazuh-states-vulnerabilities-*.

When querying wazuh-states-vulnerabilities-* across a hybrid fleet, we discovered three operational traps that naive dashboards and scripts miss:

1. Disconnected Ephemeral Cloud Nodes: Auto-scaled AWS EC2 or GCP GKE nodes that terminated days ago leave orphaned CVE documents in the OpenSearch vulnerability index unless filtered against live status=active agent IDs from port 55000.
2. Stale Pre-Patch Index Records: After an Ansible kernel or package upgrade, historical vulnerability documents with older vulnerability.detected_at timestamps can persist until the next full syscollector scan or explicit _delete_by_query index hygiene pass.
3. Multi-Megabyte JSON Responses: Querying 500 alerts or CVEs without server-side OpenSearch aggregations (terms, cardinality, top_hits) dumps megabytes of verbose JSON that overwhelm both human operators and AI orchestrators.

2. Unifying AWS, GCP, Network Perimeter & Proxmox Telemetry

To eliminate blind spots between cloud control planes and on-premises hypervisors, every security domain streams structured events into our central Wazuh XDR pipeline:

• Amazon Web Services (AWS): AWS CloudTrail management/data events, GuardDuty threat findings, and VPC Flow Logs stream via S3/Kinesis into the Wazuh AWS module (wodle name="aws-s3"), correlating IAM privilege escalations (rule.level >= 10) alongside host-level EC2 and EKS container telemetry.
• Google Cloud Platform (GCP): GCP Cloud Audit Logs, Cloud Armor WAF blocks, and GKE audit streams route through a Google Cloud Pub/Sub subscription (wodle name="gcp-pubsub") authenticated via short-lived Workload Identity credentials.
• Perimeter Network Security (JNCIP-SEC): Juniper SRX security zones, Cisco ASA/Firepower appliances, and edge routers stream structured syslog (514/udp / TLS) into custom Wazuh decoders that trigger automated edge active-response drops when brute-force or port-scan thresholds are exceeded.
• Proxmox VE & Kubernetes Nodes: Lightweight Wazuh agents on every Debian/Ubuntu hypervisor and Kubernetes worker run continuous file integrity monitoring (syscheck), package/kernel inventory (syscollector), and CIS Benchmark Security Configuration Assessments (sca).

# /var/ossec/etc/ossec.conf — Hybrid AWS, GCP & CIS Benchmark Telemetry Configuration
ossec_config:
  wodles:
    - aws-s3:
        disabled: "no"
        interval: "5m"
        buckets:
          - name: "enterprise-secops-cloudtrail-logs"
            type: "cloudtrail"
            regions: "us-west-2,us-east-1,eu-central-1"
          - name: "enterprise-secops-guardduty-findings"
            type: "guardduty"
    - gcp-pubsub:
        project_id: "prod-secops-telemetry-01"
        subscription_name: "wazuh-cloud-audit-and-armor-sub"
        max_messages: 500
        interval: "2m"
  sca:
    enabled: "yes"
    scan_on_start: "yes"
    interval: "12h"
    policies:
      - "etc/shared/cis_ubuntu24-04.yml"
      - "etc/shared/cis_debian12.yml"

3. Building the Sub-150-Token Wazuh + HashiCorp Vault CLI

In our two-tier Agentic AI architecture, the primary orchestrator never holds raw database passwords or parses multi-megabyte JSON payloads. Instead, our zero-dependency Python CLI (wazuh_cli.py) retrieves short-lived credentials from HashiCorp Vault (secret/data/ai-ops/wazuh), authenticates to both the Wazuh Manager API (55000/tcp) and the OpenSearch Indexer (9200/tcp), and cross-filters open vulnerabilities against currently active agents:

#!/usr/bin/env python3
"""Zero-dependency Wazuh SIEM/XDR + OpenSearch CVE & CIS SCA Query Engine."""
import json
import ssl
import urllib.request

def fetch_active_agent_cves(indexer_url: str, active_agent_ids: list[str], auth_header: str) -> dict:
    """Query OpenSearch wazuh-states-vulnerabilities-* for active agents only."""
    query_dsl = {
        "size": 0,
        "query": {
            "bool": {
                "filter": [
                    {"terms": {"agent.id": active_agent_ids}},
                    {"terms": {"vulnerability.severity": ["Critical", "High"]}},
                ]
            }
        },
        "aggs": {
            "by_severity": {"terms": {"field": "vulnerability.severity", "size": 5}},
            "by_agent": {
                "terms": {"field": "agent.name", "size": 25},
                "aggs": {
                    "top_cves": {
                        "terms": {"field": "vulnerability.id", "size": 10},
                        "aggs": {
                            "pkg": {"terms": {"field": "package.name", "size": 3}}
                        }
                    }
                }
            }
        }
    }
    req = urllib.request.Request(
        f"{indexer_url}/wazuh-states-vulnerabilities-*/_search",
        data=json.dumps(query_dsl).encode("utf-8"),
        headers={"Authorization": auth_header, "Content-Type": "application/json"},
        method="POST",
    )
    ctx = ssl.create_default_context()
    ctx.check_hostname = False
    ctx.verify_mode = ssl.CERT_NONE
    with urllib.request.urlopen(req, context=ctx, timeout=15) as resp:
        return json.loads(resp.read().decode("utf-8"))

When an engineer or AI sub-agent runs wazuh_cli.py summary or wazuh_cli.py remediate, the CLI classifies every finding into five deterministic buckets:

1. Bucket 1 — Stale OpenSearch Documents: Automatically pruned via POST /wazuh-states-vulnerabilities-*/_delete_by_query when the package is already upgraded on the host.
2. Bucket 2 — Disconnected / Terminated Cloud Nodes: Filtered out of active posture calculations and queued for agent deregistration.
3. Bucket 3 — Unbooted / Old Linux Kernels: Hosts where apt-get dist-upgrade installed a patched kernel image, but an older linux-image-* package remains on disk awaiting apt-get autoremove --purge.
4. Bucket 4 — Container & Ingress Images: Correlated against upstream registries (Docker Hub / GHCR / GitLab Registry) to verify that a patched container tag actually exists before triggering a GitOps bump.
5. Bucket 5 — Standard OS Packages (apt / dnf): Grouped into a targeted Ansible remediation batch.

4. Closed-Loop Autonomous Remediation with Ansible, Terraform & GitLab CI/CD

Detecting a CVE or CIS Benchmark failure is only half the battle. To close the loop safely without risking unplanned outages on stateful hypervisors or Kubernetes control planes, our autonomous remediation workflow enforces three strict guardrails:

1. Maintenance-Window Pause (hermes-ctl pause): Before touching any monitored service, the remediation pipeline pauses autonomous peer-healers so rolling restarts do not trigger false-positive auto-heal rollbacks.
2. Ansible Package & Kernel Hygiene Playbook: Executes non-interactive DEBIAN_FRONTEND=noninteractive security upgrades, removes superseded kernel packages, and restarts affected systemd units only when required.
3. Post-Patch Index Verification: Triggers a fresh Wazuh syscollector scan, prunes stale vulnerability documents, and verifies that the fleet returns to 0 Critical / 0 High active CVEs.

# playbooks/patch_secops_vulns.yml — Deterministic Fleet CVE & Kernel Remediation
- name: Remediate Active Wazuh CVEs and Prune Superseded Kernels
  hosts: secops_patch_targets
  become: true
  serial: 2
  tasks:
    - name: Update apt cache and apply security upgrades non-interactively
      ansible.builtin.apt:
        update_cache: true
        upgrade: dist
        autoremove: true
        purge: true
        dpkg_options: "force-confdef,force-confold"
      environment:
        DEBIAN_FRONTEND: noninteractive

    - name: Restart Wazuh agent to trigger immediate syscollector rescan
      ansible.builtin.systemd:
        name: wazuh-agent
        state: restarted

5. Key Takeaways for Cloud & Security Architects

• Compress Telemetry Before It Reaches the LLM: Replacing raw SIEM JSON dumps with a deterministic <150-token CLI reduces AI triage latency from 30+ seconds to under 800 milliseconds while eliminating hallucinations.
• Unify Cloud and Bare-Metal Signals: Correlating AWS GuardDuty/CloudTrail, GCP Cloud Audit Logs/Cloud Armor, Juniper SRX / Cisco firewalls, and Proxmox/Kubernetes host telemetry inside Wazuh gives security architects a single queryable graph across every environment.
• Never Auto-Patch Without Upstream & Blast-Radius Verification: Pairing Wazuh vulnerability indices with NetBox SSOT, HashiCorp Vault, and gated Ansible/Terraform CI/CD pipelines turns continuous compliance from a quarterly fire drill into a deterministic daily engineering loop.