Access and least privilege for Iris: permissions, roles and MCP tokens

Iris inherits rConfig’s access model: a person or an agent sees only what their role allows. That’s a strong foundation, and it’s also why the details matter. An agent holding the wrong token sees the wrong devices. This page sets out the controls and how to use them.

The controls

Control	Governs	Notes
`AI_CENTER_ENABLED` in `.env`	Whether the AI Center exists on this server	Off by default
`aicenter.view`	Using Iris features, seeing the AI Center, listing your own MCP tokens	In every role template
`aicenter.mcptoken`	Creating and revoking your own MCP tokens, without AI settings rights	Give it to engineers who connect agents
`aicenter.update`	Providers, capability switches, team knowledge, and other users’ MCP tokens (see, revoke, create for users you manage)	Admins have it
Capability switches	Turning each Iris feature on or off for everyone	AI Configuration tab
Device access (roles)	Which devices Iris features and MCP tools can see	Direct device assignment or tag-scoped roles
Terms acceptance	Each user accepts the AI Center terms before using it	Recorded with time and IP

MCP tokens: how they behave

A token belongs to one user and sees exactly what that user’s role sees.
Creating your own token needs aicenter.mcptoken (or aicenter.update).
Admins can create tokens for other users. With aicenter.update, pick the user under Token for. Only users you’re allowed to manage are offered: everyone for an Admin, otherwise users whose role ranks below yours.
Tokens work only on /mcp. They’re rejected by the rest of rConfig’s API, so they can’t change settings or mint new tokens.
Tokens expire. A new token lasts a year unless you choose 30 or 90 days, a custom date, or No expiry.
Creating and revoking is logged. The activity log records who did it, whose token it was, its name and its expiry.

Patterns

Engineers use their own tokens. Each engineer’s agent then sees exactly what the engineer sees in rConfig. Give their role aicenter.mcptoken so they can create tokens without AI Center admin rights.

Automation uses service users. One rConfig user per automation (digest, n8n workflow, ChatOps bot), with a role scoped to the devices it needs. An admin creates the token for that user and hands it over. Disabling that user or revoking its token stops the automation without touching anyone else.

Scope by tag. Tag the devices a team or automation may see, and give its role that tag. A device is visible if any of its tags, or a direct assignment, links it to the role, so check cross-cutting tags (like firewalls) don’t widen access by accident.

Token hygiene

Store tokens as secrets: environment variables or a secret store, never committed to a repository. Client configs can reference variables (Claude Code, Cursor, Codex and VS Code all support this).
Name tokens for their use (“claude-code-jdoe-laptop”, “n8n-change-digest”), so the MCP Server tab tells you what to revoke.
Set an expiry. Keep the one-year default, or shorter for tokens on laptops. Reserve No expiry for automations you review.
Review quarterly. Admins see the tokens of every user they manage on the MCP Server tab, with an Owner and Expires column. Revoke tokens for people who’ve left or automations you’ve retired.
Watch the application log. Every MCP tool call is recorded with the tool, outcome and device. Unexpected tools or devices for a token are worth a look.

Frequently asked questions

Who can create MCP tokens in rConfig?

Users whose role has aicenter.mcptoken create their own, and admins with aicenter.update can also create them for users they manage. A token sees what its owner's role can see.

Do MCP tokens expire?

Yes: a year by default, or a date you choose. No expiry is an explicit option.

How do I give an automation narrow access?

Create a dedicated rConfig user with a role scoped to the devices the automation needs, for example by tag. An admin creates the MCP token for that user from the MCP Server tab without signing in as them.