From compliance failure to Ansible playbook and Git pull request with rConfig MCP

From compliance failure to Ansible playbook and Git pull request with rConfig MCP

rConfig tells you which devices fail a policy. Fixing them is a second, slower project: write the change, test it, get it approved, apply it. An agent can do the first draft. It reads the failures from rConfig, checks the actual config on each device, writes an Ansible playbook, and opens a pull request. People do what they’re best at: reviewing, approving and running it.

Best for: clearing compliance backlogs, repeatable fixes across many devices, teams with infrastructure as code. Tools: rConfig, a Git repository (GitHub’s MCP server or plain git in the agent’s terminal), Ansible. rConfig tools used: get_compliance_status, search_configs, get_latest_config.

How it flows

flowchart LR
    R["rConfig MCP<br/>failing policies + evidence"] --> A["Agent drafts<br/>playbook + inventory"]
    A --> PR["Pull request"]
    PR --> H["Engineer reviews,<br/>runs --check, approves"]
    H --> X["Ansible / AWX / AAP<br/>applies the change"]
    X --> B["rConfig backup"]
    B --> V["Agent re-checks compliance"]

Only the Ansible step changes devices, and a person starts it.

The prompt

In rConfig, find devices in the Branch group that fail the “SSH hardening” policy. For each, use search_configs to confirm what’s actually in the config (ip ssh version, transport input lines on the VTYs). Write an Ansible playbook in remediation/ssh-hardening.yml using the cisco.ios collection that brings them into line, and an inventory of only the affected devices. Make the playbook idempotent and safe to run with —check. Open a pull request titled “SSH hardening for Branch devices” with a description listing each device, what’s wrong, and what the playbook changes. Don’t run anything.

The kind of playbook the agent drafts:

- name: SSH hardening for Branch devices (from rConfig compliance)
  hosts: branch_ssh_failures
  gather_facts: false
  tasks:
    - name: Use SSH version 2
      cisco.ios.ios_config:
        lines:
          - ip ssh version 2

    - name: Allow only SSH on the VTY lines
      cisco.ios.ios_config:
        parents: line vty 0 15
        lines:
          - transport input ssh

Review checklist

The pull request is where people take over:

• Check the evidence. Every device in the inventory should have a matching failure in rConfig and the config line that proves it.
• Dry run first. ansible-playbook --check --diff against the inventory shows what would change, without changing it.
• Watch the edges. VTY ranges, platform differences (IOS against IOS XE, NX-OS) and devices reached only through a jump host are where drafts go wrong.
• Match your change process. Large or risky fixes still need a change request. The pull request description makes a good one.

Close the loop

After the playbook runs, rConfig’s next backup captures the new configs. If the policy assignment has Run on backup turned on (the default since V8.2.1), the policy is evaluated again straight away. Then:

Re-check the SSH hardening policy in rConfig for the devices in remediation/inventory.yml. Which still fail, and why?

Anything still failing goes back into the next pull request.

Limits to know

• Drafts, not decisions. The agent has never logged in to these devices. Its playbook is based on the stored config and the policy result.
• Policy reasons, not rule detail. rConfig’s MCP server reports each policy’s status and reason per device. The agent confirms the details with search_configs, so ask it to show those lines in the pull request.
• Keep Git writes in Git. If you give the agent GitHub’s MCP server, scope its token to the one repository, without permission to merge.

Related reference

• Policy compliance
• Policy Library
• Snippets
• Find devices exposed to a security advisory