Here’s my latest “back of the envelope” drawing, which I drew as a companion for a new NetFoundry series called Reachability Watch.
Published fortnightly, Reachability Watch covers the volume of new network-exploitable CVEs, the handful that clear a CVSS 8.6 bar, whatever KEV actually caused damage that period, and a running tally so the trend line becomes visible over time.
The drawing features this edition’s highlighted KEV. More formally known as CVE-2026-72898, it’s what I call “BYOK: bring Your Own Key,” because that’s essentially what the exploit does. You hand Metabase’s password-reset endpoint an extra user-id key it never asked for, nobody strips it, and it rides all the way into the SQL query.
Here’s a fun little contradiction to start your week with: NetFoundry asked 200 CISOs and CTOs whether they feel pressure to secure the AI they’re deploying. Unsurprisingly, and to my considerable relief, every single one said “yes”.
We then asked how confident they are that their current tools can actually handle the new risks, and 15% said “very.” 15% is very slightly less that the odds for rolling six on a 1d6. More specifically, among the CISOs, whose entire job is to be the professional pessimist in the room, that figure dropped to 10%.
That’s the current situation: Universal pressure, near-universal doubt.
I work at NetFoundry as a developer advocate, and NetFoundry commissioned this report. So yes, this is a vendor survey, and you’re correct to raise an eyebrow. (I’d be worried if you didn’t).
In our defense, we did the thing you’re supposed to do: the survey itself was run by an independent research firm (Global Surveyz), the respondents were 200 US-based security and technology leaders at companies with 1,000+ employees, and it was fielded this past May and June.
I’m going to try and separate what the survey found from what I think it means. The first category is data. The second category is me, a guy on the internet, having opinions, which won’t always be the same as NetFoundry’s Marketign department (it happens). I’ll flag which is which.
The number that reframed the whole thing for me
Of everything in here, this is the one I keep coming back to:
Security leaders are nearly 10x more likely to worry about securing machine-to-machine workloads than human access to applications.
Specifically: 69% said machine workloads (service-to-service, API-to-API, agent-to-whatever) are where they’re least confident today. Just 7% said human user access. The remaining 24% said “both equally,” which I read as “please don’t make me pick.”
That tracks perfectly, and it’s a compliment to the last decade of security work. Think about what we spent the 2020s doing. COVID sent everyone home, remote access became the whole ballgame, and the industry poured an enormous amount of money and brainpower into VPNs, Zero Trust access, and all sorts of security measures for a world that was suddenly more online that ever. It worked, and hman access to applications is, comparatively, a solved-ish problem. We got good at authenticating people. (I should know; it was during that time that I worked at Auth0!)
The issue of identity
The catch is that all of that machinery is built on one quiet assumption: that the thing connecting to your app is a human being with a unique identity. You authenticate the person, then you grant the access.
My late former coworker, Vittorio Bertocci, has forgotten more about identity than I will ever learn, and he was starting to look very deeply into identity in the age of AI.
Agents and models don’t work like that. They don’t have identities the way humans do. So the tooling we built for the last problem doesn’t cleanly transfer to this one, and the volume is going the wrong direction, fast. Machine traffic is now growing several times faster than human traffic year over year. We got really good at guarding a door that fewer and fewer of the visitors are actually using.
A few more stats worth your attention:
100% agree their attack surface is growing. Not a plurality. Not a strong majority. Everyone. The average projected increase was 14% over the next 12 months, and that figure only counts AI deployments already underway or planned. 14% is probably the minimum.
93% are concerned about the new risks AI introduces, but only 15% are highly confident their current tools can handle them. That’s the gap I opened with. When the level of concern and the level of confidence are that far apart, something structural is going on.
99% admit they don’t have full visibility into their own AI deployments. That remaining 1%, which would have to be one respondent? I would like to buy that person a coffee (or beer! or bourbon!) and ask them a lot of questions.
90% are worried about shadow AI, the unsanctioned tools employees adopt on their own because the approved options don’t cut it. This is not a technology problem, it’s a human-nature problem. I will neither confirm nor deny my own contributions to the shadow AI at previous organizations, but in my defense, I was getting things done! When a tool is genuinely useful, people use it, memo or no memo.
Only 8% call their current identity systems “very sufficient” for non-human workloads. 85% are now actively evaluating or exploring new approaches. That second number is the tell. When five out of six organizations are shopping for a new approach at the same time, that’s teh surest indicator that the industry is collectively coming to the realization that the existing tools weren’t built for this.
Oh, and it’s slow. 55% cited risk and compliance review as a top contributor to delays in the network changes AI deployments need, and those changes add an average of 8 days from request to implementation. And that’s now, while AI-specific scrutiny is still warming up.
My read (this part is me, not the data)
In this section, I’m switching from reporting to speculating.
I think almost every number above traces back to one root cause: machines don’t have real identities. They have internal names so that developers and devops people can talk about them, but when it comes to having reasonably canonical identities like we humans do (full name, usernames, an email address, a government-issued unique ID number), we haven’t really created these for machines.
In the absence of machine identities, we have workarounds. On the less secure end, we have IP addresses; on the (relatively) more secure end, there are shared secrets, API keys, long-lived service-account credentials. As with most workarounds, they quietly rot. The credentials we give machines tend to carry more permission than they need. They rarely get rotated. After a while nobody’s entirely sure which agent a given key even belongs to, or why it exists.
Once you’re in that world, everything downstream gets harder. Visibility is hard because you can’t tell one agent’s actions from another’s. Access control is hard because a secret isn’t an identity, it’s some piece of data that happens to belong to a robot (and all too easily duplicated). Auditing is hard for both of those reasons at once. The identity gap is the root problem of most of the other security problems in the AI age.
NetFoundry — who are made of some very smart people, a few of whom are literal greybeards! — obviously has opinions about how to close that gap, and the report gets into them. That’s the vendor part, and you can take it or leave it.
In case you saw the em-dashes in the paragraph above and thought “Aha! AI!’, I assure you that I typed them in myself, because this is my relationship with AI:
Entering em-dashes is dirt simple on macOS: option-shift-minus. On Windows it’s a little more work: alt+0151. On Linux: control-shift-U, then release and type 2014, then return/enter.
Let me have just a couple of em-dashes in my article. Please.
But strip the logo off and the underlying observation stands on its own: we spent a decade giving humans strong identities and largely ignored the machines, and now the machines are the fastest-growing thing on the network. That bill was always going to come due. It’s just arriving faster than most people planned for.
The stat I want ask you about
That 14% attack-surface increase feels low to me. If you’re actually running agents in production right now, watching them spawn sub-agents and reach across cloud boundaries and pick up new tool integrations every sprint, does 14% over a year match what you’re seeing, or is it wildly optimistic?
(That’s a genuine question, not a rhetorical one. I’d rather hear it from people living it than trust my own gut.)
Read the full 2026 State of Secure AI Access report!
It’s written by Tod Burtchell, Associate Director Service Planning & Development in Management & Operations Platform (long title, dude!), whom I had the pleasure of meeting at a planning meeting last week.
Most API security spend goes into inspecting inbound traffic (WAFs, rate limiting, an API gateway parked out front), and all of it inspects traffic that has already arrived at your infrastructure. The exploit is already inside the door even before the door can do anything.
The general gist of the article leans on NetFoundry CEO Galeal Zino’s earlier article, Squaring the Circle: How to Make Public APIs Private, where he describes APIs as “snowflakes”. They’re snowflakes in the sense that they’re always changing, and each change quietly opens a new attack vector that signature-based defenses haven’t seen yet.
The tl;dr: Hardening the front door is one thing, but why not remove it instead? Picture and API with outbound-only connections, no listening ports, and identity-and-auth before anything connects. As a result, the API stays usable for the people who should reach it and is simply invisible to everyone else. OpenZiti is the open-source plumbing underneath if you want to see how it actually works.
I thought I’d make another “back of the envelope” diagram showing the difference between the usual way of building APIs, and the OpenZiti-powered outbound-only approach.
I drew the illustration above on the back of an actual envelope (one of my new “things” these days). It’s either the most or the least appropriate medium for a diagram about attack surface. Your call.
You’re probably seeing this happening around you: teams are wiring AI agents up to their CRMs, databases, and internal APIs through Model Context Protocol servers, because MCP makes it easy. What almost nobody is asking, and what security teams usually can’t even see, is whether the way they’re connecting those servers is quietly creating a new attack vector. In most of the deployments NetFoundry runs into, it does.
The cartoon is Mark’s “before and after,” in three panels. The first two are how nearly everyone connects an MCP server today. The third is what he argues you should be doing instead.
1: Public MCP (a.k.a. “door open to anyone”)
You publish the MCP server on a public hostname, stick a load balancer in front of it, and rely on an API key or an OAuth token to authenticate the agent.
If that gives you déjà vu, it should. This is the exact pattern we all used for REST APIs back around 2012, and it carries the exact same flaw. The server is reachable by anyone on the internet who can enumerate the endpoint or get their hands on a credential. It has to be reachable, because the agent needs to find it. Which means so does everybody else.
That’s the evil bot in the corner going “poke poke.” He doesn’t need to be clever. He just needs the door to exist.
2: Jump host inside (a.k.a. “one session pivots to all”)
“Fine,” you say. “We’ll keep everything internal. Run the agent on a jump host or a dedicated VM inside the network, nothing exposed to the public internet, problem solved.”
Except now you’ve traded one problem for a subtler one. That agent is the thing that’s calling an external LLM, ingesting user-supplied prompts, and taking actions across a dozen connected tools. It’s also now sitting on a trusted internal segment with network-level reach to systems far beyond what it actually needs. Compromise a single agent session and you’ve got a pivot point. One hop to the CRM, one hop to the database, one hop to the internal APIs.
That’s the middle panel: the agent with arrows fanning out to everything. One session pivots to all of them.
3: Outbound only (a.k.a. “don’t call me, I’ll call you”)
Here’s the fix, and the almost annoying thing about it is that it isn’t new. It’s the same outbound-only, identity-bound, least-privilege model that zero trust has been asking for all along. What’s new is applying it to the one connection (agent to MCP server) where none of your existing controls (firewalls, WAFs, network segmentation) actually operate.
The MCP server lives on a private subnet with no inbound connectivity. Instead of the agent reaching in to find the server, the server dials out to meet the agent through an authenticated, encrypted tunnel. There’s no public address to enumerate, no port to probe, nothing sitting there waiting to be found.
Or, as my little pencil agent puts it: don’t call me, I’ll call you.
That line did more work in one speech bubble than a paragraph of my prose could, which is a humbling thing to learn from a robot you drew yourself.
The part that isn’t about doors at all
The panels are the fun part, but the argument I’d actually push you to sit with is why this isn’t just an API-gateway problem wearing a new hat. Mark lays out three things MCP changes that break the old assumptions:
The client is autonomous. An AI agent doesn’t just call an endpoint. It decides which endpoints to call, in what order, with what parameters, based on reasoning you can’t fully predict or constrain up front. So your attack surface isn’t “the MCP server.” It’s the full action space of every tool that agent can touch, across every session it runs.
The session context carries risk. MCP servers receive the agent’s reasoning context right alongside its tool requests. If an attacker can inject content into that context (prompt injection in a document the agent reads, a poisoned result from an earlier tool call, a malicious server the agent got pointed at) they can influence the next tool call in the same session. The MCP connection is the channel that influence travels down.
The inventory is invisible. Most organizations have no systematic way to know which MCP servers their teams have already stood up, which agents are connected to them, or what those servers can reach. If “shadow API” gave you a twitch a decade ago, meet shadow MCP. It’s the same problem, but building up considerably faster.
That speed is the whole thesis, really. The API security industry got the better part of ten years to retrofit controls around a pattern it shipped before it fully understood. MCP is running the same curve compressed into months. Nobody’s getting ten years this time.
So what do you do with this?
If AI-agent security is landing on your desk right now, the uncomfortable truth in Mark’s piece is that the architecture decisions your developers are making this quarter are the ones that’ll be expensive to unwind later. A dev who wires an MCP server to your production CRM through a public hostname isn’t making a temporary choice. They’re setting the pattern every future agent deployment quietly copies.
The good news is that the fix is boring and well-understood. Outbound-only. Identity bound to the connection. Every session governed and observable. Panel 3, basically.
If you’ve been building anything with agents in the past year, you already know the shape of the problem even if you haven’t named it: you’ve got a model in one cloud, a vector store in another, a tool server somewhere on-prem, an MCP gateway facing the public internet, and a handful of A2A flows stitching the whole thing together. It works. Better than that, it’s exciting!
Let me say this as someone who’s spent a few years in cybersecurity and the last couple of weeks elbow-deep in OpenZiti: the AI systems that we’re implementing are built on a network model that was designed before any of this stuff existed, and that network model hasn’t kept up with what we’re doing today.
The core argument that Philip makes in his presentation is one I think every developer working on agentic systems needs to internalize, regardless of what they’re shipping on top of:
The traditional internet model lets you connect first and authenticate second. Agentic AI breaks that model so badly that we can’t pretend anymore.
Let me walk through why.
The exploit window has collapsed, and AI is the reason
Tap to view at full size
Philip opened with this knowledge bomb: the median time-to-exploit for newly disclosed vulnerabilities has dropped from days to hours.
AI has joined the Red Team. There’s AI-assisted reconnaissance, AI-assisted fuzzing, AI-assisted exploit synthesis, and more. Every part of the attacker’s pipeline is getting the same productivity boost the rest of us are getting from Copilot and Claude. The asymmetry is brutal. Defenders have to be right about every service they expose, while attackers only have to be right about one.
The LiteLLM supply-chain incident is a useful recent example. An exploit got injected upstream, and because the compromised library ran in environments where it could see them, attackers walked off with SSH keys, Kubernetes tokens, cloud credentials, and the rest of the usual environment-variable buffet. None of that would’ve happened if the service running LiteLLM wasn’t reachable from the place the attacker was sitting. Reachability was the precondition for everything else that went wrong.
In most “AI security” conversations, the talk is about the model: prompt injection, jailbreaks, output filtering, runtime guardrails, and so on. These issues matter, but there’s a much more “boring” question that’s worth asking…
Can the attacker even get a packet to your service in the first place?
If the answer is “yes”, all the model-layer controls in the world are working with their hands tied.
Reachability is the problem
Here’s the structural issue Philip kept circling back to, and it’s worth stating plainly because we’ve all just internalized it as how computers work:
The traditional networking model allows connectivity before authentication.
In your standard server application, you open a port. Clients, including ones that have no business knowing the server exists, sends SYN. The server completes the handshake, and then it asks the client “Who are you?”
By the time a malicious client is answering that question, the people behind it have already fingerprinted your TLS stack, learned your server software, probed for known CVEs, and maybe even identified an exploit they’d like to try.
This is fine for, say, a public web server that genuinely wants to be discovered by anyone. It is wildly inappropriate for an internal MCP gateway, an LLM endpoint scoped to a specific agent, or an A2A flow between two services that should have no business talking to anyone but each other.
There’s a reason bouncers check for ID while you’re still outside the nighclub.
Philip’s metaphor for this is…Hogwarts. Because of course it is.
Imagine if any random Muggle could walk up to Platform 9¾, see the magical world clearly visible behind a flimsy enchantment, and start poking at the bricks to figure out which sequence opens the wall. The whole point of the wizarding world’s security model is that Muggles don’t even know it’s there. Reachability is the threat. Once something is known to exist, it’s only a matter of time before somebody works out how to get in.
Most of our infrastructure today is like Hogwarts with a “Muggles Keep Out” sign on the gate. Everyone can see it. Everyone can probe it. We’re hoping the lock holds.
The identity-first approach
Tap to view at ffull size.
The inversion Philip proposes is something that NetFoundry’s OpenZiti project actually implements. It’s straightforward to describe and surprisingly hard to undo once you’ve seen it:
Strong cryptographic identity comes first. Every agent, every service, every endpoint gets a unique, attestable identity. Not a shared secret. Not a long-lived token someone copy-pasted into an env. An actual cryptographic identity tied to the workload.
Authentication and authorization happen before any data plane exists. No TCP handshake. No UDP packet. No DNS resolution that even confirms the service is real. If you don’t have a valid identity for this specific service under the current policy, there is nothing on the network for you to interact with.
Reachability is granted, scoped, and revocable. A policy says that identity X can talk to service Y for purpose Z. Change the policy, change the reachability. No firewall ticket. No VLAN reshuffle. No RMF package update.
Here’s the phrase that Philip used:
Connectivity should be an outcome of policy.
It shouldn’t be a prerequisite. That’s the difference:
In the traditional model, the network is a thing you build first, and then layer controls on top of it.
In the identity-first model, the network only exists between identities that have been explicitly authorized to see each other. Everything else is dark.
Tap to view at full size.
For agentic systems specifically, this matters because the topology is insanely fan-out. An agent may need to call three LLMs, four tool servers, two vector stores, and a partner organization’s API in a single workflow. Each of those is a trust boundary:
In the traditional model, every one of those flows is a potential firewall rule, a potential exposed endpoint, a potential lateral-movement path if something upstream gets popped.
In the identity-first model, each flow is a policy, and only the policy-permitted flows have any network presence at all.
The developer-velocity argument
Sure, the security argument is the headline, but if you’ve ever worked anywhere with a serious change-management process, the velocity argument might land harder.
Philip mentioned someone he’d recently spoken with who was building a new service. The platform supported outbound 443. The service needed thirty different ports. Each port change was a firewall ticket. Each ticket was an RMF update. The math on that timeline is grim, and it’s grim in commercial environments too. Anyone who’s tried to get a new outbound rule through a Fortune 500 change board has stories.
In a network where reachability is governed by policy on top of identity rather than by plumbing at OSI levels 3 and 4, that whole category of friction collapses. You’re not asking the network team to change the network. You’re updating a policy that says “this identity can now reach this service.” The underlay (your VLANs, your security groups, your jump hosts) doesn’t have to know or care.
Oh, and in case you don’t remember your OSI levels, here they are, illustrated with cats:
(Layers 3 and 4 are the network and transport layers.)
The downstream effects compound:
Telemetry gets quieter. When the only traffic that exists on a path is authenticated, authorized traffic, your SOC stops drowning in scan noise from the open internet. The signal-to-noise ratio on alerts goes way up.
Credentials simplify. No more shared service tokens that everybody on the team has a copy of. Identity is per-workload, scoped, and revocable.
The underlay becomes boring (and in security, boring is good). You can run the same workload across satcom, LTE, hotel Wi-Fi, and a hyperscaler VPC, and the security posture doesn’t change. The overlay handles it.
That last point matters more than it sounds for AI work specifically. Agents don’t sit in one tidy network segment. They reach across clouds, across organizations, across SaaS boundaries. Trying to enforce zero trust by keeping all that traffic inside a controlled underlay is a losing battle. Enforcing it at the identity layer means the underlay can be anything.
Where’s this going for agents?
Tap to view at full size
In his talk, Philip mentioned Cloud Security Alliance work, building a reference architecture for agentic systems on top of identity-first connectivity. It’s taking on this shape:
Foundation: cryptographic identity and attestation. Every agent proves what it is before any path exists.
Reachability: policy-driven, identity-scoped, no ambient network presence.
Authorization: agents see only the tools, models, and data their policy permits. No tool discovery for things they’re not allowed to touch.
Governance: human-in-the-loop for high-risk actions, audit trails tied to the cryptographic identity that took the action.
The thing I like about this stack is that the Foundation layer fixes the boring-but-fatal problem (reachability), which lets the upper layers actually do their jobs without being constantly undermined from below. You can have the world’s best prompt-injection defenses, and they don’t help you if your tool server got pwned because somebody port-scanned it from the open internet.
What you should take away if you’re a developer
It’s the middle of my third week at NetFoundry, and I’m still in the “drinking from the firehose” phase, where I’m interalizing these things:
If your threat model says “we’ll catch them at the application layer,” update your threat model. The exploit window is too short for that to be the only defense.
“Is this service reachable from where the attacker is sitting?” is the first question, not the last. If the answer can be “no,” make it “no.”
Identity-first is not a product category you buy. It’s a property your architecture either has or doesn’t. You can get there with OpenZiti, with various commercial overlays, with SPIFFE/SPIRE for the identity piece, with combinations. The label matters less than the property. (But hey, I’d love it if you went with OpenZiti, and double if you tell NetFoundry you heard about it from me!)
The biggest unlock isn’t security, it’s that you stop spending your week filing firewall tickets.
Philip closed with a line that I think is the right one to leave on, paraphrased: any sufficiently advanced security model looks like magic. In this context, magic means the thing you’re trying to attack isn’t there. That’s the bar. Not “well-defended.” Not “hardened.” Not visible at all unless you’ve already proven who you are.
For agentic AI, where the speed of attack and the fan-out of the topology are both moving in directions that make traditional networking less viable every month, that bar is starting to look less like a nice-to-have and more like the only model that actually scales.
If you want to dig in: the OpenZiti project is open source and a reasonable place to get hands-on with what identity-first overlay networking actually looks like in practice.
Last week was my first week at NetFoundry, where I’m the Senior Developer Advocate. It was fun, and it was also like drinking from a high-tech, encrypted firehose!
To mark the occasion, I sat down with NetFoundry’s Head of Developer Experience (and also developer; he does a lot!) Clint Dovholuk for my first episode on Ziti TV. We spent an hour diving into the “meat” of Zero Trust, networking architecture, and why your traditional VPN might be the “castle and moat” that finally (and unintentionally) lets the invaders in.
If you’re a developer who has always viewed networking infrastructure as someone else’s problem (and as a recovering mobile developer, I’m certainly guilty on that charge), here’s the deep-dive breakdown of what I learned in my first week on the job.
Clint said that Zero Trust might be better understood if you called it Explicit Trust. In the old “Castle and Moat” model, if you’re in the castle, you’re trusted. In the OpenZiti model, we assume the network is already compromised. You have zero privileges until they are explicitly granted based on:
Authentication: “Who are you?”
Authorization: “What are you allowed to do?”
A lot of resources will authenticate and authorize you through some kind of sign-in process. Clint describes OpenZiti as moving the process out by one layer into the network so you can’t even connect to an OpenZiti-protected resource without being authenticated and authorized first.
Or, to quote Clint:
With OpenZiti and Zero Trust, if you have a service that’s protected by OpenZiti, you first need to authenticate to the OpenZiti overlay network, and then you need to have an authorization that permits the operation you’re trying to perform.
OpenZiti also uses a Zero Privilege approach. Once again, to quote Clint:
The whole idea is that you have no privileges until you are granted privileges, and only then are you able to take whatever operation you want.
“Jay double-you tee” vs. “Jawt”
Apparently we’re on different sides of this debate. Clint prefers referring to JWTs as “Jay double-U tees,” while I prefer to call them “Jawts.”
OpenZiti and NetFoundry: How are they related?
OpenZiti is the network overlay project, and NetFoundry is the company behind OpenZiti.
The “Open” in OpenZiti comes from the fact that it’s an open source project. This is in keeping with the philosophy that a cybersecurity product should be open source because making source code publicly visible enables a community of developers, analysts, and other experts to audit, test, and improve it.
If you have the time, tech skills, and inclination, you can use OpenZiti and run your own overlay network at zero cost — if you don’t count the cost of said time and tech skills. It’s all up for grabs here.
However, if you’d rather spend your time and technical expertise elsewhere, especially once your needs get up to scale, such as on your main line of business, NetFoundry is here to provide you with a managed OpenZiti platform.
It’s easy to run one controller and two routers on your laptop. But when you’re an enterprise managing a fleet of routers, handling upgrades, and monitoring metrics, you’re suddenly in the “overlay business” instead of your actual business. NetFoundry is the “Easy Button” that manages OpenZiti for you [19:10].
The quickstart
Clint then gave a quick demonstration of the OpenZiti quickstart, which creates a fully functional OpenZiti network overlay on your system in a couple of seconds. This overlay has both a router and a controller, and each has a specific job.
Controller
The OpenZiti controller [24:36] serves as the brain of the overlay network. It’s the authority responsible for managing the state of the environment and ensuring that all connections are secure and verified before traffic ever flows.
Its responsibilities can be broken down into several key functions:
1. API surface and management
The controller surfaces several critical APIs that different components of the network interact with. These include:
Edge Client API: Used by SDKs and tunnelers to authenticate and discover services.
Management API: The interface used by administrators (often via the Ziti CLI) to configure the network, such as creating new identities or defining service policies.
Fabric and OIDC APIs: Used for internal mesh communication and identity provider integration.
2. The authority on explicit trust
The controller is the primary decision-maker for the two pillars of Zero Trust security:
Authentication: It verifies the identity of any user, device, or “workload” attempting to connect (answering “Who are you?”).
Authorization: It checks configured policies to determine exactly what that identity is allowed to access (answering “What are you allowed to do?”).
Unlike a traditional network where a firewall might be open by default, the controller ensures the network is dark by default. No connection is permitted until the controller has explicitly authorized it.
3. Bootstrapping trust, a.k.a. enrollment
The controller is the starting point for bringing new devices into the fold through a process called “Bootstrapping Trust”.
It issues One-Time Tokens (OTTs) (essentially signed JSON Web Tokens) that are delivered to users.
When a client initiates enrollment, the controller validates the token and facilitates a Certificate Signing Request (CSR) exchange.
The end result is a strong, cryptographically verifiable identity that the client uses for all future secure communications.
4. Orchestrating the mesh
While the controller does not actually handle the data traffic (that is the job of the routers), it provides the “map.” It coordinates with the edge routers to broker data channels, ensuring that when a client “dials” a service, the routers know how to steer that traffic to the correct destination.
Router
The OpenZiti router [26:09] is the workhorse of the network. While the controller acts as the brain and makes policy decisions, routers constitute the data plane: the actual infrastructure that moves bits from point A to point B.
According to Clint, the router’s job can be broken down into these core functions:
1. Forming the mesh overlay
The routers are responsible for creating the “mesh overlay network”. Unlike a traditional hub-and-spoke networking model, these routers connect to one another to form an interconnected fabric. Even if you start with just one router, you can deploy many others to extend this mesh.
2. Brokering data channels
The primary job of a router is to broker data channels. When an application wants to send data, the router facilitates the creation of a secure path. It effectively “steers” the traffic through the mesh to ensure it reaches the intended destination router and, ultimately, the target service.
3. Serving as the entry point for clients
Everything in OpenZiti is technically an SDK client, whether it’s a standalone app or a “tunneler.” These clients connect directly to the routers to form the necessary channels for communication. The router acts as the listener that accepts these connections once the controller has given the “okay.”
4. Shuttling the actual data
The router is where the heavy lifting happens. It is the component that actually sends your data from one side to the other. While the controller handles the logic of authentication and authorization, it never touches the application data itself. That task is handled entirely by the routers.
5. Enforcing the “dark network”
By acting as the only point of entry into the mesh, routers help enforce the “dark by default” philosophy. Unless a client has been explicitly authorized by the controller, a router will not broker a channel for it, effectively keeping the protected services invisible to the public internet, and by extension, unauthorized and malicious parties.
The coolest part for a developer? You can spin this all up on your local machine in about seven seconds with a simple ziti edge quickstart [23:00].
Why not just use a VPN?
One of my questions was the one every developer asks: “Why can’t I just use a VPN?”
Clint insists that an OpenZiti overlay actually is a VPN [34:05] in the broadest sense, in that it’s a virtual network that’s closed off to unauthorized parties. It just functions much differently than the “one big mush” of traditional VPNs, which are open by default, and once you’re in, you can see everything.
On the other hand, OpenZiti is dark by default [35:45]. If you have a server on the open internet, it usually has an open port (such as port 22 for SSH or 443 for HTTPS). With Ziti, you close those ports entirely. The service becomes “dark,” and the ports are invisible, and you can’t attack what you can’t even find.
The “magic dance” of bootstrapping trust
I’ll admit, when I first tried to set up a client and server, I got a little lost in the “magic dance” of certificates. Clint called this process bootstrapping trust [38:47].
It starts with a One-Time Token (OTT), which is a signed JWT, and the process goes like this:
The admin creates an identity on the controller [41:09].
The client uses the token to find the Controller’s URL [43:11].
The handshake takes place, where the client verifies the controller’s certificate, and they exchange a CSR (Certificate Signing Request) [44:43].
Strong identity: The result is a JSON file containing a key that must be protected like a secret.
AI Agents and the MCP Gateway
We also took a detour into Agentic AI. Clint has been using MCP (Model Context Protocol) Gateways to let Claude interact with the Ziti CLI.
The breakthrough here is efficiency and security. By using an MCP Gateway, you don’t have to give your raw credentials to the AI [57:02]. Plus, by using a targeted MCP server, you can strip a massive 100k data object down to a 10k summary, saving a fortune in tokens [59:12].
Real-world use: From blue bubbles to drones
I asked Clint who is actually using this in the wild. The “Adopters” list is growing, including projects like Blue Bubbles (the tool that brings iMessage features to Android) [50:33].
But the stakes get higher. We discussed Zero Trust Drones and secure communications on the battlefield [52:12]. When you’re in a high-stakes environment like Ukraine, having secure, “dark” comms is a necessity, not a luxury.
More coming soon!
This was the first of many Ziti TV livestreams featuring Clint and Yours Truly. The next one’s scheduled for Friday, April 30th at 11:00 a.m. U.S. Eastern / 8:00 a.m. U.S. Pacific / 1500 UTC, and you can view past livestreams in the Live section of the OpenZiti YouTube channel.
Today is my first day as Senior Developer Advocate at NetFoundry, the company behind OpenZiti.
I am thrilled, slightly jet-lagged from the onboarding reading, and (because some things never change)my accordion is within arm’s reach of the desk. If you are going to explain zero trust networking to developers, you might as well have an accordion-powered rock and roll backup plan.
This is the post where I tell you what the job is, what the product is, why the name makes me smile, and why I think this is going to be a good couple of years.
The short version
I am joining the team that invented and maintains OpenZiti, an open source zero trust networking platform. My job, alongside my colleague Clint, is to be the developer-facing voice of the project: write code, build demos, ship tutorials, show up in the communities where the conversations are actually happening, and make sure what we hear from developers gets back to the product and engineering teams in a form they can act on.
The timing is interesting. NetFoundry recently announced NetFoundry for AI, an AI-focused use of the platform aimed squarely at the problem every AI team is quietly panicking about right now: how do you let AI agents, MCP servers, and LLMs talk to each other and to the rest of your infrastructure without turning your network into Swiss cheese?
More on that in a minute. First, the name.
What is OpenZiti, and why is it called that?
The “ziti” in OpenZiti comes from “ZT”, as in “zero trust”. Say “Z-T” out loud a few times, let the letters slur a little, and you end up somewhere in the neighborhood of “ziti.” Then somebody noticed that ziti is also a tubular pasta, and because developers are developers, that became the visual identity. The OpenZiti logo is, essentially, a piece of pasta. I respect this deeply. My last employer’s mascot was a twerking login box. My current employer’s mascot is a delightfully cheesy, tasty dinner.
This also explains this cryptic comic I posted on my socials earlier, as a hint about the new job:
By the way, the rightmost pasta in the comic is a slouching ziti. Also, in case you need a quick explainer, here’s a helpful infographic:
Infographic from Sip Bite Go. Click to see the source.
The “Open” part is the substantive half of the name: OpenZiti is genuinely open source, Apache 2.0 licensed, and the whole thing lives in public on GitHub. You can pull it down right now, stand up a controller and some routers on your own hardware, and have a zero trust overlay network running on your laptop by lunchtime. (I know this because that is literally what I am doing this week as part of my onboarding. More on that later too.)
So what does it actually do?
Here is the mental model I am starting with, and I reserve the right to refine it as I get deeper in:
Today’s network model is “castle and moat.” You put a firewall around your stuff, you open ports for the services that need to be reachable, and you hope the bad guys don’t find a way through the gate. When they do (and they always do) they are inside the castle with the crown jewels.
Zero trust flips this. Instead of trusting the network, you trust identity. Every connection is authenticated, every connection is authorized, every connection is encrypted, and nothing is reachable just because of where it is on the network.
OpenZiti is the overlay that makes this practical. It gives every app, service, device, or agent a cryptographic identity, routes their traffic through a mesh of routers that only accept authenticated connections, and requires no open inbound firewall ports. This is the part that makes network engineers do a double-take. Nothing listens on the public internet. Attackers can’t port-scan what isn’t there.
If you have ever been the person who had to file a firewall change ticket to let service A talk to service B, and then waited three weeks and filled out a compliance form, you already understand the appeal.
The AI angle, which is where I am spending a lot of my first year
Here is the thing about AI agents and MCP servers: they are, architecturally, the worst possible citizens of a perimeter-based network.
They need to talk to a lot of things. They hold API keys. They get spun up and torn down on timelines that do not match anybody’s firewall change window. They are, by design, non-human identities with significant privileges, and most of the infrastructure around them was designed for humans with laptops.
NetFoundry for AI is the pitch for applying OpenZiti’s identity-first model to this mess:
A zero trust enclave for your users, agents, MCP servers, and LLMs, so none of them are reachable over the open network
Strong identities for the non-human participants (agents and MCP servers have been running around with service accounts and bearer tokens for too long)
API keys and service credentials held separately from the agents themselves, so a compromised agent isn’t also a compromised credential vault
Token tracking, cost accounting, and LLM routing across multiple providers, because once you have the identity layer you might as well use it to see what is happening
If you have been reading Global Nerdy for a while, you know the pattern. I spent three and a half years at Auth0 explaining OAuth 2.0, OIDC, and identity to mobile developers who would rather do literally anything else. The work was: take something that sounds like a standards committee threw up on a whiteboard, anchor it to a problem the developer actually has, and give them working code that does not require them to read 400 pages of RFC.
Zero trust networking is the same shape of problem. The concepts are genuinely hard. The vocabulary is dense. Most developers have never had to think about overlay networks before. But the underlying motivation, “I don’t want my AI agent’s API key to become somebody’s weekend project,” is something every builder can feel in their bones.
And some of you might remember my monthly Tampa Bay AI Meetup, which is now sitting around 2,200 members. The through-line of that community has been the same thing I am now getting paid to do full-time: take genuinely complicated infrastructure and make it feel approachable. Zero trust for AI agents is squarely in that Venn diagram.
What happens next
For the next little while, the plan is mostly “shut up and build.” I am standing up OpenZiti from scratch on my own hardware, embedding the SDK in a demo app, running MCP Gateway with Claude Desktop and a couple of backends, running LLM Gateway with a local model and a commercial one, and lurking in every community where OpenZiti and MCP get talked about. No hot takes until I have earned them.
After that, the usual Joey stuff: blog posts, short demo videos, office hours, and actual conversations in the places where developers hang out: r/openziti, r/mcp, the OpenZiti Discourse, and wherever else the work takes me.
If you build on OpenZiti, or you have been curious about it, or you just want to commiserate about explaining infrastructure to developers, my DMs are open. I am @AccordionGuy on GitHub, Joey de Villa on LinkedIn, and the accordion is here if anyone wants a rock cover of something topical as a celebratory interlude.
