Tracking event-driven automation with Red Hat Lightspeed and Red Hat Ansible Automation Platform 2.6

As organizations shift from reactive automation to proactive and intelligence-driven operations, Event-Driven Ansible continues to gain momentum. By combining real-time system insights from Red Hat Lightspeed (formerly Red Hat Insights) with Event-Driven Ansible rulebooks, teams can automatically respond to security risks, configuration changes, compliance findings, and operational anomalies, without waiting for human intervention. With Red Hat Ansible Automation Platform 2.6, we introduced a small but meaningful enhancement that strengthens trust and observability in automated operations. Any job triggered by Event-Driven Ansible now automatically includes a label in the automation controller.

This simple addition provides powerful value. Teams can now easily identify, audit, and verify event-initiated automation, enabling clearer reporting, faster troubleshooting, and improved security posture awareness. In this article, I show you how this feature works using Red Hat Lightspeed events as the automation source, including a simple rulebook example you can try today.

The power of explainable automation

As organizations scale automation, one question comes up again and again: How do you know which changes happened automatically and which were triggered by a human? With event-driven automation, this becomes even more important. Security teams, site reliability engineers (SRE), platform engineers, and compliance officers need to answer:

• What action was taken automatically?
• Which event triggered the automation?
• When did it run, and on which system?
• Was the remediation successful?

Ansible Automation Platform 2.6 answers these questions by tagging jobs initiated through Event-Driven Ansible. The result is:

• Clear separation of automated and manual actions
• Better auditability and governance
• Faster investigation and troubleshooting
• Greater confidence in automated remediation pipelines

Using job labeling with Red Hat Lightspeed events

Red Hat Lightspeed brings AI-powered operational intelligence directly into your automation workflows, transforming raw system signals into actionable, real-time insights. Instead of waiting for alerts to be manually reviewed, Red Hat Lightspeed evaluates system state, security posture, configuration drift, lifecycle status, and compliance policies, and emits structured events that can immediately trigger automation. This means the same engine that helps operators understand what's happening in their environment can now drive automated remediation, end to end.

By pairing Red Hat Lightspeed with Event-Driven Ansible (part of Ansible Automation Platform), you gain a closed-loop automation pattern. Red Hat Lightspeed detects and interprets events, Event-Driven Ansible applies policy logic, Ansible controller executes the remediation, and jobs are labeled for full traceability and audit clarity.

Instead of automation simply running, automation now runs in an explainable way, with traceable, auditable context from detection to outcome.

Here is an Ansible Rulebook example where Red Hat Lightspeed detects malware on a host and triggers a remediation job in Ansible Automation Platform, with automatic job labeling for audit clarity. Below is a rulebook that listens for Red Hat Lightspeed malware security alerts and responds automatically:

---
- name: Respond to Red Hat Lightspeed events via AAP
  hosts: localhost
  sources:
    - redhat.insights_eda.insights:
        host: 0.0.0.0
        port: 5000
  rules:
    - name: Handle detected malware events
      condition:
        event.payload.data.application == "malware-detection"
        and event.payload.data.event_type == "detected-malware"
      action:
        run_job_template:
          name: handle-malware-detection
          organization: Default
          job_args:
            extra_vars: "{{ event.payload }}"
          labels:
            # Static label to track Red Hat Lightspeed-initiated automations
            - "Activated by Red Hat Lightspeed"
            # Dynamic labels from the event payload for full traceability
            - "{{ event.payload.source.application.display_name | default(event.payload.application) }}"
            - "{{ event.payload.source.event_type.display_name | default(event.payload.event_type) }}"
            - "{{ event.payload.context.display_name | default('Activated by Red Hat Lightspeed') }}"

The key focus in this rulebook is the labels directive. When the Red Hat Lightspeed event triggers the rule, the resulting job in Ansible Automation Platform controller automatically receives both a static label (such as Activated by Red Hat Lightspeed) and contextual, dynamic labels based on the event payload.

This means details like the originating policy, application, or detection type, even the affected host, become visible in the job record without manual tagging. If Red Hat Lightspeed includes additional context, such as CVE identifiers or severity, they can also be passed through automatically.

The result is end-to-end traceability that links an event to a decision, to action, and outcome.

Here's a job labeled by Event-Driven Ansible in the automation controller:

