Recently, Red Hat's Vincent Danen highlighted how AI models found 271 real security defects in Firefox in a single pass during Mozilla's collaboration with Anthropic. If AI can do that for defenders, it can do the same for attackers. As Danen put it, "if your security strategy is solely predicated on the assumption that software will be vulnerability-free, you've already lost." Vulnerabilities in code are only the entry point. The real damage comes after—lateral movement through misconfigured networks, overprivileged credentials, unrotated secrets, and services that blindly trust each other. No patch cycle can keep up with that. This underscores the need for more "defense in depth" across enterprises—a cultural shift that assumes a compromise will inevitably occur, and focusing on reducing the impact of the exposure itself. This is the definition of zero trust. This first tidal wave of security vulnerabilities has a second and third coming behind it, and organizations need to adopt zero trust to move from pure prevention to containing the breach—enforcing least privilege across identity, secrets, network segmentation, and policy at every layer. Organizations require automated enforcement that executes at the velocity of these AI-driven threats. Red Hat Ansible Automation Platform helps make this possible.The AI attack surface shiftTraditional vulnerability scanners flag potential issues and hand them to a human for triage. AI has commoditized the cyberattack. Today's AI tools are essentially an entire team rolled into one, all at the cost of tokens. While devastating breaches like SolarWinds demanded time, deep expertise, and luck, AI now empowers motivated attackers to effortlessly chain together complex, multiplatform vulnerabilities.These seemingly small weaknesses add up, and not for your benefit. For example:A login page that lets you retry passwords too quicklyA settings page that does not re-check who you areAn API that briefly exposes a session token during logoutNone of these are overly dangerous alone. Individually each would sit in a backlog as "low priority," but chained together, they could let an attacker brute-force a password, hijack the session before it expires, and land inside the settings page as an administrator. Three minor bugs, yet you get a functional break-in.These advanced AI models write, compile, and execute exploit code, using failure outputs to iteratively refine and retry their attacks. While organizations use this to their advantage by finding and fixing previously unknown vulnerabilities at speed, the uncomfortable truth is that this capability is also available to attackers. As Danen wrote, "the same tools that help defenders find bugs will inevitably help attackers find them too." The attacker skill ceiling just dropped. Faster patching is part of the answer, but it must be supplemented by good defenses. Defense needs an automated operational layerRed Hat Enterprise Linux with SELinux and Red Hat OpenShift already provide platform-level hardening, but these platform-level defenses need to be supplemented. For example, SELinux doesn't decide who's allowed to deploy an application. Container isolation doesn't revoke database credentials when a Security Information and Event Management (SIEM) system detects a brute-force attack at 3 AM. These are roles automation can play in creating a good defensive strategy. Operational changes (deployments, patches, network reconfigurations, credential rotations) flow through people, scripts, pipelines, and automation. If those paths aren't gated by policy, then platform hardening protects you from one class of attack while leaving another class wide open. NIST SP 800-207 lays out the Zero Trust Architecture (ZTA) blueprint, and at its center is the Policy Enforcement Point (PEP). Most people think of the PEP as a firewall or a gateway that filters network traffic. But when teams are deploying applications, patching servers, and changing network configurations, those actions don't pass through a firewall, they pass through automation. Ultimately, zero trust is an operational discipline that requires automation to be delivered at scale.Ansible Automation Platform as the Policy Enforcement PointWhen Ansible Automation Platform acts as the PEP, every operational action passes through a platform that checks identity, evaluates policy, manages secrets, and logs the outcome. These aren't advanced capabilities, they're the minimum viable controls that zero trust demands. The operator never touches the target system directly. The Ansible Playbook does this, and the playbook runs only after the platform confirms the operator is authorized.The architectural benefit is centralized enforcement with distributed execution. Policy decisions happen at a single control plane, but enforcement happens wherever the automation runs. There's no direct connection to servers or running scripts from laptops, reducing the risks of "cowboy engineering" and untraceable configuration drift. This also addresses anti-patterns like credential sprawl, shadow automation, or ungoverned lateral movement.This architecture mitigates critical security vulnerabilities by eliminating high-privilege production credentials on vulnerable local endpoints. The automation platform is the single point of control, and every change carries identity, policy approval, and an audit record with it. Ansible Automation Platform can implement this through a dual-ring enforcement model. The outer ring operates at the platform level. Before a job template launches, Ansible Automation Platform consults the Open Policy Agent (OPA) server via the included policy enforcement feature, with the full job context: who's launching it, which team they belong to, and which template they're running.