The risk of ungoverned automation
As automation adoption grows across your organization, so does the risk of fragmentation. Without a centralized platform, teams develop their own playbooks, roles, and workflows independently and with different standards. The result is rogue automation, where there are scripts and jobs running in production that no one fully understands, no one explicitly approved, and no one is accountable for maintaining. In addition, these organizations experience:
- Isolated, disconnected automation adoption. At Red Hat, we typically see organizations that use free automation achieve limited results. When different teams use different versions of Ansible core, different collections, and different execution environments, the operational efficiencies from automation are lost. Users or teams might see small benefits, but that automation rarely produces the kind of results that enterprises expect. Automation content is meant to be shared and reused, not just for consistency but for scalability.
- Limited audit and reporting depth. AWX logs job execution and user activity, but lacks enterprise log aggregation, SIEM (security information and event manager) integration, long-term retention policies, and audit-ready reporting. For organizations that need to demonstrate controls to auditors or correlate automation events with security incidents, the gap between "logs exist" and "audit-ready" requires additional custom engineering.
- Unsecured automation supply chain. Community-based content contributions vary in quality and reliability. Collections from Galaxy are community-maintained. Policies are typically not enforced at runtime so automation jobs that bypass governance and controls are not discovered until later.
Maintaining security in the AI-era
The threat landscape for enterprises is changing rapidly. Attackers can now use frontier AI models to exploit vulnerable systems faster than information technology operations (ITOps) and security operations (SecOps) teams can respond. In this dynamic environment, the security posture of your organization’s automation tooling matters now more than ever.
Upstream Ansible projects, including AWX, are not tested and hardened for production, enterprise environments. Common vulnerabilities and exposures (CVE) response service-level agreements (SLAs) don't exist. When a vulnerability is discovered, your team is responsible for identifying it, assessing exposure, developing a fix, testing, and deploying, all while attackers may already be scanning for unpatched systems. Enforcing a secure automation supply chain is impractical.
The operational burden of building, maintaining, and safeguarding automation
AWX provides a UI and REST API on top of Ansible core. It's a capable tool for teams willing to invest in operating it. However, to successfully run AWX in production, your team must:
- Compile and package the software for your environment, including dependencies and container images.
- Secure your automation deployment including authentication, secrets management, and transport layer security (TLS) configuration.
- Integrate with existing systems including your configuration management database (CMDB), IT service management (ITSM), and observability solutions.
- Operationalize and reinforce with backup, recovery, high availability, and upgrade procedures.
- Support end users when things break or affect production systems.
- Maintain and upgrade the platform through releases, CVEs, and dependency updates.
For organizations with dedicated DevOps or site reliability engineering (SRE) teams and the capacity to treat AWX as an internal product, it can be done. However, a dedicated focus on maintaining the platform alone can cost your IT team practical hours that could be redirected towards engineering, innovation, and transformational projects.
Addressing compliance concerns
Highly regulated industries such as finance, healthcare, and government require proof-centric controls over automated processes. Auditors ask:
- Who has access to which systems?
- What changes were made, when, and by whom?
- How are credentials stored and rotated?
- Is automation content reviewed and approved before execution?
- How are vulnerabilities identified and remediated?
AWX provides basic RBAC and job logging, but was not designed with compliance frameworks in mind. It does not include built-in policy enforcement, human-in-the-loop approval workflows, or integration with governance tooling. Meeting audit requirements usually means a custom build. For organizations subject to System and Organization Controls (SOC) 2, Payment Card Industry Data Security Standard (PCI-DSS), Health Insurance Portability and Accountability Act (HIPAA), Federal Risk and Authorization Management Program (FedRAMP), or similar frameworks, the gap between AWX capabilities and compliance requirements brings tangible risk and cost.
Calculating the hidden costs
To truly understand the cost of automation, organizations needs to assess:
Engineering: How much time is spent building, maintaining, and troubleshooting your automation? How could those resource hours be reallocated to revenue generating projects?
Security: How are teams responding to unpatched AWX vulnerabilities? What is the process to test and validate content? How are credentials managed?
Compliance: How much time is dedicated to preparing for audits? How are CVEs currently handled and has your current process negatively affected audits?
Operational inefficiencies: How much time is spent on supporting users when issues occur? How much time occurs between upgrades?
Innovation: Is automation causing friction between teams? Is automation adoption slow with inconsistent practices and limited scale?
As you can see, organizations that believe they are making a choice purely based on cost may not be saving money at all and have taken on unnecessary risk. In fact, they may be investing more in automation because of the time and operational resources devoted to maintaining a mission-critical solution within their IT environment.
