Security reviews of AI integrations tend to go wrong in one of two ways. Either they treat the model as the threat, and spend the meeting on whether it might "go rogue", or they treat the protocol as the control, and sign off because the server "uses OAuth". Neither finds the problems that actually appear in production.
The problems that appear are ordinary. A connector runs with a shared account. A token is forwarded where it should not be. A claim note contains text that reads like an instruction. A tool writes to a legal record without anyone confirming. A server is compromised and nobody knows how to switch it off. Each is a design gap, not a model failure, and each can occur on a server that is fully compliant with MCP.
This part is a review you can reuse. It is nine questions, each tied to the failure it is designed to catch, with what a good answer looks like. It is written for the security architect, the platform lead and the system owner sitting in the same room.
Kwelanga Insurance is fictional, and its systems and figures are illustrative. Kwelanga ran this review on its rebuilt claims and policy servers from Part 4 before connecting them to Kwelanga Assist in production. It found three problems the team had not seen, which is roughly what a review should find.
Where MCP deployments fail
The specification's own security pages, checked on 14 October 2026 against version 2026-07-28, describe several attack classes in detail: confused deputy attacks through proxy servers, token passthrough, server-side request forgery during authorisation discovery, hijacking of state handles, compromise of local servers and abuse of over-broad scopes. Add the content problems that come with any system where a model reads untrusted text, and the failure points line up along a single call.
The nine questions below are designed to catch these eight failures, and a little more.
1. Who operates the client and the server?
Catches: untrusted servers, and local servers with too much reach.
A server your platform team builds, reviews and runs is a different risk from one a developer installed from a public listing last week. Local servers launched over the stdio transport run as processes on the user's machine with that user's privileges; the specification's best-practice guidance asks clients to show the exact command before running one, and recommends sandboxing.
Good answer: every server in production is in the service catalogue with named owners, and its source and version are known. Community servers are either reviewed and pinned to a version, or not allowed.
2. Which identity reaches the downstream system?
Catches: failure 4, token passthrough, and confused deputies.
The specification forbids an MCP server from accepting tokens that were not issued for it, and its security guidance names token passthrough, forwarding a client's token unchanged to a downstream API, as an anti-pattern. The underlying question is broader: when the claims server calls the claims platform, does the platform see the handler, the server's service account or the client's original token?
Good answer: the server validates that the token was issued for it, then obtains a separate credential for the downstream system that still identifies the handler, for example through a token exchange. The claims platform can tell who is really asking.
Kwelanga's rebuilt claims server passed this. Its policy server did not: it called the policy API with a static API key. Policy information is low sensitivity, but the audit trail showed every lookup as "policy-mcp", which made question 8 impossible to answer.
3. Can one user cause the agent to access another user's data?
Catches: failure 3, and state-handle hijacking.
This is the question that matters most for personal information, and the one a demo never asks. Kwelanga's handlers are assigned claims by portfolio. Can a motor handler, by asking cleverly, get a summary of a commercial claim?
Under the 2026-07-28 specification there are no protocol sessions, so state that spans calls is carried in handles passed as tool arguments. The specification's guidance is direct: possession of a handle is not authentication, handles should be unguessable, and servers should bind them to the authenticated user.
Good answer: every read and write checks the caller against the record, every call, in the system of record. Handles are random, short-lived and bound to the caller's identity.
This is where Kwelanga found its most serious issue: the sequential draft-note handles described in Part 4. Fixed before go-live.
4. Are descriptions and returned content treated as untrusted input?
Catches: failures 1 and 5, injected instructions and changed descriptions.
Claim notes contain text from claimants, brokers and assessors. Documents contain whatever their authors wrote. Tool descriptions contain whatever the server operator wrote. A model reads all of it.
Good answer: the host treats every description, resource and result as data. Approved descriptions are pinned and changes trigger re-approval. Results that matter are structured and validated against an output schema. Most importantly, no single piece of returned text can cause a consequential action on its own: an instruction hidden in a claim note may confuse the model, but the next three questions mean it cannot cause a payment, a status change or an export.
5. Which tools create side effects?
Catches: failure 6, at the inventory stage.
List every tool and classify it: reads low-sensitivity data, reads personal data, writes an internal record, or causes an operational or financial side effect. Annotations such as readOnlyHint and destructiveHint are useful hints for the host's interface, but the specification says clients must treat them as untrusted unless the server is trusted, so the classification has to come from your own review of the code.
6. What needs explicit confirmation?
Catches: failure 6, at the control stage.
The specification says there should always be a human able to deny tool invocations, and that clients should prompt for confirmation on sensitive operations. In practice, confirming every read trains people to click "yes" without reading. Confirm in proportion to consequence.
Good answer: a table like Kwelanga's above, agreed with the business owner. Every write is confirmed with the exact content shown. Operational side effects need a role, a change reference and a second person, and Kwelanga decided that restarting a queue worker would not be available to the staff assistant at all.
7. Are secrets kept out of the model's context?
Catches: failure 2.
API keys, database connection strings and downstream tokens belong in the server's execution layer, never in a tool argument, a description, a result or a prompt. The specification also warns server developers not to mirror sensitive parameters into HTTP headers, because headers are visible to network intermediaries.
Good answer: a grep of tool schemas, descriptions and sample results for anything resembling a credential finds nothing. Secrets are retrieved by the server at call time and never returned.
8. Can every action be reconstructed later?
Catches: failure 8.
When a claimant complains that a note on their file is wrong, Kwelanga must be able to say who asked for it, through which application, what the model proposed, what the person confirmed, what the server sent to the claims platform and what came back. The specification reserves fields for OpenTelemetry trace context so a trace can follow a request from host to server, but recording the evidence is still your design.
Good answer: one correlation identifier links the host's record of the conversation turn, the server's audit record and the downstream system's log. A trace is not an evaluation covers what that evidence should contain.
9. How is a compromised server disabled?
Catches: failure 7.
If a server is compromised, or simply starts misbehaving, how long does it take to stop every host using it? Who can do it, out of hours?
Good answer: a documented, tested kill switch per server and per tool, owned by the platform on-call rota, plus the ability to revoke the server's downstream credentials independently. Kwelanga's first answer was "we would redeploy the host without that server", which takes about two hours. That gap is what led to the gateway in Part 6.
Two more checks for remote clients
Two classes of attack in the specification's guidance are worth adding when your MCP clients run on servers rather than laptops. Server-side request forgery: during authorisation discovery a client fetches URLs that a malicious server controls, so block private and link-local address ranges, including cloud metadata endpoints, and route discovery through an egress proxy. Scope minimisation: start with the smallest scopes and step up only when a privileged tool is actually used, rather than requesting everything up front.
Running the review
Kwelanga's review took half a day per server with the security architect, the engineering owner and the business owner. Its output was three findings, the tier table, a test for each finding and a date for the next review, which the team set for whenever a tool is added or a description changes.
This is general information about security design, not a compliance determination. Where personal information is involved, your information officer and legal advisers should confirm what POPIA's security safeguards require in your case.
Key points
Compliant is not the same as safe. Most real failures are about identity design, content handling, confirmation and operations.
Identity is the centre of the review. Who reaches the downstream system, and can one user reach another user's data?
Treat everything inbound as data. Descriptions, documents and results can confuse the model, so make sure confusion cannot cause a consequential action.
Confirm in proportion to consequence. Reads need identity and access checks; writes need confirmation; operations need a role, a change reference and a second person.
Know how to switch it off. A tested kill switch and independent credential revocation, owned by on-call.
Next: Part 6, The enterprise MCP gateway. All parts are on the series page. For the wider agent risk picture, see Agents change the risk boundary.
How CloudNala can help
We run MCP security reviews with your security, platform and business owners in the room: walking the nine questions against your actual servers, testing the cross-user and handle cases rather than assuming them, agreeing a tier table for confirmation and approval, and leaving you with findings, tests and a re-review trigger. It is a practical half-day per server, not a framework exercise.
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 Security Review or write to us at consult@cloudnala.co.za