"We run it read-only" has become the standard reassurance whenever someone asks about an agent connected to a cloud estate. It is a good answer to one question: can the agent change anything? It is a poor answer to the others. Can it read things it should not? Where does what it reads go? And what would have to be true before anyone lets it do more?
Microsoft's guidance for Azure MCP Server 3.0 is to start with --read-only, a development subscription and a least-privilege identity. Part 1 endorsed that. This part explains why read-only should be treated as the first layer of an architecture, with its own threat model, rather than as a governance programme that is finished once the flag is set.
Ask your cloud a question made the case for what a read-only operations agent is useful for. Here the focus is what it can still get wrong.
What a read can still do
Reading is not harmless. Four things can go wrong without a single resource changing. Two of them, sensitive reads and runaway query costs, are covered in detail in the read-only operations agent article, so they get one line each here.
A sensitive read. Configuration, tags and above all log query results return whatever someone wrote into them, including customer identifiers and, in bad cases, secrets.
A read that leaves. Whatever the tool returns goes into the model's context. If the model is hosted by a provider, the content leaves your boundary for processing, subject to that provider's terms and region. It may also be written to the client's conversation history, to a trace store or to a shared chat. A read-only tool can be the first step of an exfiltration path that nobody designed.
A read that instructs. Returned content is untrusted input. A resource tag, a log line or a description field can contain text written to look like an instruction. MCP is a context boundary covers this: the danger rises sharply once the same agent also holds a tool that can send, write or post.
A read that costs. An agent that retries a broad log query in a loop can produce a bill and a throttling incident on its own.
The two in the middle are the ones teams tend to miss, because neither shows up in the cloud's own logs as anything other than a successful read.
Read-only mode, read-only identity and read-only data are different things
Three separate controls get described with the same word.
| Control | Enforced by | Protects against |
|---|---|---|
| Read-only server mode | The MCP server's tool exposure | The agent calling a tool that changes resources |
| Read-only identity | Azure role assignments | Any call, from any client, changing resources |
| Bounded read scope | Which subscriptions, resource groups and workspaces the identity can see | Sensitive reads in places the workflow never needed |
The first is convenient and easy to switch off. The second is the real boundary for changes. The third is the one most teams skip, and it is the one that decides what can leak. A read-only identity with Reader at management-group level can read the entire estate.
A practical rule: the identity's read scope should match the workflow, not the organisation. An agent that helps with Advisor recommendations for one application's resource groups does not need to read the security team's workspace.
Two details make the distinction concrete. First, what counts as read-only in server mode is a classification the server's maintainers make, tool by tool. Microsoft's 3.0 release post notes, for example, that the Azure Communication Services email and SMS send tools are excluded in read-only mode. Sending a message changes nothing in Azure, yet it is plainly not a read. That classification can be refined between versions, which is one more reason the identity, not the flag, is the boundary you rely on.
Second, the new operationPlane metadata in 3.0 labels each operation as control plane, data plane, both or not applicable. Control-plane reads return how resources are configured. Data-plane reads return what is inside them: log rows, blobs, documents, query results. Most of the leak risk sits on the data plane, so it is a useful way to sort the approved tool list: control-plane reads can usually be granted broadly within the workflow's scope, while every data-plane read deserves a named reason and the narrowest workspace or account that serves it.
A one-hour read-scope check
Before arguing about promotion, find out what the pilot identity can actually see. The check is short and needs no new tooling:
- List every role assignment, including inherited ones.
az role assignment list --assignee APP_ID --all --include-inheritedshows assignments at management-group, subscription and resource-group level. Inherited Reader at management-group level is the common surprise. - Look for data-plane roles. Roles such as Log Analytics Reader, Storage Blob Data Reader or Key Vault Secrets User grant access to content, not configuration. Each one should map to a tool on the approved list. Do not assume plain Reader is configuration-only: the built-in Reader role's wildcard read permission includes querying Log Analytics workspaces in its scope, which is how a pilot ends up reading log lines nobody meant it to see, as the example below shows.
- Check group membership. If the identity is in an Entra ID group, the group's assignments apply too. A pilot identity added to a broad "platform readers" group inherits whatever that group was given years ago.
- Run the workflow's real questions and record what came back. Note any result that contained personal information or secrets, and fix it at source rather than in the prompt.
The output is a short table: role, scope, why the workflow needs it, and who agreed. If a row has no reason, remove the assignment and see whether anything breaks.
The data path needs an owner
Sedgefield Freight is fictional, and its systems and figures are illustrative. Sedgefield's pilot server runs read-only, as a dedicated identity, against the development subscription. In week two an engineer asks the assistant why a dispatch API is slow. It queries the monitor workspace and returns forty log lines, several containing driver cell-phone numbers that the API logs on every request.
Nothing in the MCP configuration was wrong. The data had been sitting in the logs for a year. The agent simply made it visible, and sent it to the model provider in the process.
Sedgefield's response is a useful pattern:
- Fix the logging so the numbers are masked at source. That is the real defect.
- Restrict the identity to the workspaces the pilot needs.
- Record which model provider and region receive tool results, and treat that as a processing decision under POPIA with the information officer, not an engineering detail.
- Set a row limit and time window on log queries in the workflow instructions, and alert on queries that return unusually large results.
Define the promotion evidence before anyone asks
Read-only pilots succeed, and success creates pressure. Someone says "it's been fine for a month, let it apply the fixes". That is a decision to change the agent's authority, and it should need evidence, not a good mood.
Before an MCP-connected agent moves from inspecting to preparing changes, a platform team should be able to show:
- Scope evidence. The identity's role assignments are exported and match the documented workflow. No person's credentials are used.
- Behaviour evidence. A sample of runs shows the agent selecting appropriate tools and stopping when information is missing. Part 3 covers how to test this.
- Data evidence. The data path from tool result to model provider, logs and traces is documented, and sensitive fields found during the pilot have been fixed at source.
- Operational evidence. Query volume, cost and errors are observed, with alerts.
- Change path. Prepared changes will go through the existing pipeline and review, not a new side door.
Moving to execution needs all of that and more: a separate write identity, allow-listed tools, approval for the exact change, and evidence retained for every action. Part 7 describes that record.
Read-only is where you start, not where you stop
Some teams will keep their agents read-only indefinitely, and for many workflows that is the right answer. Others will promote specific workflows. Either way, the read-only stage is where the important design work happens: the identity model, the scope, the data path and the evidence habit. A team that treats read-only as "done" will skip that work and then promote an agent on top of foundations it never built.
Next: Part 3, Tool descriptions are part of agent behaviour. All parts are on the series page.
How CloudNala can help
CloudNala helps platform teams threat-model read access for agents connected to their cloud. We would map what an MCP-connected identity can read, follow the data path from tool result to model provider and trace store, identify sensitive data surfacing through logs and configuration, and define the promotion evidence your organisation will require before an agent prepares or executes changes.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an MCP Readiness Review or write to us at consult@cloudnala.co.za