Ask a platform team how a change reached production and they can usually show you. There is a ticket, a pull request, a reviewer, a pipeline run and the cloud provider's activity log. The trail may be imperfect, but it exists, and it was designed.
Now ask how a change made through an agent reached production. The request is in a chat history on someone's laptop. The tool calls are in the MCP server's log, if it was logging. The plan was shown in the conversation and may not have been saved. The approval was someone typing "yes". The activity log shows an identity, but not which person asked or why. Each piece exists somewhere. None of them is joined to the others.
This final part of the series puts them together. It describes a single change record that runs from natural-language intent to verified result, and shows it with a complete synthetic example.
Why the chain matters
Three groups need this record, for different reasons.
- Operations need it to understand an incident: what changed, when, why, and how to reverse it.
- Audit and risk need it to show that changes were authorised by someone with authority, not merely suggested by a model and accepted.
- The platform team needs it to improve the agent: which requests produced bad plans, which approvals were rubber stamps, which tools failed.
The cloud operations agent reference architecture argued that natural language must not bypass change management. The change record is how you prove it did not.
The eight links
- Request. What the person asked, in their words, with who they are and when.
- Interpreted intent. What the agent understood the request to mean, stated back in plain terms before any action. This is where misunderstandings are cheapest to catch.
- Evidence gathered. The read-only tool calls made to understand the current state, with their results or a reference to them.
- Proposed change. The exact change: a Terraform plan, a configuration diff, a named action with parameters. Not a description of the change.
- Approval. Who approved, under which authority, and what exactly they saw. An approval of a summary is not an approval of the change.
- Execution. The tool call or pipeline run that applied the change, under which identity, with the server version and tool name.
- Result. What the cloud reported, and whether the operation actually completed, not merely whether it was accepted. The API call succeeded, the change did not explains why this distinction matters.
- Verification. A follow-up check that the intended state now exists and nothing else changed.
The record ties these together with one identifier that appears in the chat, the MCP server log, the pull request or change ticket, and, where possible, the resource tags or deployment name.
A complete synthetic example
Sedgefield Freight is fictional, and its systems, identities and figures are illustrative. The request concerns a development storage account flagged by Advisor.
| Link | Record entry |
|---|---|
| Request | 2026-11-03 09:12, a platform engineer on the dispatch team: "Fix the Advisor finding on the dispatch-dev storage account." |
| Interpreted intent | "Disable Shared Key authentication on storage account stdispatchdev01 in resource group rg-dispatch-dev, subscription Sedgefield-Dev, as recommended by Advisor. No other changes." Confirmed by the engineer. |
| Evidence gathered | Advisor recommendation retrieved (read-only tool, server 3.0.x pinned). Current setting: Shared Key enabled. Two app settings in app-dispatch-dev reference a connection string with an account key. |
| Proposed change | Terraform pull request #412: set shared_access_key_enabled = false; switch app-dispatch-dev to managed identity with Storage Blob Data Contributor. Plan output attached: 2 to change, 1 to add, 0 to destroy. |
| Approval | The platform owner for dispatch-dev, a different person from the requester, approved PR #412 after reading the plan. Authority: development change policy, no CAB required. |
| Execution | Merged; existing pipeline run 1187 applied the plan using the pipeline's deployment identity. The agent did not execute the change. |
| Result | Pipeline reported success; Azure activity log entries for the storage account, the app and the role assignment show the operations completed. |
| Verification | Agent re-read the account setting: Shared Key disabled. Smoke test on app-dispatch-dev passed. Record closed with ID SF-CHG-2026-1103-07. |
Two things stand out. First, the agent found the dependency (the connection string) during evidence gathering, which turned a change that would have broken the application into one that did not. That is the value. Second, the agent prepared but did not execute. The execution ran through the same pipeline and identity as any other change. That is the control.
Note too that this particular change mirrors one of the defaults Microsoft describes for new storage accounts created through Azure MCP Server 3.0. As Part 1 noted, those defaults do not touch existing accounts. Changes like this one are how existing resources catch up.
When the agent executes directly
Some organisations will allow direct execution for narrow, reversible actions in specific environments. The record must then carry more, because there is no pull request and pipeline to provide it:
- the exact tool and parameters, captured before the call;
- the policy that pre-approved this class of action, with its version;
- the identity used, which should be a dedicated write identity, not the read identity;
- the result and the verification, recorded automatically;
- an alert to the owner, so execution is never silent.
If you cannot produce that record automatically, the action should not be autonomous.
Building it without a new platform
Most of the record already exists in pieces. The work is joining them:
- Make the interpreted intent an explicit step in the agent's workflow, and save it.
- Log every MCP tool call centrally with user, tool, parameters, result size and correlation ID. A shared server makes this easier (Part 6).
- Route prepared changes into your existing pull request or change system, and put the correlation ID in it.
- Tag or name deployments with the ID where the platform allows.
- Add the verification step to the workflow, and record its result.
Then test the record the way an auditor would: pick a change at random and try to reconstruct it from request to verification without asking anyone. Where you get stuck is where the chain is broken.
What this series has argued
MCP servers are becoming part of the cloud control plane. Treat them that way. Decide authority before tools are exposed. Start read-only, but threat-model the reads. Test tool selection and treat descriptions as behaviour. Give databases their own boundary. Pin versions and test upgrades. Choose where servers run by identity and ownership, not convenience. And keep a change record that a stranger could follow.
None of this depends on a particular vendor. Azure MCP Server 3.0 is simply the clearest current example of why it matters.
Back to the start: Part 1, Your agent can operate Azure. What exactly did you authorise? All parts are on the series page.
How CloudNala can help
CloudNala helps organisations make agent-made changes auditable. We design the change record for your environment, connect the agent workflow to your existing pull request, pipeline and change systems, set up central tool-call logging with correlation, and test the result by reconstructing real changes end to end.
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