Build a network audit evidence pack from rConfig compliance with an AI agent
Audit season means screenshots, exports and spreadsheets: which devices are in scope, which pass, which fail and why, and what you’re doing about it. rConfig already has the answers as policy compliance results. An agent can collect them over MCP and draft the pack in the format your auditors expect, in an afternoon instead of a fortnight.
Best for: internal and external audits, quarterly control evidence, answering auditor follow-up questions quickly.
Tools: rConfig. Optional: Atlassian’s MCP server for Confluence or Jira.
rConfig tools used: get_compliance_status, get_devices, search_configs, get_latest_config.
What goes in the pack
| Section | Comes from |
|---|---|
| Scope: devices and groups covered | get_devices filtered by group or tag |
| Results summary per group | get_compliance_status for each group: compliant, non-compliant, not evaluated, percentage |
| Failing policies per device, in plain English | get_compliance_status per device: each policy with its status, reason and evaluation time |
| Evidence lines from the config | search_configs for the settings each failing policy checks |
| Not evaluated, and why | Devices with no backup for the command the policy checks |
| Remediation status | Your tickets, if an ITSM server is connected |
The prompt
Build a compliance evidence pack for the PCI-scoped devices in rConfig (tag
pci).
- Scope: list the devices with group, model and last backup time.
- For each group, give the compliance summary.
- For each non-compliant device, list the failing policies with the reason rConfig recorded, explain each in one sentence, and quote the relevant config lines.
- List devices that weren’t evaluated and say why. Write it as a Confluence page in the AUDIT space titled “Network compliance evidence, Q4”. Don’t include passwords or keys even if they appear obfuscated.
Wording that holds up in an audit
- Evidence, not certification. rConfig policies show what was checked and found. Say “maps to” a control, never “compliant with” a framework. The Policy Library frameworks page follows the same rule.
- Date everything. Each result should carry the backup time it was evaluated against. Auditors ask “as of when?”
- Explain “not evaluated”. It usually means no stored config for the command the policy checks. That’s a gap to close, not a pass.
Limits to know
- The pack is only as good as the policies. If a control has no rConfig policy behind it, the agent can’t produce evidence for it. List those controls as manual.
- Large estates: run the pack group by group, and use
search_configsfor evidence lines rather than full configs. - Review before sending. The agent drafts; an engineer checks every explanation against the policy definition.
Related reference
Frequently asked questions
Can an AI agent prepare network compliance evidence for an audit?
It can gather and organise it. Connected to rConfig over MCP, the agent collects compliance status per group, failing policies with the reason rConfig recorded, and the config lines behind them, and drafts the pack. An engineer reviews it before it goes to the auditor.
Does this make my network compliant with PCI DSS, NIST or CIS?
No. rConfig policies provide evidence towards controls; they don't certify compliance. The pack shows what your policies check and what they found.
Where should the pack go?
Wherever your audit team works: a Confluence page through Atlassian's MCP server, a Jira issue, or a document the agent writes locally. Keep it in a restricted space, since it contains configuration excerpts.