Watch it refuse. Then read where it stops.
Two minutes of this page is a live agent being refused by a rule with a name. The rest is the part you actually need: what this proves, what it does not, and the three properties that are defensible against a platform that already authenticates everything inside itself.
Drive it
A production agent, a production policy engine, your request.
No account, no key, nothing installed. Ask for a public document and watch it allowed; ask it to execute a payment and watch it refused. Either way you get the rule that decided, by name, and the agent's own status code — because the verdict is enforced, not reported.
Every option below is evaluated for real, by the production policy engine, against a governed agent that is running right now. You are not choosing a canned answer — the verdict comes back from the same path a paying customer's agent takes.
Loading what the demo can evaluate…
No account, no key, and nothing installed. Solara signs this request as the shared demo agent, because you hold no credential and were issued none — a dedicated agent with an identity of its own is what the paid tier is.
The proof underneath
You do not have to take our word for the refusal.
A verdict from a vendor's own service is a vendor's own claim. What makes this different is that the proof of who acted, and with what authority, is a signed object you can check yourself — with a key we publish and tell you not to trust on our say-so.
The anchor is published, and its own page says the origin is untrusted
The kernel key's thumbprint is published in three independent channels, two of them on infrastructure we do not run. The hash is what makes the fetch safe; the transport is not. A verifier that checks a document's thumbprint against that same document's key has verified that a number equals itself, and the page says so in those words. Read the trust anchor →
Verification runs with the network off
The verify page holds the published key, makes no request when it verifies, and works offline — open the Network tab and watch it stay empty. That page carries no analytics script at all, precisely so that instruction is not a lie. Verify a real production VAID →
The verdict is scoped, and the scope is stated
A verification establishes authenticity and expiry. It does not consult revocation and cannot — there is no published revocation list. A third party can walk a delegation chain and confirm each child's authority sits inside its parent's, across organisations, provided the presenter supplies the ancestors.
The honest scope
Three properties. This is the whole of the defensible ground.
Your platform vendor already authenticates every agent inside its own boundary, and does it well. We are not claiming to do that better. The claim is narrower and it is about what survives leaving the boundary.
Across organisational boundaries
An agent your supplier runs calls an agent you run. There is no shared trust domain, no prior relationship and no common IdP. A signed action is checkable anyway, by anyone holding the signer's public key.
Offline and at the edge
Verification is a local computation over bytes you already hold. No callback, no introspection endpoint, no availability dependency on us at the moment you need to decide.
Post-hoc, where the gateway operator is not trusted
Six months later, in a dispute, the party asking the question is not the party that ran the gateway. A log the operator controls answers nothing. A signature over the action does.
Stated as one line: authenticated inside a platform is not the same as verifiable
anywhere.
And the strongest counter-argument, which we would rather raise than have raised at us:
obtaining a given deployment's public key is its own step, and an honest comparison says so.
How this differs from Google, IBM and Databricks — named, sourced and dated →
Where it stops
Five things you would find, so you find them here.
Each of these is the answer to a question a security review asks in its first hour. None of them is buried elsewhere on this site, and none of them is phrased to survive a second reading it would not survive.
A request no rule matches is still allowed. The engine is deny-capable, not deny-by-default. Twelve rules are loaded at boot on the deployed substrate; anything outside them falls through to allow. If you are modelling this as a default-deny control, you are modelling something we do not have.
Built, audited, and deployed nowhere. Isolating an incident, revoking an identity and cutting access are coded, gated on a provisioned actor identity, and write an audit record carrying the substrate's own event id. The mode that enforces them fails closed at boot on an identity that has never been issued, so it has never run outside a test. It is not roadmap and it is not shipped; both words are wrong and this is the accurate one.
Tamper-evident, not tamper-proof. The ledger is hash-chained, so alteration is detectable. It is not immutable and no party is prevented from rewriting it — the durable, operated ledger is the commercial piece and it does not exist as code. Anywhere this site still says "tamper-proof", that is a correction in flight, not a stronger claim.
There is no published revocation list. A VAID is a bearer credential; verification tells you a document is authentic and unexpired, not that its authority still stands. Within the deployment, revocation is checked on inbound requests to the substrate. Credentials are short-lived and carry an explicit expiry, which is what currently bounds the exposure.
A working prototype, and outside the wedge. Threat classification is deterministic pattern matching, not a learned classifier. If you are evaluating runtime agent security posture — detection rates, false-positive rates, coverage lists — we do not have those numbers and will not invent them. Buy this for verifiable identity and enforced authority; do not buy it as a detection product. The Sentinel page, with the same split →
Bring your hardest question.
The ones above are the ones we know about. If your review turns up a sixth, we would rather hear it from you than read it in a procurement rejection.
Wrong door?
I build with agents and I want the identity primitive.
Builders about 90 seconds 02My business is adopting AI and I need to know what could go wrong.
Business owners about 4 minutes 03I want this operated for us, on our terms.
Enterprise about 3 minutes 04None of those, or not sure yet.
Everyone else about 2 minutes