Tool Annotations and Role Scoping
Every tool InfraScout exposes carries a set of annotations — a short, structured statement of how the tool behaves. Does it only read, or can it change something? Is a change reversible? Does calling it twice do the work twice? These are part of the Model Context Protocol itself, not an InfraScout invention, and any connected client can read them.
InfraScout takes one of those annotations and makes it load-bearing. readOnlyHint decides which tools a caller's role can reach, enforced by the server before any tool runs. That is the difference between telling an AI to be careful and making carelessness impossible.
The Four Annotations
Each tool declares a human-readable title plus four behavioral properties.
readOnlyHint states that the tool does not modify anything. agent_list, inventory_list_software, and every mscloud_* query set it — they gather information and leave the world as they found it.
destructiveHint states that a modification may be irreversible. It applies only to tools that already modify something, and it separates a tool that adds from a tool that overwrites or deletes. agent_exec_shell sets it, because the shell it opens can run rm as easily as ls.
idempotentHint states that repeating the same call with the same arguments has no additional effect. Reads are idempotent almost by definition. Execution tools are not — running a script twice runs it twice.
openWorldHint states that the tool reaches outside InfraScout's own records — onto one of your hosts, or into your Microsoft cloud tenant. A tool that only touches InfraScout's own session and finding records does not set it.
Read together, these describe the risk of a call in a form both the model and the server can act on. agent_exec_powershell_readonly is a good illustration of why the combination matters: it is readOnlyHint: true and not destructive, but it is not idempotent, because a validated read-only script still costs real time on a real host each time it runs.
INFO
The MCP specification calls these hints because a client cannot verify them — a badly behaved server could annotate a destructive tool as read-only. That framing is right for the protocol. It is not how InfraScout treats its own tools: their annotations are declared where each tool is defined and enforced server-side, so the classification and the enforcement cannot drift apart. Annotations arriving from third-party MCP servers are a different matter, covered below.
Role Tiers
Roles are assigned in Entra ID, so there is nothing to configure inside InfraScout. Five roles resolve into two tiers plus administration.
User tier — Users and MCPUser. Read your infrastructure, run assessments, record findings.
Operator tier — Operator, MCPOperator, and Admin. Everything the user tier can do, plus every tool that changes a host.
The MCP variants carry one extra capability: permission to connect an MCP client at all. MCPUser is the user tier plus MCP access; MCPOperator is the operator tier plus MCP access. A plain Users or Operator account works in the portal but cannot connect Claude Desktop. See Users (Admin) for how the roles map to portal capabilities.
How the Boundary Is Enforced
A caller who is not operator tier is confined to tools annotated readOnlyHint. The boundary is applied in two places, and both matter.
The tool list is narrowed. When a client asks what tools are available, a user-tier caller receives only the read-only ones. The AI never sees a tool it cannot use, so it never proposes an action that will fail — the menu it works from is already the menu it is allowed.
Calls are refused before dispatch. A client working from a stale list, or one constructing a call by hand, gets refused at the server. Nothing reaches a host, and nothing is dispatched and then rolled back.
The refusal is deliberately uninformative. A write tool refused by role, a tool hidden by tool-group scoping, and a tool name that was never registered all produce the identical response. Distinguishing them would let anyone with any level of access map the entire tool catalog by probing for which names produce which error. The cost is real — a user-tier caller does not get told "use the read-only version instead" — and it was accepted knowingly.
Both directions fail closed. A caller whose role cannot be resolved is treated as user tier, not as an operator. A tool whose classification cannot be determined is treated as a write tool, not as a read. When InfraScout is unsure, it withholds.
The Assessment Carve-Out
Five tools write, but are available to every tier: starting a session, submitting one for review, and saving, updating, or deleting an insight.
These are the ordinary mechanics of running an assessment. They write only to InfraScout's own tenant-scoped, audited records — never to a host under review, which is why none of them sets openWorldHint. Confining them to operators would mean a standard user could gather evidence but not record what they found, which defeats the point of giving them read access at all.
Everything else that writes stays behind the operator tier.
Three Gates, Not One
Role scoping is one of three independent checks, and a tool call has to clear all of them.
Tool-group scoping decides which groups of tools your Entra security groups can reach at all. It is closed by default and administered per group — see Tool Groups (Admin).
Role tier is the ceiling described on this page. It applies on top of whatever groups you can reach: a broadly shared group containing both read and write tools offers a standard user only its read-only half.
Resource visibility decides which specific agents, groups, and connections you can act on. Also closed by default — see Groups (Admin).
A connected client can hold a slightly stale list
Clients are told a tool list stays good for a minute, so an already-connected client can take up to that long to notice a scoping change an administrator just made. The bound applies only to what a client has been offered. It never applies to what it can run — every call is checked against your live permissions, so a stale list naming a tool you have lost is refused when the client tries to use it.
The practical consequence for administrators is that you do not need a read-only variant of every tool group. Compose a group around a job to be done, mix read and write tools freely, and let the role tier decide who gets which half. When someone genuinely needs to make changes, change their role rather than reshaping the group.
Every Path In
The boundary is enforced by the server, so it does not depend on which client someone uses. Portal chat, delegated runs handed to a Task Agent, scheduled workflows, and a raw MCP client connected straight to the endpoint are all held to the same rule, evaluated the same way.
This is worth stating plainly because it was once not true. Until July 2026, keeping a standard user to read-only work was guidance in the AI's instructions — advice the model generally followed, but could cross, and which applied only inside InfraScout's own chat. A user pointing a raw MCP client at the server was outside it entirely. That gap is closed; the instructions remain as an additional layer, but they are no longer what stands between a standard user and a state-changing tool.
Third-Party Tools and the Trust Question
Tools from registered third-party MCP servers arrive with whatever annotations their server chose to publish, and those annotations are the server's own claim about itself.
InfraScout trusts them in the restrictive direction only. A tool a server declares read-only is treated as read-only. A tool that declares nothing is treated as a tool that writes, so it stays behind the operator tier by default. A server cannot widen its own reach by staying quiet.
That default is stricter than it may sound in practice. Across 591 discovered third-party tools, exactly one server declared annotations at all — so administrators can override the classification per tool from the server's detail view, which is how a genuinely read-only tool from a silent server becomes available to standard users. Overriding is an explicit act by an administrator who knows the server, which is precisely the point.
WARNING
An override is a statement that you have verified what the tool does. Marking a third-party tool read-only makes it reachable by every user-tier caller in your tenant, and InfraScout has no way to check the claim against the server's actual behavior.
What Annotations Do Not Do
Annotations classify behavior. They do not grant permission, and they are not a substitute for the audit trail.
A read-only tool is still a tool that reads your infrastructure, and reading can disclose plenty. readOnlyHint bounds what a caller can change, not what they can see — that is resource visibility's job, and it is a separate gate for exactly this reason.
Every call also lands in Executions regardless of tier, attributed to the person whose identity it ran under. Because InfraScout authenticates through Entra ID and never uses a shared credential, an action is always traceable to whoever authorized it.
See Also
Understanding MCP
What the protocol is, what a server exposes through it, and where annotations fit in the wider picture.
Security Architecture
The full trust model — agent transport, sign-in, visibility, encryption, and the audit trail behind every finding.