Role-Scoped MCP Tool Access
July 14, 2026 · InfraScout Team
Who can run which tools now depends on who is asking. As of this release, standard user-tier callers are confined to read-only tools, while operator-tier callers — your admins and operators — keep the full tool set. This makes least-privilege the default: an ordinary user can inventory hosts, pull configuration, and review findings, but the tools that would change something are simply out of reach.
The important part is where the boundary lives. It is enforced by InfraScout itself, on every path a caller can take — not just the web chat, but any Model Context Protocol client connecting directly.
From an advisory hint to an enforced boundary
Until now, keeping a standard user to read-only work was a matter of instruction. The AI was told to stay within read-only tools, and it generally did — but that was guidance the model chose to follow, not a wall it could not cross. It also only applied inside the InfraScout chat experience. A user pointing a raw MCP client straight at the server was outside that advice entirely.
That gap is closed. The read-only boundary for user-tier callers is now applied by the server, before any tool runs, regardless of how the caller connects. The guidance the AI receives is still there as an extra layer, but it is no longer what stands between a standard user and a state-changing tool. The enforcement does.
User tier and operator tier
Roles come from your Entra ID sign-in, so nothing new to configure. Members of your operator and admin roles are treated as operator-tier and keep every tool available to them, exactly as before. Everyone else is user-tier and works within the read-only set.
For a user-tier caller, the change is a strict reduction: fewer tools are reachable, and the ones removed are precisely those that could alter a host. Operators and admins see no change at all. The tier is decided server-side from your identity, not chosen by the client, so a caller cannot elect into a higher tier by asking differently.
Two ways refusal shows up
What a read-only caller experiences depends on how they connect, but the outcome is the same either way.
In a connected MCP client, write tools do not appear in the offered tool list at all. The client only ever sees the tools it is allowed to use, so a read-only caller works from a read-only menu and never has the option to reach for something it cannot run.
If a call for a non-permitted tool is made anyway — a client working from a stale list, or one crafting a request by hand — the server refuses it before it runs. Nothing reaches a host. The boundary is fail-closed by design: when in doubt about a caller or a request, InfraScout treats it as read-only rather than letting it through.
Assessment sessions and findings still work normally for everyone. Starting a session, recording findings, and updating their status remain available to user-tier callers, because that is the ordinary work of running an assessment and none of it touches a host. What changes is only the ability to alter the systems under review.
Safer delegation
The practical value is confident delegation. You can hand a standard user — or an AI client acting on their behalf — access to run assessments, knowing the server itself keeps that access read-only. There is no prompt to get exactly right, no chat-only assumption to rely on, and no separate posture for direct MCP clients versus the web experience. Read-only means read-only, on every path in.
Operators retain the full toolset for the work that genuinely needs it, and every action any tier takes is still recorded, so a change is always attributable to the person who authorized it.
Questions or feedback? Reach us at info@infrascout.cloud.