SynOI

For developers shipping automation

Build once. Rewire anything. Redeploy never, governed with a receipt you own.

gate() routes every action through a resolver that binds to a provider at call time. Swapping what runs behind a capability is a config change, not a rebuild, and every call still mints a signed receipt.

ProofThe resolver and signed binding store are shipped and tested (38/38 tests). One environment variable to start.

How it works

One governed call. One signed receipt.

In plain terms: a drop-in gateway your traffic flows through, approving or blocking each action and signing a verifiable receipt for every one.

Every model, every tool call, every pipeline release: gated, signed, and independently verifiable. SynOI® sits between intent and execution and refuses to let anything through without a receipt. Open protocol. Multi-vendor. Self-hostable. The opposite shape from a closed control tower. vs ServiceNow + NVIDIA →

Point your app at your gateway. Govern any action you wrap with one call:
export SYNOI_GATEWAY_URL=http://localhost:3000

import { gate } from '@synoi/sdk'
await gate({ tool_name: 'payments.charge', tool_input: { amount: 4200 } }, () => charge())

Any action: an API call, a payment, a device, an integration, or an LLM. Signed receipt on every one. No LLM required.

Already routing LLM calls? Govern those with zero code:
export ANTHROPIC_BASE_URL=http://localhost:3000/anthropic
# or  OPENAI_API_BASE=http://localhost:3000/v1

Just repoint your base URL. Self-hosted: your keys, your machine, traffic never leaves your box. BYO keys. Multi-vendor. 12 of 20 tools verified →

Decision ReceiptSignature valid

receipt_id rcpt_8b3c9f...

tenant acme-prod

action_class tool.deploy

model claude-opus-4-7

decision allow

risk_level medium

approver a.rivera (mobile · 14s)

elapsed_ms 3

recorded_at 2026-05-14T14:32:01Z

signature 3a9f2b…Ed25519 + ML-DSA-65

Verifiable at oid.synoi.systems/r/<id> by anyone, offline, with any Ed25519 library.

Every governed action mints one of these. Try the verifier →

Built on GAP, an open standard

Live on npm

SynOI runs on the Governed Action Protocol (GAP): CC0-licensed, published, and verifiable by anyone. Your receipts can be checked without trusting SynOI. No account, no SynOI dependency, no lock-in.

npm install @synoi/gap@1.2.0
npm install @synoi/verify
npx @synoi/verify rcpt_abc_123   # check a GAP receipt yourself, offline

@synoi/sraid · @synoi/gap · @synoi/verify · @synoi/oid-resolver: all public on npmjs.org, source on github.com/synoi. Anyone can implement GAP, not only SynOI.

Three primitives, one substrate

Receipts, approval gates, an open protocol.

The three things accountable AI execution needs. SynOI ships them as composable products you can adopt one at a time, or as a unified runtime.

01

Receipts

Every governed action produces a hybrid-signed (Ed25519 + ML-DSA-65) Decision Receipt. Canonical JSON body, public verification surface. Anyone (auditors, customers, regulators) can verify offline with no SynOI dependency. The audit trail is the data.

Receipt Verifier

02

Approval gates

When risk policy says "ask a human," SynOI routes the request to the surfaces that fit your team: mobile push, Slack, SMS, desktop toast, or email magic link. Approve or deny in a tap. Timeouts fail closed. The approval itself is signed and part of the receipt.

How HITL works

03

Open protocol (GAP)

The Governed Action Protocol (GAP) is the open, content-addressed provenance substrate underneath every receipt: canonical JSON wire format, CC0-licensed spec, published on npm as @synoi/gap. Anyone can implement it, not only SynOI.

Read the GAP protocol

Standards alignment · what we build on

  • CSA · STAR for AI· application in flight
  • OpenSSF
  • sigstore
  • in-toto
  • NIST FIPS 204· PQ migration path
  • NIST AI RMF
  • RFC 8949 · CBOR· reserved · future profile
  • RFC 8152 · COSE· reserved · future profile
  • RFC 8032 · Ed25519
  • ISO/IEC 42001· planned

We don't invent crypto. How SynOI aligns with each body →

Not sure where SynOI fits? Answer two questions.

What can I do with SynOI? →

One fabric, every environment

Platform architecture

One governed layer across every environment.

SynOI is not another siloed tool bolted onto one app. It is built to span your apps, your AI agents, your services, your cloud, and your devices, across any vendor, carrying one operator identity and one signed-receipt trail with it wherever it goes.

Most tools give you governance or memory for one model, in one app. SynOI is designed to give you one signed, governed surface, portable across every AI surface and every environment you run in, so identity and policy travel with you instead of locking you into a single model or platform.

Apps

Web and native, wherever you build

AI agents

Any model, any vendor, any framework

Services

APIs, background jobs, internal tools

Devices

Endpoints, edge, and controlled hardware

The gateway and receipts you can install today (above) are the first slice of this layer. The full span across devices and every vendor surface is the architecture we are building toward, not a claim that every integration ships today. How the stack fits together →

Quietly trusted

An available product, in production, with teams building agents that ship.

We don't publish customer names without permission. The shape of the deployments is below, anonymized but accurate. Public references are coming with the next round of customer-story permissions.

Deployment

Series-B AI infra

observability product · 14-tool MCP fleet

Deployment

Regulated SaaS

HIPAA workload · CI/CD release governance

Deployment

Solo developer

OpenClaw + BYO keys · production agents

Deployment

Bootstrapped consultancy

multi-tenant gateway · 6 client tenants

Customer stories →

One environment variable.
Receipts from the next request on.

The gateway is free to start. The receipts are free to verify. The protocol is open. Drop SynOI in front of any model call and the audit trail begins.