Also note that Ansible Automation Platform 2.6 automatically adds an Activated by Event-Driven Ansible label for all jobs initiated by Event-Driven Ansible, ensuring clear differentiation between runs triggered by Event-Driven Ansible and those manually executed.

Visibility, trust, and automated response

By combining Red Hat Lightspeed with Event-Driven Ansible, organizations move from detection to automated action, more securely and with complete transparency. When Red Hat Lightspeed detects a vulnerability, anomaly, or compliance deviation, it can trigger Ansible Automation Platform to respond instantly. This shortens the time between detection and remediation, reduces risk exposure, and ensures consistent, policy-aligned responses.

This approach doesn’t just accelerate response, it also improves clarity and traceability. With job labeling in Ansible Automation Platform 2.6, every event-driven job is automatically tagged so teams can see exactly why automation occurred and which Red Hat Lightspeed event initiated it. Instead of digging through logs or guessing whether a job was run manually, operators and security engineers get immediate visibility into the automation pathway. The job history becomes an authoritative source of truth, clearly tying events, automation logic, and remediation together.

Dynamic labels also help confirm that each automated action carries meaningful human context. When a Red Hat Lightspeed signal triggers an automation, the rulebook can apply labels based on event metadata, such as the originating application, event type, or policy name. This means an automation run doesn’t just show that it came from Event-Driven Ansible, it shows what happened and why. In practice, entries in the automation controller might read as "Detected Malware” or “Red Hat Lightspeed compliance policy violation,” making it easier for teams to understand what drove each automated change without deciphering JSON payloads or event structures.

For highly regulated environments, and for any team building trust in automation, this level of transparency is essential. Security and operations teams can review each automated run with greater confidence, knowing that the platform clearly documents the trigger and intent. Auditors benefit as well, since the automation platform now provides a verifiable chain from detection to action. Over time, this visibility strengthens trust in automation and encourages wider adoption, because engineers can see not just that automation worked, but how and why it worked.

Finally, this integration lays the groundwork for measuring the impact of event-driven automation at scale. Job labels make it possible to group, analyze, and report on event-driven remediation activity, from the types of incidents most frequently automated to the time saved by automated response. As event-driven adoption grows, these insights help organizations quantify automation value, not only in technical efficiency but also in reduced risk and improved operational resilience. In short, Red Hat Lightspeed events paired with labeling by Event-Driven Ansible don’t just enable automation, they make it visible, trustworthy, and measurable.

Why this matters

As automation adoption accelerates, traceability becomes mission-critical. Security, operations, and compliance teams need confidence that automated responses are not only fast, but also observable, auditable, and explainable. With Ansible Automation Platform 2.6 and Red Hat Lightspeed events, every automated action now carries full contextual visibility, from the triggering event to the remediation outcome.

This capability turns automated response into a trusted operational pattern. Security operations center (SOC) and SRE teams can quickly verify why a job ran, what event triggered it, which system was affected, and whether the remediation succeeded. Compliance officers gain an auditable chain from detection, to automated action, to result. Platform engineers gain confidence that automation is behaving predictably and transparently. In short: automation becomes safer, clearer, and easier to scale across the enterprise.

Event-driven automation transforms insight into action, helping close security and compliance gaps faster while strengthening operational resilience. The new job-labeling capability brings a higher level of governance and visibility to that automation, making it easier to adopt event-driven workflows at scale.

Try the example in this article to trigger a job with Red Hat Lightspeed, and then look for the job, labeled by Event-Driven Ansible, in your automation controller. Then you can start building toward secure, explainable, real-time remediation pipelines. This is another step toward an intelligent automation fabric, where every system event becomes an opportunity for immediate, secure, and fully traceable automated response.

Get started with Red Hat Lightspeed-powered Event-Driven Ansible

If you’re ready to explore this pattern further, we’ve published resources to help you move from concept to hands-on execution.

• Blog: Red Hat Lightspeed Collection for Event-Driven Ansible explores why Red Hat created a Red Hat Lightspeed-driven event collection, how events are structured, and what automation scenarios it unlocks.
• Learn: The Event-Driven Ansible web page includes self-paced training resources and frequently asked questions.
• Try it: The redhat.insights_eda collection on Ansible automation hub includes event sources, example rulebooks, and documentation you can use immediately in your own environment.

Together, these resources give you everything you need to start building automated, insight-driven, and fully traceable operations with Red Hat Lightspeed and Ansible Automation Platform.