Last week was a busy one for anyone thinking about AI agents in operations. Red Hat made its MCP gateway for OpenShift generally available, ServiceNow and Descope both announced ways to put identity and runtime policy around agents, and in the middle of it all, five CVEs landed against MCP software in a single week. Two of them were in the official Python SDK.

Meanwhile, the MCP server for Ansible Automation Platform has been fully supported since June, and with AAP 2.7 rolling out I am hearing the same question from several teams: should we let an agent run our automation? My answer is yes, eventually, but not by pasting a personal API token into a chat client on a Friday afternoon. Here is the order I would do it in.

1. Start read-only, and stay there longer than feels necessary

The AAP MCP server has a server-wide switch, mcp_allow_write_operations, and it defaults to false. Leave it there for the first few weeks. In read-only mode the switch wins over whatever the token’s user is allowed to do, so the agent can look at jobs, inventories and logs but cannot launch anything.

That sounds limiting, but read-only is where most of the early value is anyway. Some things an agent does well without touching a single host:

  • Explain why last night’s patch job failed on four hosts and what those four have in common.
  • List which hosts have not had a successful backup job in the last seven days.
  • Summarise which schedules run over the weekend and who owns each template.

Use this period to learn how the agent behaves with your data. You will find out quickly whether your job names, descriptions and inventory groups make sense to someone who has never seen them before. If the agent is confused, a new colleague would be too.

2. Give the agent its own identity

The MCP server authenticates to the automation controller with the API token you hand it, and the agent inherits that user’s permissions. So the most important decision is whose token it is.

It should not be yours. Create a dedicated account per agent or per use case, named so nobody can mistake it for a person, for example svc-agent-patching. If your platform authenticates against IdM or another directory, create the account there and map it to an AAP team through a group, the same way you would for a human. Then you get the same lifecycle: an owner, a review date, and a single place to disable it.

At a large bank client, the first question from the security team was not whether the agent could do the job. It was whose name would show up in the activity stream when it did. A shared or personal token makes that question impossible to answer honestly. A named service account answers it in one line.

3. Expose only the toolsets you need

The MCP server groups its tools into toolsets: job management, inventory management, system monitoring, user management, security and compliance, platform configuration and content discovery. You can connect to everything at once, use the discover endpoint, or connect to one toolset per endpoint.

For an operations agent, pick the per-toolset endpoints and start with two: job management and system monitoring. User management, security and compliance, and platform configuration have no business in an operational agent’s client config. RBAC should stop misuse anyway, but there is no reason to show a model tools it should never call. A minimal client config looks something like this:

{
  "mcpServers": {
    "aap-jobs": {
      "type": "http",
      "url": "https://aap.example.com:8448/mcp/job_management",
      "headers": { "Authorization": "Bearer ${env:AAP_AGENT_TOKEN}" }
    },
    "aap-monitor": {
      "type": "http",
      "url": "https://aap.example.com:8448/mcp/system_monitoring",
      "headers": { "Authorization": "Bearer ${env:AAP_AGENT_TOKEN}" }
    }
  }
}

4. When you enable writes, make the agent ask first

Once you trust the read-only behaviour, turning on writes does not have to mean the agent can change production on its own. AAP already has the building blocks for a human in the loop. You just have to use them deliberately.

  • Workflows, not raw templates. Give the agent’s account Execute on a short list of workflow job templates and nothing else. No Admin role, no project or inventory edit rights.
  • An approval node up front. Put an approval node at the start of each of those workflows, and give the Approve role to a human team, not to the agent’s account. The agent can propose and launch. The run waits until a person says yes.
  • Surveys with fixed choices. Use multiple-choice survey questions for things like environment or host group, so the agent picks from a list instead of writing free text into extra vars.
  • No ad hoc commands. Do not grant the ad hoc role on any inventory. If something is worth running, it is worth a job template with a name and an owner.

A good first write use case is the boring kind. Say the nightly backup job failed on two database hosts. The agent reads the log, sees a full disk on the backup target, and offers to run the cleanup workflow followed by a backup rerun limited to those two hosts. The workflow pauses, the on-call engineer reads the agent’s summary, approves, and the result is in the job history with both names attached: the agent that asked and the person who approved.

5. Keep secrets where the masking works

Everything a tool call returns ends up in the model’s context, and if your client uses a hosted model, it leaves your network. The AAP API masks passwords, keys and tokens stored in the credential system before the MCP server ever sees them. It does not mask secrets you have put somewhere else.

Red Hat’s documentation lists the fields that are not protected: host and group variables, extra vars on templates, job output, survey answers and workflow prompts. If you have ever printed a connection string in a debug task or kept an API key in group vars “temporarily”, now is the time to clean that up. Hostnames and IP addresses will also be visible, so check that this is acceptable under your data policies before you connect an external model at all.

6. Watch what it does

Because the agent has its own account, its activity is easy to filter. Forward the activity stream and job events to your log platform and build a simple view per agent account: jobs launched, jobs approved, jobs denied, failures. Add a couple of alerts that would surprise you if they fired, such as launches by an agent account outside the hours it is supposed to work, or a sudden burst of read calls against inventories it normally never touches.

If you put an MCP gateway in front of your servers, use its logs too. Red Hat’s newly GA gateway writes an audit entry per tool call with the calling user, the tool and the result, and it exposes Prometheus metrics for the backend connections. That gives you a second, independent record of what the agent tried, including calls that never reached AAP.

7. Patch the MCP layer like any other exposed service

Last week’s CVEs are a good reminder that MCP servers, SDKs and gateways are ordinary software with ordinary bugs. The Python SDK issues allowed unauthenticated clients to exhaust memory, and a separate advisory showed that bearer token audience checks were not enforced unless you turned them on. A third-party MCP gateway shipped an OAuth flaw that handed out tokens without authenticating anyone.

Put every MCP component in your normal vulnerability scanning and patch process, keep them off the internet unless there is a strong reason, and be careful about which third-party MCP servers your users connect their clients to. An agent with a token to your automation platform should not also be talking to a random server someone found on GitHub.

A short checklist

  • MCP server deployed with writes off, and left that way for a few weeks.
  • One named service account per agent, owned by a person and managed in your directory.
  • Per-toolset endpoints, starting with job management and system monitoring.
  • Writes only through workflows with an approval node and fixed survey choices.
  • No secrets in variables, extra vars or job output.
  • Activity per agent account visible in your logs, with a few alerts.
  • MCP components in the same patch cycle as the rest of the platform.

None of this is new thinking. It is the same least privilege, named accounts and change approval we already expect from people. The agent just makes it obvious which of those habits were real and which only existed on paper.

Resources