A Firewall for a Protocol Nobody Told You Was on the Network
Return to Part 0: Table of ContentsPrevious Chapter: Part 30, Your Experiment Tracker Is Production Infrastructure Now
Microsoft's documentation for its new Model Context Protocol control opens with a sentence that should stop an enterprise architect mid-scroll.
"MCP logging helps you discover shadow MCP servers in your organization."
Discover. Not restrict, not govern. Find.
The second sentence explains how, and it is the one that carries the argument. Microsoft's documentation says the control uses "deep packet inspection to identify MCP traffic based on the protocol itself," rather than what every predecessor product relied on, "a predefined cloud app catalog." Read that as an architect rather than as a buyer. A cloud app catalogue is how every software-as-a-service discovery product has worked for a decade: you hold a list of known destinations, you watch for traffic to them, you report what you find. Microsoft is telling you that approach does not work here, because there is no list. The servers your agents are reaching are not in anyone's catalogue. Some of them are not on anyone's internet.
So the product has to read the wire and recognise the grammar.
For readers who have not had to care yet: the Model Context Protocol is the connector standard an AI agent uses to reach a tool. Your assistant queries a claims database, checks a calendar, files a ticket, reads a document store. Something has to sit between the model and that system, describe what the system can do, and carry the call. That something is an MCP server. It is a small piece of software, it takes minutes to stand up, and it is where an agent's actual reach into your organisation is decided.
Microsoft put a firewall in front of it in September 2026, in public preview. The interesting part is what the firewall had to do first.
What the control actually does, and what it cannot do
Precision matters more here than enthusiasm, so take the documented capability rather than the announcement.
The prerequisites are specific. You need a Global Secure Access licence. You need either the Global Secure Access client installed on end-user devices with Internet Access traffic forwarding and TLS inspection enabled, or Global Secure Access integration with Microsoft Copilot Studio. The TLS requirement is not incidental. Microsoft states the reason plainly: TLS inspection is required because, as the documentation puts it, "MCP data is in the encrypted payload of the traffic." To find out what your agents are talking to, you break and inspect the encryption on the devices they run on. That is a real architectural decision with real privacy consequences, and it belongs in the business case rather than in a footnote.
Then the limit, stated on Microsoft's page as a limit rather than discovered by a customer. "MCP Logging only captures traffic to remote MCP servers," it says, and local ones fall outside that scope because they generate no network footprint the tool can inspect. A locally-running MCP server, the kind a developer starts on their own laptop over standard input and output because it is the fastest way to give an agent access to something, produces no network traffic at all. It is not unmonitored by policy choice. It is invisible by construction. The census this product produces is a census of one transport.
And the enforcement, on the same page, is coarser than the product name suggests: to stop a risky server, the documented method is to "use URL filtering to deny access to that server's URL." That is destination-level blocking through web content filtering. Trade coverage of the September announcement describes something finer, allowing or denying individual tools, resources and prompts and enforcing protocol versions and transports. That finer capability may well exist. This chapter does not assert it, because no documentation page has been located that describes it, and a preview feature's marketing is not its specification.
None of which makes the control weak. It makes it honest. What it does is tell you what is there.
The protocol is common ground. The visibility is not.
Here is the part the product announcement does not draw attention to, and it is the reason this chapter exists.
MCP is not Microsoft's. Anthropic contributed it to the Agentic AI Foundation, a directed fund under the Linux Foundation, announced on 9 December 2025, alongside goose from Block and AGENTS.md from OpenAI. Anthropic, Block and OpenAI are the co-founding companies. The platinum members named in the announcement are Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI.
The reasons given were about governance, not engineering. Jim Zemlin, executive director of the Linux Foundation, said bringing the projects together under the AAIF gives them "the transparency and stability that only open governance provides." Mike Krieger, Anthropic's chief product officer, said donating MCP to the Linux Foundation as part of the AAIF "ensures it stays open, neutral, and community-driven" as it becomes infrastructure the wider AI industry depends on.
Both statements are true, and neither of them was ever going to produce an inventory.
That is the structural point, and it is worth stating flatly because it generalises well beyond this product. Open, neutral, multi-vendor governance of a wire format determines who controls the specification. It says nothing about who can see the specification in use inside a given enterprise. Those are different questions with different answers, and the second one is currently answered commercially, per vendor, behind a licence and a TLS-inspection requirement, by one of the protocol's own supporting members.
This is not an accusation. Nothing in the record suggests bad faith, and Microsoft building visibility into a protocol it helps fund is ordinary product strategy. It is a limit on what open governance achieves on its own, and architects who reach for "it's an open standard" as a governance answer should know where that answer stops. The standard being open is why a deep-packet-inspection product could recognise the protocol at all. It is not why anyone knows how many servers are running.
This is not the Logic Firewall
A note on vocabulary, because two things in this book now share a word and they are not the same thing.
Chapter 10, "Explainable Zero Trust: When Your AI Must Justify Its Decisions", introduced the Logic Firewall as an active governance mechanism that inspects and interrupts an agent's reasoning before it acts, alongside Logic Logging as the passive audit layer that captures the reasoning chain. Microsoft's MCP firewall does something else entirely. It inspects the wire between an agent and a tool, and it decides whether a connection is permitted.
Different layer, different question. The Logic Firewall asks whether an action should happen given what the agent concluded and why. A protocol firewall asks whether this destination is allowed at all. You can hold one without the other, and most organisations reading this will get the second one first because a vendor is selling it. Do not let the shared noun collapse them. A control that can block a server URL has told you nothing about whether the agent's reasoning to call it was sound.
Why an MCP server is the sharpest version of a problem this book named early
An MCP server is a compact instance of the lethal trifecta, the term Simon Willison coined in June 2025 for the combination of private data access, untrusted content exposure, and external communication capability.
Look at what one actually is. The server exists to give an agent access to a system that holds something worth having, which is the first leg. The agent's context window fills with whatever comes back from that system and from every other tool in the session, which is untrusted content, and that is the second. And the protocol itself is an external communication path, the third, because the whole point of a remote MCP server is that the traffic leaves the device.
A single MCP server, wired up in an afternoon, can satisfy all three legs at once. That is not a misconfiguration. It is the design working as intended.
This series has been circling the same absence for a while from other directions. Chapter 24, "Sixteen Hundred Agents and No Inventory: The Identity Layer Zero Trust Forgot", measured the blind spot for agents an organisation knowingly deployed. Chapter 16, "The Non-Human Identity Crisis: Why Your Zero Trust Architecture Has a Blind Spot", established the scale of the non-human population those agents join. Chapter 9, "The Identity Layer: When Every Agent Needs a Badge", argued that every non-human actor needs an identity issued, scoped and rotated like any privileged service account, and Chapter 12, "The Sixth Pillar: Agent Identity and the New Perimeter", made agent identity the sixth Zero Trust pillar.
An MCP server is precisely the kind of actor all four of those chapters describe. It holds credentials to a system. It is reachable by an agent. It has no badge, because nobody issued one, because nobody knew it existed. Recent chapters in this part have found the same shape twice more in the past fortnight, in build infrastructure and in machine-learning development tooling, both times in systems classified by where they sat in a lifecycle rather than by what they held. Those chapters diagnosed. This one is different in kind: a hyperscaler has put the diagnosis into a product roadmap and priced it.
There is also a pattern name for how these arrive. Chapter 19, "The Delegation Problem", described enterprise governance emerging from accumulated vendor defaults rather than from deliberate architectural choice: deploying before governing. An MCP server is that pattern in miniature. Nobody convened a review. A team enabled a connector because the vendor made it one click, or a developer wrote forty lines of Python because it was faster than filing a request. The architecture arrived by accretion, and the first architectural decision anyone made about it is the one being made now, retrospectively, by buying a tool that counts them.
A register that records its own blind spot
Here is the artefact. It is a declaration, one block per MCP server, held in version control next to whatever configuration stands the server up, and reviewed when that configuration changes rather than annually.
The unusual field is the last one. Most asset registers record what is known. This one records whether the discovery control you just bought can see the entry at all, because a register that quietly mixes "confirmed present" with "cannot be confirmed either way" is worse than no register.
# mcp-server-declaration.yml# One block per MCP server. Reviewed when the server config changes.mcp-server:name: claims-document-storepurpose: "Read-only retrieval of policy documents for the claims assistant"owner-team: claims-platformtransport: remote-httpendpoint: "https://mcp.internal.example.co.nz/claims-docs"fronts-system:name: policy-document-storedata-classification: commercial-in-confidencecontains-personal-information: trueagent-reach:callable-by: ["claims-assistant-prod"]tools-exposed: ["search-documents", "fetch-document"]write-capable: falseidentity:credential-type: workload-identitycredential-lifetime-hours: 8scoped-to-this-server: truetrifecta-legs-satisfied:private-data-access: trueuntrusted-content-exposure: trueexternal-communication: truenote: "All three. Treat as a delegation boundary, not a data source."network-discoverability:visible-to-protocol-inspection: truereason: "Remote HTTP transport; in scope for network-layer MCP discovery"The value is in what the fourth and sixth blocks force. A team filling in trifecta-legs-satisfied has to decide, in writing, whether the thing they stood up in an afternoon is a data source or a delegation boundary. A team filling in network-discoverability has to state whether any discovery control can confirm the entry, which turns "we bought the firewall" into "we bought the firewall and it covers this much of the estate."
| Transport | Discovery control sees it | What that means for the register |
|---|---|---|
| Remote, HTTP-based | Yes, with TLS inspection enabled | Entry is verifiable against observed traffic |
| Local, on-device | No, no network footprint to inspect | Entry rests on declaration alone; audit by inspecting the device |
| Remote, via a managed agent platform | Yes, through the platform integration | Entry is verifiable without device-level TLS inspection |
This is a starting shape, not a finished control. It says nothing about who may approve a new entry or what happens when a declaration and observed traffic disagree, and both of those are governance decisions your organisation has to make rather than inherit from a schema.
Aotearoa New Zealand: what the guidance says, and what it assumes you already know
New Zealand's National Cyber Security Centre co-authored joint guidance on this exact class of system. "Careful Adoption of Agentic AI Services", published 1 May 2026, was developed with the Australian Signals Directorate's Australian Cyber Security Centre, the United States Cybersecurity and Infrastructure Security Agency, the United States National Security Agency, the Canadian Centre for Cyber Security and the United Kingdom's National Cyber Security Centre. Twenty-eight pages, and it is worth reading in full rather than in summary.
It is direct about privilege. The authoring agencies recommend "never granting it broad or unrestricted access, especially to sensitive data or critical systems", and state that organisations "should only use agentic AI for low-risk and non-sensitive tasks." It is equally direct about observability, instructing organisations to "log agent tool usage and ensure results are captured in system logs" and to integrate source checks with agent logs so they can record which tools were used and what was retrieved.
Every one of those instructions is sound, and every one of them starts from a position further along than most organisations are standing. They describe what to do with an agent-to-tool connection you know about. Read the document for guidance on establishing which connections exist in the first place, and that step is not addressed. The word inventory does not appear in that sense. Neither does Model Context Protocol, anywhere in the document.
That is an observation about sequence, not about quality, and the distinction matters. The guidance is written for the organisation that can enumerate its agents' tools. Microsoft's product exists because that organisation is rarer than the guidance assumes. A New Zealand practitioner holding both documents has a competent instruction set and no starting inventory to apply it to, and closing that gap is enterprise work rather than a regulatory one.
For citation hygiene: the New Zealand Information Security Manual is at v3.9, released 9 May 2025, and remains the current version on the last check this series ran. It was not examined at chapter level for agent-to-tool or protocol-level guidance this session, so no NZISM control is cited here, and that absence is stated rather than papered over.
The open-source dimension
Worth naming, because the governance story here runs the other way from the usual one. MCP is not proprietary. Anthropic contributed it to the Agentic AI Foundation, sitting alongside goose, Block's open-source agent framework, and AGENTS.md, OpenAI's contributed convention for describing a repository to a coding agent. That openness is load-bearing for the security story in a specific, technical way: a closed connector protocol could not be recognised on the wire by a third party, because its grammar would not be public. Microsoft's deep packet inspection works because the protocol is documented and open to any implementer. Openness bought inspectability. It did not buy an inventory, and it never could have, because an inventory is a fact about one organisation's estate, not a property of a specification. Anyone who has argued that an open standard is a governance answer in itself should carry both halves of that sentence.
The sequence this control follows, discovery in front of enforcement, is doctrine everywhere zero trust actually originated. The United States Cybersecurity and Infrastructure Security Agency's Binding Operational Directive 23-01, issued in October 2022, told federal civilian agencies the same thing years earlier: you cannot govern access to a system nobody has enumerated, so automated asset discovery comes first, and vulnerability enumeration follows it on a fixed schedule, not once a year. The Department of Defense's own Zero Trust Reference Architecture opens on the same premise, that an unknown asset is an ungoverned one by definition. Microsoft's product did not invent the discovery-first sequence. It imported a defence-sector assumption into an enterprise product category that had spent a decade assuming visibility could be bought later. For an architect, the ordering is the tell: whichever comes first, discovery or enforcement, is the ordering an organisation actually believes.
An enterprise architect at a New Zealand insurance company turns on MCP logging on a Tuesday afternoon. The pilot exists to satisfy a board request for "AI visibility", raised after a trade-press story about somebody else's breach, and she expects it to confirm what her team already believes. Two servers, maybe three: the claims database connector and the policy documentation store, both wired up deliberately over the past few months.
She checks the dashboard on Wednesday morning. There are eleven.
Two she recognises. Three more turn out to be the same approved servers logged under slightly different destination URLs, because a developer stood up a staging copy nine months ago and never took it down. The remaining six she does not recognise at all.
One of them, when she opens the session detail, is a marketing team's trial of a scheduling assistant, connected to a calendar tool that also holds read access to a shared drive nobody scoped it to touch. Nobody asked security. Nobody thought of it as something security needed to know about. It was a browser extension one person installed before a conference to save half an hour a week.
She is not looking at a list of unauthorised systems her team failed to stop. She is looking at the first list of MCP traffic her organisation has ever had, because until Tuesday afternoon there was no way to produce one. And the number she will put in the board paper is not how many of the eleven were malicious. None of them were. It is that six of eleven were unknown, that the count only covers servers running over the network, and that nobody in the building can currently say what the number would be if it covered the laptops too.
The board asked for a compliance checkbox. What she has is a census, and the honest version of a census reports its own coverage.
Which is the finding worth carrying out of all of this. When a vendor with the resources of Microsoft ships a security control and puts discovery in front of enforcement, that ordering is evidence. It says the market's binding constraint is no longer deciding what to permit. It is knowing what is already connected.
Which agent-to-tool connection in your organisation was the last one somebody deliberately approved, and can you name who approved it?
If your programme needs an independent architecture assurance review before its next gate, message me and I will send the scope and the fixed fee.
The views expressed in this article are entirely my own, informed by morethan 30 years of professional experience in architecture, security, andtechnology leadership in New Zealand. I write as director of Te PonoLimited; the views are personal and do not represent the position of anyclient, any government agency, or the New Zealand government. My commentaryon legislation and policy is analytical, drawing on publicly availablesources and my professional expertise in architecture, security, and AIgovernance, and it is politically neutral.
Andreas Hamberger is a New Zealand leader in Architecture & Security and Associate Member of the Institute of Directors. Zero Trust Architecture for the Agentic Enterprise is the first book in The Hamberger Report series, providing practitioners with deployable patterns and configurations for securing AI-driven systems. Through Te Pono he provides independent architecture assurance reviews and AI verification audits to boards and programmes; contact andreas@thehambergerreport.com for the scope and fixed fee.
This article was produced with AI assistance under my direction. Research,drafting and images pass through a pipeline I built and govern: automatedgates for source verification, forbidden language and political neutrality,and my own review before anything is published. The tools include Claude,Gemini and Openart. The frameworks, arguments and editorial judgements aremine and are the same discipline I apply to the AI systems I audit forclients. AI accelerated the work; the thinking, and the responsibility forit, are mine.
[1] Microsoft. "How to view Model Context Protocol (MCP) traffic logs in Global Secure Access (Preview)." Microsoft Learn. Page metadata ms.date 31 March 2026; last updated 1 April 2026. Fetched directly 3 September 2026. https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-view-model-context-protocol-logging
[2] Noureen, R. "Microsoft Entra Expands Identity Governance and Access Controls." Petri IT Knowledgebase. 2 September 2026. https://petri.com/microsoft-entra-identity-governance-access-control/
[3] The Linux Foundation. "Linux Foundation Announces the Formation of the Agentic AI Foundation." 9 December 2025. https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
[4] Willison, S. "The lethal trifecta for AI agents: private data, untrusted content, and external communication." simonwillison.net. 16 June 2025. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
[5] National Cyber Security Centre New Zealand. "Careful Adoption of Agentic AI Services." 1 May 2026. Co-authored with ASD's ACSC, CISA, NSA, the Canadian Centre for Cyber Security and NCSC-UK. https://www.ncsc.govt.nz/protect-your-organisation/careful-adoption-of-agentic-ai-services/
[6] CISA, NSA, ASD's ACSC, Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK. "Careful Adoption of Agentic AI Services." Joint guidance, 28 pages. https://media.defense.gov/2026/Apr/30/2003922823/-1/-1/0/CAREFUL%20ADOPTION%20OF%20AGENTIC%20AI%20SERVICES_FINAL.PDF
[7] National Cyber Security Centre New Zealand. New Zealand Information Security Manual, v3.9. Released 9 May 2025.
[8] Cybersecurity and Infrastructure Security Agency. "BOD 23-01: Improving Asset Visibility and Vulnerability Detection on Federal Networks." 3 October 2022. https://www.cisa.gov/news-events/directives/bod-23-01-improving-asset-visibility-and-vulnerability-detection-federal-networks