Your postman can’t read your letters. He knows a great deal about you anyway – who writes to you and how often, the envelope from the bank, the law firm, the hospital, the official-looking window envelope. He never opens a thing and could still sketch your month from the outside of your mail.
And he’s only the part you can see. Behind him a sorting system logs every item, and an operator could be asked by a court who sent you what. None of them read the contents. They don’t need to. This is metadata, and the first thing to notice is that it’s old – recording the outside of the envelope is centuries of postal practice, not a new failure of the cloud. Which is the clue that you can’t make it go away. It isn’t a leak someone introduced. It’s how any delivery system works.
The digital version is the same shape with more observers and longer reach. Your data can sit in Frankfurt while the postmarks – who connected, when, how much, to what – go elsewhere, and the postmarks can tell a story the letters were supposed to protect. So the demand you hear everywhere, that no metadata ever leave the jurisdiction, is asking the postal system to forget the outside of the envelope. It can’t. The real question is narrower: which of it would actually hurt you, which you can do something about, and who you’re protecting it from.
Which of it would actually hurt you
Most of it wouldn’t. A health-check ping between two services, a certificate renewing, a routine sync to offsite backup – this is the bulk of what leaves your estate, and it usually tells nobody anything consequential. Treating it as sensitive is how you spend a sovereignty budget on noise.
The metadata that matters reveals a decision before you’ve made it public – and it’s rarely the content of anything. It’s the pattern. A spike in traffic to an investment bank’s domain, three weeks before you announce a deal. A cluster of connections to a law firm and a data room, which is what due diligence looks like from outside. Staging servers lighting up the week before a launch. Nobody read a file. The shape was the signal.
That’s the test, and it’s short. Not “is this metadata” but “could someone infer something we haven’t announced from the pattern of it.” Most metadata fails that test. The small amount that passes is the only part worth architecting around.
Metadata isn’t only about business inference. It can also contain personal data – email addresses, IP addresses or user IDs in logs. When it does, the same legal transfer rules apply as for any other personal data. The observability data most teams never classify is often where this hides.
Which of it you can do anything about
Take what passed the test and sort it into two piles.
Some of it leaks because of a choice you made – a monitoring service aggregating telemetry in another region, a managed database shipping query logs to the provider, an identity system holding the whole picture of who signs in from where. A different choice stops it. This is where sovereignty work pays off: the exposure exists because of an architecture decision, and those can be remade.
The other pile leaks because of connectivity itself, and no decision of yours closes it. Your carrier sees your flows whatever you encrypt, because it’s routing the packets. DNS is observable by design. And private interconnection – the cross-connect you provisioned to get off the public internet – is no exception: any provider running that link can see who connected to whom, and when. But hold the comparison straight, because this is where anxious framing gets it backwards. Interconnection exposes far less than the alternatives, not more – the postmark rather than the letter, provided the letter itself is sealed, and to one party instead of the open internet. You can seal the envelope; you can’t unprint the postmark. The honest goal isn’t a link nobody can observe – it’s the smallest, shallowest exposure available, which is exactly what private interconnection is.
There’s a harder version the moment you want global reach. A provider large enough to connect you worldwide inevitably falls under some jurisdiction – usually one with a long reach, like the US CLOUD Act. A national provider avoids that but can only reach the world through others, which moves the dependency deeper rather than removing it. So this isn’t a bad vendor choice to correct; it’s the price of reaching everywhere.
Sometimes the exposure is the point
There’s a category the anxious framing misses entirely: metadata you publish on purpose, because being seen is the benefit.
A network’s interconnection data – where it’s present, who it’ll peer with, how to reach it – sits in PeeringDB, a public database built so networks can find each other and interconnect. Yes, a competitor can see where you interconnect. That’s not the cost of the system, it’s the system working: the same record that in theory reveals your footprint is, in practice, how a potential peer knows you exist and how to reach you.
It’s the name on the mailbox: publish it and the mail finds you, paint it over and it doesn’t. Try to hide it and you don’t gain sovereignty, you lose reachability. Not all exposure is leakage. Some of what looks like metadata escaping is metadata working, and closing it would cost more than the exposure ever could.
Afraid of whom, exactly?
Everything still standing comes down to one question, asked about each party who holds it: this record exists and someone has it – is that someone a threat to us?
Start with whoever collects it. Your monitoring vendor aggregates your telemetry; your connectivity provider sees your flows. Will they compete with you, or trade on what your traffic reveals? For almost everyone the answer is no – they’re running a service, not reading your strategy – and if it’s no, stop. If it’s genuinely yes – a provider adjacent to your own market – then move it to one that isn’t a rival.
Then the legal reach. Could a government compel the party holding this record to produce it, perhaps without your knowing? Often yes – and the question that matters is the second one: would it hurt if they did? For most of your metadata it wouldn’t. Where it would – where the pattern reveals a deal, a position, a move – you’re into real choices: keep that connection off a compellable provider, hold the record yourself, or arrange things so the revealing pattern never forms in one place.
What to actually do about the part that’s left
By now the pile is small. There are only three moves, and most metadata needs none of them.
Relocate it. If the exposure exists because of an architecture choice, move it – self-host the piece that leaks, and the leak closes because you changed what caused it. This is the pile where effort pays off.
Split it. The sharpest move, and the one people miss. A pattern only reveals a decision when it assembles in one place. Route the connections to the bank, the law firm and the data room so no single party holds the whole shape, and the pattern never forms where anyone can read it. You haven’t hidden any one piece – you’ve stopped them from adding up.
Choose who holds it. For what’s left, put the sensitive connection on a provider who isn’t your rival and isn’t trivially compellable. Same postmark, safer hands.
And for the remainder? Price it in. Everything that survives those three moves is inherent to being connected – the carrier, the postmark, the border you crossed on purpose. You don’t fix these; you accept them, knowing they’re the shallowest exposure available. Buying a guarantee against them is spending on the pile no decision of yours can close.
Sovereign metadata isn’t metadata that never escapes. It’s the small set where three things line up at once – a pattern that would reveal something, a party who holds it, and an adversary who could use it – and the permission to stop worrying about everything else. Which is most of it. The carrier sees your flows, the cross-connect records your connections, the border gets crossed the moment you reach across it. Those aren’t failures to fix. They’re the cost of being connected, and the honest move is to price them in rather than buy a certificate that pretends they’re gone.
Originally published on LinkedIn