Skip to content
Guides & References

Reference design: Iris and AI agents for MSPs on rConfig Vector

How an MSP on rConfig Vector gives engineers AI agents over MCP without crossing customer boundaries: tag-scoped roles, own tokens, provider choice.

Iris: AI CenterReference designUpdated
On this page

Reference design: Iris and AI agents for MSPs on rConfig Vector

An MSP’s rConfig holds every customer’s configurations in one place. That’s what makes it efficient, and it’s also why AI needs care: an agent with broad access can read any customer’s configs and send them to its model. This design keeps every AI path inside customer boundaries using controls rConfig already has.

What it looks like

flowchart LR
    subgraph c1["Customer A sites"]
        VA["Vector Agent"]
    end
    subgraph c2["Customer B sites"]
        VB["Vector Agent"]
    end
    VA --> VS["Vector Server<br/>(rConfig + Iris)"]
    VB --> VS
    E1["Engineer, team A<br/>role: tag customer-a"] -- "MCP token" --> VS
    E2["Engineer, team B<br/>role: tag customer-b"] -- "MCP token" --> VS
    W["Automation<br/>service user per customer"] -- "MCP token" --> VS

The controls

Control How Effect
Tag per customer Tag every device with its customer The unit everything else is scoped by
Tag-scoped roles One role per customer or customer group, scoped to their tags (tag-scoped roles) Engineers see only their customers’ devices, in the UI and over MCP
Own tokens Engineers create their own MCP tokens (aicenter.mcptoken) A token sees what its owner sees, no more
Service user per customer One automation user per customer, scoped to that customer’s tag; an admin creates its token under Token for A per-customer digest or workflow can’t touch other customers
Activity log Every MCP tool call is logged with tool, outcome and device Evidence for customer audits that access stayed in scope

A user sees a device if any of the device’s tags, or a direct device role assignment, links it to one of their roles. So a shared, cross-customer tag (say, firewalls) linked to a broad role exposes every customer’s firewalls to that role. Keep customer tags and cross-customer tags on separate roles, and check what a role can see before handing out tokens for it.

The Iris provider is server-wide

Iris’s features use one provider for the whole rConfig server. On a shared Vector Server, every customer’s configs analysed through Iris go to that provider. Options when customers’ AI policies differ:

  • Pick a provider every customer accepts, often a self-hosted model or Azure OpenAI in a region they’ve approved.
  • Turn Iris features off and offer AI only through agents, where each engineer’s agent and token can follow the customer’s rules.
  • Separate Vector Servers for customers with strict requirements, as in the multi-country design.

Agents and customer rules

Some customers forbid their configs going to any cloud AI. Record that per customer (a tag such as no-cloud-ai works), and make sure engineers who use cloud agents don’t hold roles that include those devices. The split design describes the same pattern for a single organisation.

Frequently asked questions

How do I stop an AI agent seeing other customers' configs?

Tag each customer's devices and give engineers roles scoped to their customers' tags. An MCP token only sees the devices its owner's role allows, so the agent can't read other customers' configs.

Can different customers use different AI providers?

Not on one rConfig server: the Iris provider is a server-wide setting. Customers with stricter AI rules need Iris features turned off, a provider that satisfies everyone, or their own Vector Server.

Should customers get MCP access themselves?

Only with care. A customer user with a role scoped to their own tag sees only their devices, but the MCP server returns full configs, so treat it like giving them rConfig access.

Type to search.