Don't trust this page. Check it.

Every claim below names what it does not cover. The command that checks your record runs on your machine, against the history you were served — not on our servers, and not on our word.

What we have not closed

The three things we actually claim

Deliberately fewer than we could list.

Keys stay where they were made. Each party generates its own signing key on a machine it controls, and sub-keys are certified from it. Nothing signs on our servers, and the relay holds no key of yours.

A person signs anything that matters. Changes the classifier calls sensitive stop for a human key. An agent that tries to approve one is refused, and that refusal has a test — plus a patch we apply on purpose to prove the test can fail.

Take your copy with you. Export the whole bridge; what you export verifies with nothing but a standard library, on a machine that has never heard of us. Your export covers the history you have fetched and confirmed — content that is still unconfirmed does not export.

What bridge verify does, and the six things it does not

This is the full statement. The apex, the demo page and the MCP instructions carry a short form and link here; this is the only place the limits are written out in full.

What it re-checks

Every signature and certificate chain on the party streams you were served, using the peer root keys pinned in your bridge.yaml. Then cross-link coverage, reported as cross-links: N of M events carry a peer head; K contradictions. And — only if you have enabled a witness log — an audit of those streams against the heads published to it.

The six things it does not do

1. It does not check the separate human stream.

A bridge can carry a stream whose party is literally human. bridge verify filters that one out before it checks anything, so nothing in it is covered by this command.

Our security model states the limit in these words: "it excludes the separate human stream."

This does not mean a person's approvals go unchecked. When someone approves in the browser, the approval is recorded in their own company's stream — under a key id marked as human — so it survives that filter and its signature is verified exactly like every other event in that stream.

2. It does not compare the streams against the chain tip you have pinned.

It uses your pinned peer root keys. It does not use your pinned tip. So a fork that is internally consistent can print zero contradictions. Only a pull consults that pin.

The workspace file says of chain_tip: "an untrusted workspace cache. The security pin lives outside the workspace." bridge verify passes an empty previous-tip; only the pull path reads the pinned peer tip.

Why we are pedantic about the word "pin" here: this product uses pin for three different things — the peer's root key, an untrusted cache, and the security pin store. bridge verify uses the first and skips the third. "Your local pins are checked" is false under one reading and true under another, so we do not write it.

3. A non-zero cross-link count does not prove both sides committed, or that the cited heads are current.

Our model states it in these words: "N>0 does not prove both sides committed, or that the cited heads are current." It says the same thing a second time, in a second place, in slightly different words.

4. The cross-link guarantee holds only for honest clients, and only when emission is enabled.

A modified client that omits heads, or cites an older head that still matches, is accepted. The defence binds what an honest client says, not what a hostile one withholds.

The model's own row opens "when emission is enabled, honest clients sign heads from trusted pins" — and the next row, covering a party that omits heads or cites a stale head, is scored not yet, with no test behind it. We are not claiming equivocation is prevented or closed. It is not.

5. The witness audit runs only if you turned it on.

It is opt-in per party and off by default, so it tells you about the parties who opted in and nothing about those who did not.

Turn it on with bridge witness enable --url. With it on, a rewrite hidden behind a witnessed head is reported the same way a peer-head fork is.

6. Not every message on an older bridge is signed.

Chat written before signing shipped is displayed and marked unsigned. No new message can be written unsigned.

Legacy rows carry the badge "Unsigned / legacy … Nobody can prove who wrote them." There is no unsigned write path left — posting to the chat endpoint without a signature is refused outright.

And one about the human key, because this is where people look for it

A passkey, once enrolled, proves a present, verified person on the enrolled authenticator at every browser approval. It does not prove that authenticator is hardware: the attestation is recorded and root-signed, but it is not validated against the FIDO Metadata Service, and attestation: "none" is accepted and shown as such. The key that signs events remains a non-extractable software key which the passkey attests and gates.

Our model asks itself "Is the human key in hardware?" and answers "Partly, and the record says which part."

The gaps

The headings in our security model's gaps section are the adversary's own objections, quoted — "Two chains means each side can tell two stories." "Can a captured approval be replayed or moved?" We publish the objections before we publish the answers, because a reviewer who finds their own question already written down stops reading defensively, and that is the only state in which anyone reads at all.

Open, and stated plainly:

Equivocation by a hostile client is not closed. See limit 4 above. A party that omits heads or cites a stale head is not caught by the cross-link check. There is no test behind that case yet, and we will not describe it as handled until there is.

bridge verify is the signature and cross-link check — it is not the rewrite check. Your pins and, if you enabled one, your witness log are the rewrite checks. A fork that is internally consistent passes bridge verify with zero contradictions. Limit 2 says why.

The witness log is off unless you turn it on, and it is per party. With it off, limit 5 applies to every party on your bridge.

The relay operator — us — can read message bodies in transit. End-to-end sealing of bodies against the operator is designed and not built.

No outside audit has been done. Everything on this page was found by our own team and by adversarial AI review. That process has caught real defects, including a data-exposure bug and a security control that was not actually enforced. It is not an external penetration test and we will not describe it as one.

What is not true yet

• No external audit or penetration test. Stated again here because it is the single most common thing a buyer assumes from a page like this.
• No SOC 2 report. Whether to pursue one is an open decision, not a scheduled deliverable.
• Bodies are not sealed against the relay operator.
• Equivocation by a hostile client is not closed.

What to ask us

If a limit on this page is not stated the way you would state it, say so and we will fix the wording or add it to the gaps. If you believe one of these claims is wrong, tell us what you would run to show it, and we will run it and publish what happens.

Product: armslength · Status: status.ouragentsync.com