Iris data flow map: what leaves rConfig, where it goes, and what's kept

Iris data flow map: what leaves rConfig, where it goes, and what’s kept

Every security review of AI starts with the same question: what data goes where? Iris has two outbound paths, and they’re governed differently. This page draws both. The authoritative per-feature detail, with sizes, is on the governance page; this page shows how it fits together.

The two paths

flowchart LR
    subgraph rc["rConfig server"]
        F["Iris features<br/>analysis, drift, compliance,<br/>rule drafting, optimisation"]
        MCP["MCP server<br/>read-only, role-scoped"]
        AT[("AI audit trail<br/>metadata only")]
        AL[("Application log<br/>MCP tool calls")]
        F --> AT
        MCP --> AL
    end
    F -- "Path 1: request<br/>secrets obfuscated" --> P["Your configured AI provider<br/>cloud, Azure tenant or on-site"]
    A["Agent<br/>Claude Code, Cursor, Codex, n8n"] -- "Path 2: tool calls<br/>with a token" --> MCP
    A -- "tool results go to<br/>the agent's model" --> AM["Agent's model provider"]

	Path 1: Iris features	Path 2: agents over MCP
Started by	A user clicking in rConfig	An agent with an MCP token
Data leaves to	The provider configured in rConfig	The agent, then the agent’s model provider
Who chooses the destination	rConfig administrators	Whoever runs the agent
Scope	What the user can see in rConfig	What the token owner’s role can see
Recorded in	AI audit trail	Application log

Path 1: what each feature sends

Feature	Config text sent?	Other data
Config analysis	Yes, on the first chat message (up to about 100,000 characters)	Your question, config metadata
Drift narration	Diff (up to 8,000 characters) and the start of the current config	Device name, trigger, severity
Compliance narration	No	Device and policy names, results, reasons
AI Generate Rules	Only a config you paste in (up to 8 KB, credentials redacted)	Policy name and description
Optimisation assistant	No	Your question, conversation, documentation passages

Every feature except the optimisation assistant also sends the context harness: rConfig’s built-in knowledge and your team’s entries. Write team entries as if they’ll be read by your provider, because they will.

The provider’s classification on rConfig’s Privacy tab tells you where Path 1 ends: On-Premises (configs stay on your network), Cloud Provider, or External API Endpoint. See Choosing a provider.

Path 2: what agents can read

An agent with an MCP token can read devices, configs, history, diffs and compliance results, limited to the token owner’s role, with secrets obfuscated. What happens next is up to the agent: its results go to whatever model it uses. rConfig’s provider setting doesn’t apply.

The controls on this path are the token and the role. See Access and least privilege.

What rConfig keeps

Kept	Where	Contains
AI audit trail	`ai_audit_logs` table	User, IP, feature, conversation ID, provider, model, token counts, time
MCP tool calls	Application log	Tool, outcome, device ID; not the arguments
Chat conversations	Per user, per config	Visible only to that user
Narrations and one-off answers	Not kept	Copy them if you need them

Frequently asked questions

Does rConfig send device configs to an AI provider?

Only from features that need them, and only to the provider you configure. Config analysis sends the config; drift narration sends the diff and the start of the config; compliance narration sends policy results and no config. Secrets are obfuscated first.

Does rConfig store AI prompts or answers?

No. The audit trail records who, which feature, which model and how many tokens, never prompt or answer text. Chat conversations are kept per user so they can return to them.

Where do MCP agents send rConfig data?

To the agent's own model provider, not rConfig's. rConfig controls what the agent can read through the token owner's role; the agent's vendor terms govern what happens next.