Red Hat opens Ansible to AI agents, within limits

Red Hat on Tuesday opened its Ansible Automation Platform to AI agents while adding new controls intended to keep them under tight control. The company made its Model Context Protocol (MCP) server for Ansible generally available, allowing any AI tool to access the platform, and it introduced a new automation orchestrator, in technology preview, that routes actions through human-approved, deterministic playbooks.

The goal is to allow enterprises to start using AI to automate their workflows while keeping a firm hand on what the AI agents can and can’t do with it, since there have recently been a series of reports about AI agents performing unauthorized actions.

AAP will now also support more models, in addition to IBM’s WatsonX Code Assistant. Supported models include those from Google, Anthropic, OpenAI and any other leading models that are OpenAI API-compatible, says Sathish Balakrishnan, vice president and general manager of the Ansible business unit at Red Hat. Enterprise will also be able to provide their own background information, in the form of RAG embedding, to AAP.

“Customers have a lot of contextual knowledge,” Balakrishnan tells Network World. “These are our policies, this is when we update machines — they have rules they have written about IT infrastructure. We can now start reading all of those things.”

But the new AI functionality will operate within tight guardrails, he says. “AI is unpredictable,” he adds. “When you suddenly put AI into your production environment and ask it to change it, you’ve seen the articles about how a company lost its database.”

Instead, the AI will rely on pre-made, tested, approved playbooks for creating the automations that users request, he says. “And if AI does something new, then you need to put a human in the loop,” he tells Network World. “They have to verify that those actions that AI recommends are the right actions.”

The playbooks are not only testable, repeatable, and deterministic, but they’re also much less expensive than having to call an LLM during the actual execution of an automation.

“Why would you use AI just to patch a machine?” he says. “We all know tokens are expensive. We know the best way to patch a machine — why call an AI to do that when you already have a playbook that’s been in use for ten years?”

The MCP access, which allows external AI agents to connect to Ansible, is new and risky, confirms Paul Nashawaty, an analyst at Efficiently Connected.

“The security concerns are very real,” he tells Network World. “If those agents are connected to highly privileged automation systems, the blast radius can become enormous, including accidental production outages or destructive actions.”

Today, the strongest use cases for AI are AI-assisted troubleshooting, compliance remediation, developer self-service, and human-approved workflow execution, he says. “Companies should avoid giving AI unrestricted production access, broad admin privileges, or autonomous control over critical systems,” he says.

With the new AI features, that means we’ll see developers asking for environments in natural language, he says, or AI systems automatically correlating alerts and suggesting fixes. “Or operations teams reducing incident response times by having AI assemble and execute approved remediation steps.”

IDC analyst Jevin Jensen says that he’s been waiting for vendors to provide natural-language front ends for their platforms for the past 18 months. “This really broadens the use and value of the platform to new users and improves efficiency of existing users,” he says.

The key is to have good governance in place in order to reduce risk, he adds. “It is important — with or without MCP — that enterprises properly utilize and leverage role-based access control,” he says.

The benefit is that enterprises will be able to create automation playbooks more quickly. “IDC recommends starting with the development environment or a less impactful cloud area first,” he says.

In other Ansible-related news today, administrators will now be able to delegate the ability to trigger automations to end users. For example, factory floor managers can trigger updates at a point where they’ll create the least interference with the manufacturing schedule. And Red Hat is also now allowing multiple events to trigger the same automation playbook, instead of having to have a separate playbook for each event.