What Is OpenClaw? Agentic CVE Remediation with Ansible Automation Platform

What Is OpenClaw?

OpenClaw is an AI agent framework that was demonstrated live at Red Hat Tech Day Netherlands 2026 in Bunnik, during the "Ansible Automation Platform 2.7 and Beyond" session presented by Fred van Zwieten and Ismail Dhaoui of Red Hat. In the demo, an OpenClaw agent ran inside an OpenShift Pod and used the Ansible Automation Platform (AAP) MCP server to autonomously detect, validate, and remediate a critical CVE across four production servers — end to end, without a human writing or triggering the fix.

The headline takeaway from Red Hat's presentation was not "the AI wrote a playbook." It was the opposite: the agent never wrote a fix at all. It selected a pre-approved, already-tested playbook exposed through the AAP MCP server, and every enterprise guardrail — policy engine, ITSM ticketing, CMDB, audit trail — stayed fully authoritative throughout the process. OpenClaw simply drove those existing systems faster and without manual handoffs.

This matters because it reframes what "agentic AI in IT operations" should mean. OpenClaw is not a code-generation bot let loose on production. It is an orchestration layer that reasons about when and how to invoke trusted automation that already exists.

See also: From Alert to Patched Fleet: An OpenClaw and AAP Remediation Walkthrough

The 5-Step Remediation Pipeline

The Bunnik demo walked through a complete lifecycle for a fictional but realistic critical vulnerability, CVE-2026-31337 (CVSS 9.8), affecting four production servers.

1. Detection and validation

The OpenClaw agent detected the CVE and cross-checked it against the CVE database before doing anything else — confirming severity, affected packages, and the exact hosts in scope.

2. Change management kickoff

Rather than acting unilaterally, the agent created a ServiceNow Change Request (CHG0012847), marked it priority critical, and scheduled a 03:00–05:00 EST maintenance window. It notified app owners via PagerDuty and attached all four affected servers to the change record. This is standard ITSM practice — the agent simply executed it instantly and consistently.

3. Policy gate (OPA)

Before any remediation could proceed, an Open Policy Agent (OPA) engine ran an automated review, checking that:

• the ITSM ticket was valid and properly scoped
• the maintenance window was confirmed
• the playbook was pre-approved for this specific CVE class
• a rollback plan existed

4. Rolling patch and reboot

Once policy passed, AAP executed the patch_and_reboot.yml playbook as a rolling operation, one host at a time: prod-web-01, prod-web-02, prod-api-01, and finally prod-db-01, which was drained before reboot. Monitoring was silenced for the maintenance window and automatically restored afterward. Health checks passed on every server before moving to the next.

5. Close and notify

The ITSM ticket was closed, app owners and the SRE lead were notified, the CMDB was updated, and a compliance report was filed automatically — closing the loop with the same rigor a human operator would be expected to follow, minus the delay.

Inside the OpenClaw Control Panel

The demo's control panel showed the agent, named sre-sally, running on Claude Sonnet 4.6 via LiteLLM. Visible tool calls included memory_search, runtime_search, and runtime_exec — giving the audience a transparent view into the agent's reasoning steps rather than a black box. The final change record, CHG9679226, showed the kernel upgraded from 5.14.0-427.el9 to 5.14.0-503.el9, with the previous kernel retained as a GRUB boot entry for rollback, and zero downtime achieved because each host was drained before its reboot.

See also: OpenClaw and the AAP MCP Server: Architecture for Autonomous Patching

Example: The Kind of Playbook OpenClaw Invokes

OpenClaw does not generate remediation logic on the fly. It selects from a catalog of pre-approved playbooks exposed via the AAP MCP server. A simplified illustration of what patch_and_reboot.yml might look like:

---
- name: Rolling kernel patch and reboot
  hosts: patch_targets
  serial: 1
  become: true
  vars:
    target_kernel: 5.14.0-503.el9
  tasks:
    - name: Silence monitoring for this host
      ansible.builtin.uri:
        url: "https://monitoring.example.com/api/v1/silence"
        method: POST
        body_format: json
        body:
          host: "{{ inventory_hostname }}"
          duration_minutes: 30

    - name: Drain database connections before reboot
      ansible.builtin.command: /usr/local/bin/db-drain --wait
      when: "'db' in group_names"

    - name: Apply kernel and security patches
      ansible.builtin.dnf:
        name: "kernel-{{ target_kernel }}"
        state: present

    - name: Reboot and wait for host to return
      ansible.builtin.reboot:
        reboot_timeout: 600

    - name: Run post-patch health check
      ansible.builtin.uri:
        url: "http://{{ inventory_hostname }}:8080/healthz"
        status_code: 200
      register: health
      retries: 5
      delay: 10
      until: health.status == 200

    - name: Restore monitoring
      ansible.builtin.uri:
        url: "https://monitoring.example.com/api/v1/unsilence"
        method: POST
        body_format: json
        body:
          host: "{{ inventory_hostname }}"

Where OpenClaw Fits vs. Traditional Automation

Why the Guardrails Matter More Than the AI

The most important architectural decision in this demo is what OpenClaw was not allowed to do: write its own remediation. Every action it took was a call into systems that already had authority in the enterprise — ServiceNow for change management, OPA for policy, AAP for execution, and the CMDB for the system of record. The AAP MCP server acts as the narrow, auditable interface between the agent's reasoning and the platform's execution engine, so nothing runs that wasn't already governed.

See also: AAP 2.7 EE Builder Step 1: Choosing a Base Image

Key Takeaways

• OpenClaw is an agentic AI framework shown at Red Hat Tech Day Netherlands 2026 orchestrating CVE remediation through Ansible Automation Platform's MCP server.
• The agent (sre-sally, running Claude Sonnet 4.6 via LiteLLM) detects and validates CVEs, but never writes remediation code itself.
• A five-step pipeline — detect/validate, ITSM ticketing, OPA policy gate, rolling patch execution, and close/notify — mirrors what a disciplined SRE team already does manually.
• The OPA policy check is a hard gate: ITSM validation, maintenance window, pre-approved playbook, and rollback plan must all pass before any host is touched.
• Rolling execution with per-host draining (as seen patching prod-web-01, prod-web-02, prod-api-01, and prod-db-01) delivered zero downtime, with the prior kernel kept as a GRUB entry for rollback.
• The real innovation is speed and consistency, not autonomy without oversight — ITSM, CMDB, policy, and audit trail remain the authoritative systems of record.