Case Study - Building a vault nobody can open alone. Notes on Helix Vault, and the design decisions we'd defend

We can't tell you who uses Helix Vault.

And there's a very good reason for that. 

When you're trusted to protect someone's most sensitive information, the last thing you should do is advertise whose information you're looking after.

A list of clients could become a list of potential targets. So, while Helix Vault is already in use, we don't publicly identify the people or organisations relying on it.

The same thinking applies to how we've built it. 

We're happy to explain what Helix Vault does, how its security principles work and why we've made certain design decisions. We believe anyone trusting us with valuable information deserves to understand how it's protected.

What we won't share are the specific technical details that could help someone get around those protections.

Good security shouldn't rely on keeping everything secret. But there's no sense in handing someone the keys to the front door, either.

Where it started

We were already managing the social media presence of a well-established artist. That work led us to develop VelvetRope, our AI-powered reputation protection platform, designed to control what reaches an artist's public-facing social media accounts.

But while we were protecting what came in from the outside, we discovered another problem: how do you protect everything that's already on the inside?

Passwords. Account details. Legal documents. Contracts. Years of valuable information that needed to be kept safe, but also needed to remain accessible when the people responsible for it were no longer around.

It raised some important questions: Who actually controls this information? Who can access it? And what happens if the one person who knows where everything is suddenly becomes unavailable?

It's a problem that affects far more than the entertainment industry. Law firms, businesses, management companies and family estates can all find themselves in the same situation.

Important information ends up scattered across emails, spreadsheets, shared drives or, worse still, stored entirely in someone's head.

That last one is particularly dangerous. 

If your business continuity plan is "Bob knows the passwords," Bob isn't the IT department.

Bob is a single point of failure with a lanyard.

The biggest security risk isn't always a hacker

When we think about protecting sensitive information, we tend to think about hackers breaking into systems and stealing data.

That's why most secure storage products talk about encryption. And encryption is important. It makes stolen information unreadable to anyone who doesn't have the right keys.

But there's another problem that encryption alone doesn't solve.

What about someone who already has access?

Think about a trusted employee who leaves the company but still has working login details. A manager who accidentally shares something confidential. Or an IT administrator who can access every password, document and account simply because the system gives them that authority.

These aren't necessarily people with bad intentions. Sometimes they're simply people making mistakes, working under pressure or being given more access than they actually need.

And that's where the real risk lies.

If one person can access everything, that person becomes a single point of failure. It doesn't matter how securely the information is encrypted if one set of credentials can unlock it all.

When we started designing Helix Vault, we wanted to approach the problem differently.

Rather than simply asking, "How do we keep people out?", we asked:

"How do we make sure that nobody can access sensitive information entirely on their own, including us?"

That became one of the fundamental principles behind Helix Vault, and it shaped every decision that followed.

Decision 1 - Encrypt twice, under separate control

Imagine putting something valuable into a safe, locking it, and then placing that safe inside another locked safe.

That's essentially how Helix Vault protects your information.

Before sensitive information even leaves your computer or device, it's encrypted. When it reaches Helix Vault, a second, completely independent layer of encryption is added.

The result is information protected by two separate sets of keys, controlled independently.

Neither layer can be unlocked by one party acting alone.

Even though we provide and manage the Helix Vault service, we can't simply open a customer's vault and read what's inside. We don't hold everything needed to unlock both layers.

And that's an important distinction. It's not just a promise that we won't look at your information. We've designed the system so that we can't access it independently.

There's another detail worth explaining:

1. Many people are familiar with the six-digit security codes generated by authentication apps when signing into an account.
2. In Helix Vault, those codes are used to verify your identity when you log in. They're not the keys that encrypt or unlock your information.
3. So even if someone manages to obtain your authentication code, that alone won't give them access to the information stored inside the vault.

Logging in proves who you are. Unlocking protected information requires much more.

Decision 2 - Bind the vault to its environment

