Trust Rails for Agents

Your agent reads an inbound email and pulls out an account number. It also looks one up in your own vendor registry. Both are strings. Your type system cannot tell them apart, your payment function cannot tell them apart, and whoever planted the email is counting on exactly that.

Types constrain shape. Nothing constrains pedigree.

SweeTrust is trust rails for AI agents. Three primitives, and the order is the idea: issue authority, enforce it, prove what happened.

Mandate issues the authority. It is delegated in bounded tiers — organization, then project, then agent — and each tier can hold only a subset of what its parent holds. Revoke the parent and every tier beneath it dies with it.

Gate enforces it. A value carries where it came from, from the moment it enters your system to the operation that finally spends it. Any privileged operation can demand that history and refuse to act without it.

Verify proves it afterwards. Every decision, allowed and refused alike, is signed and hash-chained into a record a stranger can re-check — without having to trust the machine that wrote it.

Why it is powerful

Most agent-safety tools detect. This one refuses. A sink that fails closed does not flag a suspicious payment for review; it declines to make one, and names the missing pedigree in the refusal.¹ That difference matters because a review queue needs a human with attention left over, and the entire reason agents are interesting is that they work when nobody is watching.

The second reason is the one worth arguing about. Better models do not shrink this market — they grow it. The value here scales with how many models are running unattended and how cheap they are, not with how flawed they are. Most safety pitches are an implicit bet that models stay bad, which is a bet against the field. This is the opposite bet: as capable models get cheap enough to run everywhere by default, a guarantee that holds no matter which one is driving becomes worth more, not less.

What sets it apart

There are four provenance tiers and they only move one way on their own — untrusted, asserted, corroborated, verified. Combining values taints downward, so anything mixed with untrusted data comes out untrusted. Model output is born untrusted no matter how good the model, because inference is not evidence.

A value can climb, but only by three audited routes: match it against a registry you control, corroborate it against independent sources, or ask a person — with the value's history rendered into the question, so the answer is informed rather than reflexive. The constructor is private to the module, so there is no fourth way up.²

The part worth showing a skeptic is the limits. Deleting the last few receipts leaves a perfectly valid shorter chain, and only an on-chain anchor catches that, which is why the anchor exists. A compromised host can sign lies going forward. The off-chain authority layer can be bypassed by a host that owns you completely — making that impossible is the Move contract's job, and the two compose without either claiming the other's guarantee. Each of those limits has a test behind it rather than a sentence.

How much is built

The three primitives are built and versioned together at 0.3.0, under 169 passing tests that include a dedicated adversarial suite against each one. Zero runtime dependencies — node builtins only, so nothing else enters your tree.³

The packages are not on npm yet — they are in final review before publication. The product around the primitives is a separate question and a longer one: the execution engine, the client and the adoption flow are not built.

So this says built, not shipped, and it will keep saying that until you can install it and check for yourself. A claim you cannot verify is a claim I am not making.