All news

QuantumGuard Is Live on Mainnet

October 2, 2026

Tuesday’s Industry Updates led with Australia’s account of an OpenAI agent that found a way around the blocks on a government website. It was the ninth issue since July with a story about OpenAI’s agents getting somewhere they weren’t supposed to be.

OpenMatter® spent those same months building a boundary to stop exactly that. QuantumGuard™ is now live on MatterChain mainnet, inside the Datavizor™ console. Below is a walkthrough of what it does, screen by screen.



Stay up to date as we build the infrastructure layer for secure AI collaboration:

Subscribe now


OpenMatter is chairing the Decentralized AI Agent Alliance’s Agentic Privacy & Security subgroup. Our next meeting will be held on October 7, 2026, at 1pm EDT, and every other Wednesday thereafter. Please join us.

If you’re curious what DAIAA is all about, you can watch the September 23 meeting to learn more.


QuantumGuard Is Live on Mainnet

A Walkthrough of the Datavizor Console, from the Deploy Form to the Record

One checkbox at deploy puts a boundary around your agent.

An agent has a task. Something stands between it and the task, and the agent finds a way around. Such stories have become ubiquitous this year. QuantumGuard was built to prevent an agent from finding its way into places where it shouldn’t go.

QuantumGuard puts a boundary around the agent that checks everything it sends out, whatever the agent tries and whatever it’s been persuaded to try. You write a policy: the hosts the agent may reach, the credentials used on its behalf, and the settings it’s allowed to see. The boundary checks every outbound request against that policy and records the decision. Every decision goes on a record anyone you choose can check, and each request the boundary allows comes with a proof.

It’s live now in Datavizor, and turning it on is as easy as checking a box.

One Checkbox at Deploy

The deploy form has a new section. Select Enable QuantumGuard, pick a policy, and the form shows what that policy grants before you launch: the hosts the agent reaches, the credentials handled for it, the settings it sees, and what can reach it from outside. Anything that needs fixing is listed right under that summary.

Your app doesn’t change. You deploy the same image you would have deployed anyway, and the boundary goes around it, so an agent that runs unguarded today can run guarded tomorrow.

The Hosts It May Reach

A policy starts with a list of hosts, and that list is the whole permission. A new policy allows nothing by design, so a host you never thought about is a host that’s already refused. You can narrow the policy further by method, port, and path.

The boundary has no interest in why the agent wants to go somewhere else. If a prompt injection talks the agent into contacting a server it was never permitted to reach, the request is checked like any other and recorded as refused. “Did it ever try to reach somewhere it shouldn’t?” becomes a question with an answer.

QuantumGuard runs in two modes. In real-time mode, a request waits for its proof before it leaves. In audit mode, every request is checked and recorded, and nothing is held up while it happens. That makes a strict policy a safe place to start: it shows you every host the agent tries before you decide which ones it needs. Policies show audit mode in the console for now, and a switch between the two is coming to the policy editor.

Keys It Never Holds

When you mark a credential as handled, the agent never receives a key. It gets a stand-in instead, generated fresh each time the agent starts. On the way out, the boundary swaps in the real key, and only on requests to the hosts you scoped it to. The agent works exactly as it would have. It just never holds a real key.

Settings follow the same default. Anything you don’t declare is dropped before the agent starts, so a setting you forget to list is withheld.

One Policy, Many Agents

A policy belongs to your organization. Any owner or admin can edit it, and you can attach it to as many agents as you like. Two agents that should share a boundary can share one policy, instead of two hand-written copies that drift apart.

Datavizor ships six ready-made policies to start from, including these three:

  1. Locked down reaches nothing.

  2. AI agent reaches the model services your organization can route to and your own ModelRouter™ gateway, handing each key only to the service it belongs to.

  3. Via ModelRouter reaches only your gateway, so model traffic is routed and recorded in one place.

Edit a policy, or attach a different one to a running agent, and the agent picks up the change within about 30 seconds. No redeploy. MatterChain records which version each agent is running, so you can confirm the change went through.

A Record You Can Check Yourself

Every allowed or refused action produces its own entry. Each entry records when it happened, what kind of action it was, and whether it was allowed. An allowed action also carries a zero-knowledge proof that it followed the policy in force. The boundary writes the entry, so the agent being watched has no hand in it.

Entries are linked to one another. Remove an entry, reorder two, or change one, and the record fails verification for anyone who checks. As the record loads, your browser confirms that each entry belongs to it. Reading a record needs no sign-in, so you can hand its address to an auditor or a customer and grant them nothing else. A public command-line tool for checking each proof in full is on its way.

The proofs and the log live with the agent, and you can export them to the cloud storage you already use. What goes onchain is small on purpose: the hash of each policy and which version each agent is running. Every proof is verified against that hash. OpenMatter can’t swap in a different policy after the fact, and neither can whoever runs the machine the agent ran on, because the proofs wouldn’t check. Our word isn’t part of the guarantee.

From Believing to Knowing

Four weeks ago we wrote that the agents in the Hugging Face incident got past every safeguard they could reach. QuantumGuard puts every attempt like theirs on the record, and in real-time mode no request leaves without its proof.

QuantumGuard puts the rules outside the agent. The hosts are a list the agent can’t edit. The keys are ones it never holds. The record is written by something it can’t touch but can be checked by anyone you choose. That’s the whole shift, from believing an agent behaved to knowing it did.

Add It to the Stack You Already Run

QuantumGuard fits around the agents you already deploy. A research agent works with confidential data while reaching only approved model endpoints. A customer-engagement agent reaches only the CRM routes its task needs, and its outputs are scanned for the sensitive values you list. Coding, support, and operations agents reach only the repositories, records, and endpoints named in their policies.

The workflow stays the same, and every policy decision goes on the record.

Don’t trust data. Prove it. Open Datavizor, go to QuantumGuard, and duplicate Locked down. Then add the hosts your agent needs, one at a time.

— The OpenMatter Team


If you know someone who would benefit from reading this article, please share it:

Share


OpenMatter is building the verifiable policy and evidence layer for governed AI agents. If your organization needs to control agent access, protect credentials, or produce independently verifiable activity records, contact our team.