Imagine someone stealing an entire safe, taking it home and discovering that it can no longer be opened because it's no longer in the building it belongs to.

That's the thinking behind another of Helix Vault's security features.

Every Helix Vault installation is securely linked to the environment in which it was created. Even if someone manages to copy all the encrypted files onto another computer or server, those files cannot simply be opened in the new location.

We have a saying for this: "The vault is the building."

Take the contents out of that building, and all you're left with is a collection of unreadable information.

Of course, there are legitimate reasons why a vault might need to move. A company might:

• change its domain name,
• upgrade its servers, or
• move to a different hosting provider.

With most software, that's a relatively straightforward technical task. With Helix Vault, it's deliberately more involved.

Moving a vault requires approval from the appropriate keyholders and a documented authorisation process. Nobody, including GeekyBee, can simply move it independently.

Yes, that makes things a little less convenient. But it's a deliberate decision.

If someone steals a copy of your vault, they shouldn't also steal the ability to open it.

Decision 3 - A second pair of eyes, but not just anyone

Having permission to access sensitive information is one thing. Being able to access it whenever you like, without anyone else knowing, is quite another.

That's why Helix Vault requires a second person, known as a witness, to approve requests to view protected information.

When someone requests access, their witness receives a notification on their own device. They can approve or reject the request, but importantly, they never get to see the information themselves.

And here's where we've taken things a step further.

The witness must be someone who doesn't have access to that section of the vault.

Imagine someone in the Accounts department needs to retrieve a sensitive password. Their witness must be someone who doesn't have access to the Accounts section.

Why does that matter?

Because if two people from the same department are constantly approving each other's requests, it can quickly become a habit.

"Can you approve this for me?"

"Yeah, sure."

Before long, everyone's clicking approve without giving it much thought.

Helix Vault is designed to prevent that familiarity from undermining security. It enforces the separation rather than simply relying on people to follow a policy.

It's much the same principle used in financial controls: the person approving a payment shouldn't be the same person processing it.

Helix Vault also allows authorised users to update passwords without seeing the existing ones.

"I need to change it" stops being a route to reading it.

Decision 4 - No master key. No single person in control.

Most secure systems have some form of master key or password that can unlock everything.

That creates an obvious problem. If someone gets hold of it, they potentially get access to everything it protects.

We wanted to avoid that entirely.

When Helix Vault is first set up:

• a master secret is created and
• divided into separate pieces, which are
• distributed among a small group of trusted individuals, known as custodians.

The original master secret is then destroyed.

Not stored somewhere for emergencies. Not kept in a backup file. Destroyed.

No single custodian has enough information to recreate it. Recovering the vault requires a specific number of custodians to bring their pieces together and authorise the process.

GeekyBee always holds exactly one of those pieces:

• Not because we're more trustworthy than anyone else, but because we're independent of the people and organisations using the vault.
• We're not sitting in the same office, attending the same meetings or travelling on the same bus as the other custodians.

That separation matters. If something happens to several people within an organisation, our independent share can help the remaining custodians recover the vault.

But there's an important limitation:

• We cannot recover a vault on our own. Neither can any individual custodian.
• If the required custodians and their shares are unavailable, the vault cannot be recovered.

It's a deliberate trade-off. We've removed the convenience of a master key because we believe no single person, including us, should have that much control.

Decision 5 - No shortcuts, even in an emergency

Helix Vault has three levels of access, each requiring a different degree of approval depending on how much information someone needs:

1. Accessing a single item requires approval from one independent witness.
2. Accessing an entire section requires two witnesses: one who has access to that section and another who doesn't.
3. Releasing the entire vault is a much more involved process. Only the designated Vault Master can initiate it, and every member of the approval panel must participate in a specific sequence during a live call. If a step is missed, the process starts again.

And that's it. There isn't a secret fourth option.

No emergency password. No hidden master switch. No special access for administrators, legal representatives or even GeekyBee.

