mcpvault

We are live 0xf560e14c75a60a21a50c2f3a7a92f15e8a4595c0

Shipped a lot into Vault today. A trading firewall for AI agents with spend caps, per-token limits, market hours, and a circuit breaker. A simulate-before-sign layer that runs the real swap on-chain and bails if it reverts or gets sandwiched. And every guarded trade now writes a signed receipt to a contract live on Robinhood Chain, which rolls up into a public safety score per tool. Two npm releases out, all tested.

When we started building Vault, it was based on an industry gap we identified. We believe that Agent security won't be based on identity. It doesn't matter if the agent trades or runs a simple task, a verified agent will still drain your wallet if a poisoned tool response tells it to. What actually protects it is a layer that filters everything before it acts. $VLT

Building on Pons? Show us what you are working on.

But within the coming days your very own instance of VaultOS equipped with it's trusty MCP will be able to transform your trading experience.

Vault MCP was the first piece. It protects what agents read. VaultOS will control what agents can do with your wallets, accounts, files, and infrastructure. The goal is simple, give agents power without giving them the keys to everything.

Earlier, we said we’d be shipping constantly over the coming days. That hasn’t changed. But vagueposting “VaultOS” doesn’t give you much to get excited about, so allow us to explain.

Little demo video for our MCP, but I think the best part is that our MCP is just a cog in the machine that is to come under the umbrella of Vault OS...

We just shipped a trading firewall for AI agents that trade on-chain. The problem it solves is simple: when an agent reads data from some tool or website and then places a trade, a bad actor can slip fake instructions into that data and quietly point the trade at their own wallet, and the agent will sign it without blinking. Vault sits between the agent and the actual trade and checks every order right before it gets signed. It blocks a swap going to a wallet you never approved, blocks one that came from untrusted data, caps how much can move in a single trade and how much can move total over a window, caps how much can pile into any one token, throttles how fast trades can fire, and if the agent starts throwing a bunch of bad trades in a row it trips a breaker and freezes trading until things calm down. It even knows market hours, so an agent holding tokenized stocks won't fire orders when the market is closed. The whole thing turns on with one environment variable, it runs locally so your keys and data never leave your machine, and it is live on npm right now as npx @aimcpvault/mcp-proxy@latest.

Our first new feature has been shipped and is one of a dozen to come in the coming days. By devs, for everyone.

Dex has been paid.

One honesty note so you can defend it: the taint guard is real and shipping right now, the semantic version and the on chain trust graph are what we are building toward. Say it exactly that way. The vision is huge and the fact that the first piece already works on chain is what makes people believe the rest.

So the category is not "prompt injection scanner." Scanning is table stakes and we do it today. The category is the provenance and trust layer for agent tool use, and the winner is whoever can prove an action only depended on trusted inputs and make that proof portable across the whole ecosystem. We are already at the right layer, we already have the taint primitive running in production, and we are the only ones treating this as a dataflow problem instead of a text problem.

Then the part that turns it from a feature into a moat. Every verdict and every provenance decision we make is content addressed and cryptographically attested on chain. That turns one proxy's private judgment into a shared, verifiable record. A malicious tool that injects one agent leaves a signed public trail that every other agent can check before it ever connects. The more agents run Vault, the denser that trust graph gets, and the harder it becomes for a bad tool to operate anywhere at all. That is a network effect on safety, and you do not copy it by shipping a better regex.

That is the research we are doing, and it is three things working together. First, semantic taint, where we track provenance by meaning rather than exact bytes, so a value that is semantically derived from tainted content is caught even after the model reworded it. Second, structured mediation at the tool boundary, which we can do because we sit at the MCP layer and see every response and every call, so we can force any argument to a high stakes tool to reconcile against the full provenance of everything the agent has read this session. Third, a split between the data an agent is allowed to act on and the data it is only allowed to read, kept on separate rails, with us as the thing that enforces the rail.

So we track the dataflow. Every byte of untrusted tool output that enters the agent's context gets a provenance label. When the agent later tries to call a sensitive tool, we check every argument against that label graph, and an argument that traces back to an untrusted source gets blocked. This is not a pattern match. It is a soundness property. Nobody paraphrases their way past a rule that does not care what the text says.

Here is the hard part, and the reason nobody has done this at the agent layer. The agent is an opaque model. Untrusted data goes into its context, the model summarizes it, reasons over it, and eventually emits a tool call. Classic taint tracking assumes you can instrument the program. You cannot instrument a language model. The tainted address might come back verbatim, or paraphrased, or rebuilt from pieces.

The insight is that you do not actually need to recognize the attack. For any dangerous action, the only question that matters is: did any part of this action come from data the agent was not supposed to trust? If an agent is about to move funds and the destination address traces back to something that came out of a tool response instead of from the user, that is game over no matter how the instruction was worded. The phrasing is irrelevant. The dataflow is the crime.

We are getting off it.

Content detection is a treadmill. You scan tool output for injection, the attacker rephrases or encodes or buries it, you scan again. You can be very good at it, and we are, but you can never be done, because the attacker always gets the last move. Every prompt injection product on the market is running on that treadmill.

What we're building: a provenance firewall. We stop detecting attacks and start proving safety.