No agreed blast radius
Nothing pins which model, tools, scopes, and budget the approval actually covers, so the reviewer is asked to bless a moving target.
The evidence layer for high-consequence AI agents
Get your agent through security review, and prove what it did.
Origin runs a deterministic, configuration-bound reference check and issues a tamper-evident attestation a reviewer can re-verify offline.
For the owner of a high-consequence agent that a reviewer can’t yet approve: agents touching production, internal tools, code, PII, or money. Prototype in private pilot: synthetic sandbox evidence, not production SaaS, and not compliance certification.
Agent proposal
Policy verdict
- Scopein allowlist
- Budgetover auto-cap
- Verdictrequire-approval
- Proxyheld
Risk owner
payments on-call
Audit trail
- Proposed · payments.refund · hash ✓
- Gate · over cap · require-approval
- Approved · payments on-call
- Executed via proxy · verified
- Over-scope call · blocked & recorded
Implemented today, check, then prove
- Configuration digest
- Deterministic battery
- Origin Attestation
- Offline re-verification
Speaks the formats your reviewer already reads
- SHA-256 hash chains
- Canonical JSON
- ES256 score receipts
- Offline re-verification
The demo
One agent configuration, checked and attested.
The reference check binds an exact agent configuration, runs a deterministic battery against it, grades it with the oracle, never an LLM judging an LLM, and issues an attestation that stops verifying the moment a bound field changes.
Bind The exact configuration is bound
Model, tool set, policy, budget, and scenario battery are pinned into a single configuration digest. The attestation that follows is bound to this digest and nothing else.
config · model + tools + policy + budget + battery DIGEST BOUND
Challenge A deterministic battery runs
The same scenarios every time: actions that must be allowed, actions that must be denied, and actions that must escalate to a named human.
battery · allow · deny · escalate DETERMINISTIC
Grade The oracle grades it
False accepts, false rejects, and catastrophic failures produce a readiness level. A catastrophic over-grant caps the result at L0 no matter how well everything else scored.
oracle · FAR · FRR · catastrophic cap READINESS LEVEL
Attest An attestation is issued
Origin issues a configuration-bound, tamper-evident Origin Attestation over the synthetic sandbox run, the artifact a reviewer receives.
attestation · bound to config digest · synthetic sandbox ISSUED
Reverify Offline VALID, until the config drifts
A reviewer re-verifies the artifact offline and gets VALID. Change one bound field, swap the model, widen a scope, and the same verifier returns VOID. That is the property being sold.
verify · unchanged artifact VALID
verify · one bound field changed VOID
Change one bound field and the attestation stops verifying. Drift invalidates the evidence.
High-consequence agents get stuck before launch.
Agents are moving from chat into action: they touch production systems, internal tools, infrastructure, code, PII, and money. A reviewer cannot approve what nobody can bound or verify, so the launch date slips. Origin starts exactly there: internal-ops and production-access agents, where the blast radius is concrete and the reviewer is one identifiable person.
Scattered logs, no artifact
Prompts here, logs there, a screenshot in Slack. Nothing the reviewer can re-check independently, and nothing that notices when the configuration changes afterward.
The approval question, answered
Identity tells you who the agent is; observability helps engineers debug. Origin answers the reviewer's question: has this exact configuration earned the right to act, and can I verify the evidence myself, offline?
Proof lands here, as it's earned.
We publish evidence in rungs, and we never dress one rung up as another. Available today: an authored specimen and a machine-emitted sandbox trace with a re-verifiable hash chain. The design-partner trace is forthcoming.
Proof status
TR-A001Authored specimen, shows the evidence-package formatAvailable
TR-A002Machine-emitted sandbox trace, real, re-verifiable SHA-256 hash chainAvailable
TR-A003First external design-partner traceNot earned yet
Authored evidence specimen
Shows the shape of the evidence a reviewer receives: policy verdicts, approvals, proxy events, blocked actions, audit digests. It does not claim a machine-emitted run. See it →
Machine-emitted sandbox trace
Origin's trace engine emitting a real 12-event, hash-chained record over a sandboxed agent action, digest ca1d4690…, re-verifiable with npm run proof:verify. Sandbox only; no live money. See it →
First design-partner trace
Evidence from a real external workflow, published only once a design partner runs it.
The record
- Agent ·
payments-ops-agent - Proposed ·
payments.refund $480.00 → order_8842 - Verdict ·
require-approval(over $250 auto-cap) - Approved ·
payments on-call· 14s hold - Executed · via proxy · within scope
- Over-scope retry ·
blocked & recorded
The proof
- Every step hash-chained & tamper-evident
- Who owned the risk, and when they approved
- Exportable, replayable audit digest
- chain intact ✓ · digest sealed
What this shows
The shape of the evidence a reviewer receives: proposal, policy verdict, approval, execution, and an over-scope action blocked and recorded. The machine-emitted version of this same loop is TR-A002.
What it does not show
Not a customer deployment. Not a performance claim. No reviewer has accepted it. This specimen is authored (illustrative); the sandbox run with real hashes is TR-A002.
Plumbing proof ≠ customer proof. A human-created payment link + a signed webhook would prove the evidence system can capture a real transaction end-to-end, that lane has not been run yet. Either way the agent never touches live money, and it wouldn't be customer revenue.
Start here
Start with an Agent Launch Evidence Review.
A founder-led engagement for one blocked agent workflow: we map the approval blocker, bind the exact agent configuration, run the deterministic reference check against it, and produce the attestation and evidence your reviewer needs to evaluate the launch.
You bring
- →The agent workflow you're trying to ship
- →The tools and systems it touches
- →What's blocking approval, and who signs off
- →What that reviewer needs to evaluate the launch
Origin provides
- ✓A bound configuration digest for the workflow
- ✓A deterministic reference check over that configuration
- ✓An Origin Attestation you can re-verify offline
- ✓A review-ready, tamper-evident evidence package
Built for reviewers, not just builders.
Configuration-bound attestation
The attestation is bound to the exact model, tools, policy, budget and battery that were checked. Change a bound field and it returns VOID.
Tamper-evident audit chain
A hash-chained record of every proposal, verdict, approval, and action.
Escalation scenarios
The battery includes actions that must escalate to a named human; the oracle grades whether the agent escalated when it should have.
Deterministic oracle
Verdicts come from a deterministic oracle, never an LLM judging an LLM, the same battery returns the same result every run.
Runtime gate & proxy (proposed)
A runtime gate, controlled tool-call proxy, and kill switch are the proposed pilot architecture, not deployed general enforcement. See how this differs from runtime enforcement.
Vendor-neutral · exportable
Across clouds and model providers, with an evidence package you can export.
Built by someone who has owned the launch gate.
Origin comes from ~20 years building the "prove it's safe before you ship" layer, payment-grade biometric authentication (designing the false-accept / false-reject operating points that let a face unlock a payment), frontier-safety launch gates and residual-risk ownership, and RL environments with verifier integrity. I've been the reviewer who couldn't approve a launch because there was no way to bound what a system could do or prove what it did. Origin is that missing layer, built for agents.
Origin starts with software agents. The longer arc is any high-consequence system where actions need policy, control, and proof. That's the vision, not today's product.
Origin is decision-support and evidence infrastructure. We use "tamper-evident" to mean alteration is detectable by replay and digest checks; "review-ready," meaning a reviewer can check it, never that a reviewer has signed off. It does not provide legal or compliance certification, and the customer stays responsible for the agents and tools they connect.
Have an agent stuck in security review?
Show us one blocked workflow. We'll map the risk, run the evidence loop, and tell you honestly whether Origin can produce the evidence your reviewer needs.