It's a decision that sometimes raises eyebrows. After all, what happens if someone urgently needs access?

But we've always taken the view that "a bypass everyone knows about becomes the real front door."

Introduce an emergency shortcut, and sooner or later someone will use it because it's convenient. Then because it's quicker. Eventually, it becomes the normal way of doing things, and all those carefully designed security measures become rather pointless.

That doesn't mean emergencies can't be handled.

It means the right people need to be available to authorise access through the proper process, even when time is critical.

An emergency shouldn't mean abandoning the security measures that were put there to protect you.

Decision 6 - Nothing disappears without a trace

Imagine discovering that someone accessed a sensitive password or document, but nobody can tell you who did it, when it happened or who gave them permission.

That's not much use when you're trying to protect valuable information.

Helix Vault keeps a permanent record of activity within the system. Every access request, approval, rejection and failed login attempt is recorded:

• And importantly, those records cannot be changed or deleted, even by GeekyBee or someone with administrative access.
• The activity history shows what information was requested, who requested it, when it happened and who approved or rejected it.
• What it doesn't show is the sensitive information itself. Passwords and other protected values never appear in the activity log.

We've taken a similar approach to the information stored in the vault:

• When a password or other record is updated, the previous version isn't simply erased. It's securely retained as part of the history, protected by the same encryption and access controls as the current version.

This means organisations can trace changes and understand what's happened to important information over time.

Because protecting information is one thing. Being able to account for what happened to it is just as important.

What are the trade-offs?

We could tell you that Helix Vault offers exceptional security without any compromises. But that wouldn't be entirely honest.

Every security decision comes with a trade-off, and we've deliberately chosen protection over convenience in several areas:

It's not always instant:

• Accessing sensitive information requires another person to approve the request. That takes a little longer than simply entering a password, but it's also the reason the information is better protected.

Helix Vault isn't intended to store every document or file your organisation owns. It's designed for the information important enough to justify that extra protection.

It's not designed for everyone to access everything:

• Helix Vault works with a small group of trusted keyholders, typically between three and twelve people, with clearly defined responsibilities.
• If you need forty people working on the same document at once, there are better tools for that. And we'll happily tell you so.

Moving a vault takes planning:

• Because each vault is tied to its original environment, moving it to another server or domain isn't simply a case of copying files.
• It requires the involvement and approval of the appropriate custodians. That's intentional, even if it makes migration more complicated.

Recovery requires people, not just technology:

• There's no emergency master password that GeekyBee can use to restore access.
• Recovering a vault requires a specified number of custodians to participate, so organisations need to make sure those people are available when needed.
• That's as much about good planning and responsibility as it is about technology.

Ultimately, Helix Vault isn't intended to be the most convenient way to store information.

It's designed to protect information that's too important to leave under the control of any one person.

And if your organisation doesn't need that level of protection, that's absolutely fine. We'd rather tell you that than sell you something you don't need.

Where it's going

Helix Vault isn't just an idea or a product waiting to be developed. It's already live and protecting sensitive information.

Every customer has their own dedicated vault, their own domain and their own group of authorised keyholders. Their information is encrypted and kept separate from everyone else's.

And we're not stopping there.

We're developing additional protections for valuable documents and digital assets, including technology that can:

• identify who a leaked document was originally shared with,
• trace the source of unauthorised disclosures, and
• control how protected documents can be used or distributed.

We're also exploring ways to protect intellectual property such as voice rights, something that's becoming increasingly important as AI makes it easier to reproduce someone's voice without their permission.

The important thing is that these capabilities are being built on the same security foundations we've already established. Existing installations won't need to be completely redesigned to accommodate them.

Helix Vault was built around a simple principle: information can be valuable enough to protect from outsiders, but too important to leave under the control of any one person.

And that's the principle we'll continue building on.

Helix Vault | helixvault.co.uk

GeekyBee Ltd | geekybee.net | info@geekybee.net