Publication context
This reflection comes from a voice memo recorded on Monday, July 6, 2026. The article faithfully preserves my analysis as of that date, without reworking it in light of later developments. AI platforms move fast: some features mentioned here may have been added, changed, or removed since. This text is a snapshot of a line of reasoning, not a permanent state of affairs.
In a previous article, the day my AI account's security became a selection criterion, I described how a routine check shifted the way I think about trusting AI platforms. What I'm describing here is different, but complementary: this isn't about trust anymore, it's about architecture. That Monday, July 6, 2026, an evolution of the OpenAI platform, discovered almost by accident while configuring ChatGPT, made me realize these platforms wouldn't stay simple conversation interfaces for long.
The context of July 2026
At the time, my personal work environment already ran on several building blocks I operate and maintain myself: a Kubernetes cluster hosting part of my applications, several MCP servers I expose to connect my tools to various AI assistants, self-hosted services, and one or two personal agents I built to automate certain tasks. I also work, more broadly, on SaaS products and business applications — the question of how an external system integrates cleanly into an architecture isn't new to me; it's a concern I already carry on the software design side. None of this is exotic for anyone already working with this kind of infrastructure — but it's exactly this ground that made that day's discovery land so immediately, and it explains why it caught my attention far beyond what it would have meant for a typical ChatGPT user.
What I was already doing with my MCPs
Before that Monday, my use of MCP followed a pattern I think is fairly common among people experimenting with the protocol: exposing an MCP server on the internet, usually behind a reverse proxy or a gateway I control, so an AI assistant could connect to it and interact with my tools. It works, but it involves a decision I make every time with some caution: agreeing to expose a service directly on the internet, even a protected one, to make it reachable from the outside.
Discovering the tunnels
While configuring an MCP integration on my ChatGPT account that day, I came across an option I wasn't expecting, coming from the OpenAI ecosystem rather than the conversational interface alone: the ability to create a tunnel. Once I checked how it worked, the principle matched exactly what I'd imagined from the term itself: my MCP server can stay at home, on my local cluster, behind a kind of relay that bridges it to ChatGPT — without my needing to open that service directly on the internet.
Faced with a new capability like this one, I didn't stop at what it enables today. It's a habit I've built into my practice as an architect: looking at a feature and trying to imagine what it will make possible tomorrow in the systems I design, rather than judging it solely on its immediate use. That reflex is what let me grasp the technical implications of this tunnel almost instantly, before I'd even finished testing it.
The moment it clicked
What stopped me in my tracks wasn't the feature itself — technically, a tunnel is nothing groundbreaking. It's what it makes possible for someone who, like me, already hosts their own services. Within seconds, I projected this feature onto my existing infrastructure: my local MCP, my personal agents, my home Kubernetes cluster — all of it suddenly connectable to ChatGPT without direct exposure. It's no longer the assistant fetching a one-off piece of information. It's an assistant that can come consume an agent I host at home, continuously, as if it were just another service in my architecture.
The real shift happened at that exact moment. Before this discovery, I thought of ChatGPT as an external tool, one I used occasionally, much like any other third-party service. After this reflection, I started seeing it differently: as a potential component of my own information system, on the same footing as a service I might have deployed myself in my cluster. That shift — from external tool to integrable component — is what actually changed my perspective that day, far more than the tunnel mechanics themselves.
Without overstating the analogy, I did have, in that moment, the sense of witnessing a new stage in how digital platforms connect to one another — not in the sense that this tunnel compares to the arrival of the Web or the Cloud, but in the sense that it embodied, at my own scale, a paradigm shift in how an AI can interact with a system you host yourself. It's a personal impression, tied to that specific Monday, not a thesis on the history of computing.
Why this changes how I see AI platforms
Until then, I thought of AI platforms as entry points: you ask a question, they answer, sometimes leaning on a tool you'd connected to them for that occasion. What this tunnel made me understand is that they're becoming something else: full-fledged execution platforms, capable of integrating directly into an existing architecture, on the same level as a cloud service or a network gateway. Conversation becomes one layer among others, not the only mode of interaction.
What I immediately imagine for my own infrastructure
A number of concrete directions took shape right away. Connecting my personal agents to ChatGPT without ever exposing them on the internet. Having my local Kubernetes cluster talk to an AI assistant as if it were just another internal service. Rethinking some of my MCPs not as permanently exposed services, but as access points activated on demand, through a tunnel rather than a classic public exposure. None of this is settled in my head at this stage — it's more a list of directions this discovery opened up all at once.
Why I consider this a major shift
For a mainstream user, this feature might look anecdotal — just another configuration detail. For someone who already designs and hosts their own systems, it changes the nature of the relationship between the AI assistant and one's personal infrastructure. It shifts the question from "how do I connect my tool to this AI" to "how do I integrate this AI into my existing architecture" — a change of posture, not just a new feature.
That same day, I checked whether Claude AI offered a comparable option: on my account, as of this July 6, 2026 date, I didn't find an equivalent to the tunnels I'd just discovered on ChatGPT. I mention this as a dated observation, specific to my account and to that particular moment — not as a lasting comparison between the two platforms, whose gap, if it exists, can shift quickly.
Looking ahead
What I take away from that Monday isn't the existence of MCP tunnels as such. It's confirmation of a broader shift: AI assistants are no longer just tools we connect to. They're progressively becoming components capable of integrating into our own architectures.
For a long time, our integration work has mostly consisted of connecting our applications to cloud services — bringing the cloud toward our systems. With the emergence of MCP and mechanisms like these tunnels, I had, that Monday, the sense that the movement is starting to reverse: it's now the AI platforms themselves that are seeking to integrate directly into our own systems, rather than the other way around. This shift in perspective, still nascent and likely to evolve quickly, is to my mind the real subject of this reflection — far more than the feature that revealed it to me.
After a first reflection on digital trust and AI account security, this one is about architecture. These aren't two separate topics, but two stages of the same reflection on my practice as an engineer: as these platforms integrate more deeply into our work environments, how do I choose to welcome them in, and under what conditions do I give them a place in the systems I design? It's a question I plan to keep exploring in future field reports, as these use cases become clearer.