Read-only by design: what Iris and rConfig’s MCP server can and can’t change
AI in network operations raises one question before any other: can it break something? In rConfig the answer is built into the product, not left to a prompt. Iris reads and explains. It doesn’t change devices, stored configs or rConfig settings, and the MCP server that outside agents use has no tools that could.
What each path can do
| Path | Reads | Writes |
|---|---|---|
| Config analysis | The config you’re viewing | Nothing. Chat history is saved for you |
| Drift narration | The diff and the start of the config | Nothing |
| Compliance narration | Policy results (no config) | Nothing |
| AI Generate Rules | Policy name and description, plus a config you paste in | A draft in the policy editor, saved only when you click save |
| Optimisation assistant | rConfig documentation | Nothing |
| MCP server | Devices, configs, history, diffs, compliance, within the token owner’s role | Nothing. All eight tools are read-only and flagged as such to clients |
The layers that keep it that way
- No write tools exist. The MCP server has eight tools, all reads. There’s nothing for an agent to call that could change a device, however it’s prompted. Each tool is also marked read-only in its MCP metadata, so clients like Codex can let them run without approval prompts.
- No AI code path writes to devices. Iris’s features return text to your screen. Drift narration’s instructions also tell the model not to propose pushing changes.
- MCP tokens only work on
/mcp. rConfig accepts an MCP token on the MCP endpoint and rejects it everywhere else. A leaked token can read what its owner can read, and can’t touch the REST API, create tokens or change settings. - Results follow roles. Every MCP result is limited to the devices the token owner can see under Roles.
- Secrets are obfuscated before configs leave rConfig, on every AI path.
The one write, and why it’s safe
AI Generate Rules drafts policy rules in the policy definition editor. rConfig asks before replacing the editor content, the rules land as an unsaved draft, and nothing reaches the policy store until a person saves it. Even then, a policy only evaluates configs. It never changes a device. See Drafting policies with AI.
Where changes do happen
Read-only doesn’t mean AI can’t help with changes. It means the change is applied by a person, through tools built for it:
- An agent drafts an Ansible playbook in a pull request: remediation as code.
- Batfish tests the proposed change before it’s applied: Batfish pre-change validation.
- After the change, rConfig’s diff proves what was applied: change window verification.
Related reference
Frequently asked questions
Can rConfig's AI push a change to a network device?
No. No AI feature in rConfig writes to a device or a stored config, and the MCP server has only read-only tools. Changes always go through a person and your own change process.
What is the one thing Iris can write?
A draft policy definition. AI Generate Rules puts generated rules in the policy editor, and nothing is saved until a user clicks save. It never touches a device.
Can an MCP token be used against rConfig's REST API?
No. rConfig accepts MCP tokens only on the /mcp endpoint. Presented anywhere else, they're rejected, so a leaked MCP token can't be used to change rConfig or mint new tokens.