VaultHelm assumes your AI will eventually be fooled. Not might be — will be. Everything here is built so that when it happens, it doesn’t matter much.
The thing we’re actually defending against
You can hide instructions inside almost anything an AI reads. A line buried in a document. Text in an email. A comment on a web page. The AI reads it as if you’d typed it, and does what it says.
This isn’t exotic or rare. The moment an AI can read your email, browse the web, and open your files all in the same conversation, it’s simply the weather. Any system that treats it as an unlikely edge case is one badly-worded PDF away from a bad afternoon.
So VaultHelm starts from the assumption that your AI can and will be talked into something at some point — and makes sure that being talked into it isn’t enough.
You can change an AI’s mind. You can’t change what it’s able to reach.
Why this isn’t just careful instructions
This is the part worth understanding, because it’s what separates VaultHelm from a well-written prompt.
Nobody tells the AI to behave. There’s no instruction saying “please ask before doing anything important,” because instructions are exactly what an attacker overwrites. Every limit lives on the server, outside the conversation, where the AI has no reach at all.
The practical test: someone sends you a document engineered to hijack your assistant. It works — the AI is fully convinced it should go and change something important. It then can’t, because the ability was never handed to it in the first place. The attacker won the argument and got nothing, because the argument was never what was holding the door shut.
And it can’t promote its own work
Your AI can always write — into a holding area. What it cannot do is move anything out of there and into the real record. That step runs on a separate, higher-trust path, and the assistant that produced the work has no way to reach it.
This is an old idea rather than a clever one: the person who writes the cheque doesn’t sign it. Keeping the two apart means a compromised assistant can fill the holding area with whatever it likes and still change nothing that counts. You review, and it moves because you said so.
Nothing is lost while you decide, either. Staged work sits there indefinitely and stays readable until you accept it, correct it, or bin it.
What’s actually in place
| Concern | What stops it |
|---|---|
| The AI changing something important | It can’t write to anything that matters — its work lands in a holding area. Moving it into the real record takes a separate, higher-trust path that the AI which wrote it cannot invoke, and that only runs when you say so. |
| The AI reaching a tool it shouldn’t | The list it can see and the list it can use are the same list, checked in one place. There’s no hidden menu. |
| One customer seeing another’s work | Separate installations, separate files, separate keys — even though we host them. There is no shared pile. |
| Connections to outside services | Email, messaging, monitoring and the like are each switched on individually, and off by default. |
| Passwords and keys leaking | Hidden when read, never echoed back, never stored in the program itself. |
| Not knowing what happened | Every action your AI takes is logged — who, what, when, how long. The log can only be read, never fed back to the AI. |
| Something going badly wrong | Every version of every file is kept, off-site. Updates check their own backup first and undo themselves if they fail. |
What we’ve tested, and what we haven’t
Most companies show you a list of security features. Here’s ours with an honest third column instead — proven means we’ve actually done it to the running system and watched it work, working means the code is live but we haven’t tried hard to break it yet, and owed means it’s meant to behave that way and we still owe you a real test.
We have not had an outside security audit. This list is the standard we hold ourselves to in the meantime.
| The test | What should happen | Status |
|---|---|---|
| Someone tampers with a pending settings change | Refused and quarantined. Nothing is written. | Proven |
| An update fails partway through | It checks its backup and undoes itself. | Proven |
| The web console tries to edit protected settings directly | Refused. Only one narrow, separate process can. | Proven |
| The AI tries to change something important | Refused, and told where to put it instead. | Working |
| The AI tries to use a tool it wasn’t given | It can’t see it and can’t call it. | Working |
| Someone asks the AI for a stored password | Hidden or refused. | Working |
| The logging breaks mid-job | Your work carries on; the failure is recorded. | Working |
| A booby-trapped document tries to hijack the AI | No password available, no new abilities, nothing changes. | Working — we still owe a proper attack test |
| One installation tries to reach another’s files | Refused at the boundary. | Working — we still owe a proper attack test |
The failure we design around
The thing that has cost us most isn’t a break-in. It’s something quietly stopping and reporting success.
It always looks the same. A job fails but exits as though it worked. An error goes into a file nobody ever reads. A summary silently drops half its content and hands back something that looks fine. A safety check gets written correctly and then never actually runs.
In every case the dashboard stays green while nothing is happening. And green is more dangerous than red, because red gets investigated.
So these are hard rules here, not good intentions:
- Nothing reports success without accounting for what it was given.
- If something got cut short, that’s an error — not a result.
- A safety check isn’t finished until we’ve watched it actually trigger.
- Failing quietly to be helpful is a disguise, not a kindness.
- A protection that’s never run in the situation it’s meant for isn’t a protection.
- A scheduled job that can’t do its work has to fail loudly and then check its own result. “It ran” is not “it worked.”
Websites we host
Where we run a website alongside VaultHelm, one particular door is bricked up rather than guarded. There’s an old WordPress feature that reports “success” even when a password is wrong, and lets someone test hundreds of passwords in a single request. Standard protection watches for failed logins, sees an unbroken wall of apparent successes, and never fires. Blocking it outright is the fix. Rate-limiting it is theatre.
Found a problem?
Tell us at the address on the contact page. We’ll confirm we got it, and if it’s real it goes into the same approvals queue as everything else — which means you can be told exactly what was done about it, and when.