What we hold. What we don't. How to verify.
Compliance review of a managed AI-agent infrastructure provider should start with one question: what would a compromise of this provider give the attacker? Our answer is documented and bounded by design — most things you might worry about, we structurally cannot have.
- operator account metadata: email, billing address, plan tier
- public Bitcoin addresses you bind agents to (these are public on Bitcoin already)
- OC Agent action envelopes (the content-addressed action receipts — kind 30084, sharing OC Stamp's envelope structure) and the audit bundle structure
- OpenTimestamps proofs (OC Stamp's underlying anchor rail) submitted to public calendars
- operational logs sufficient for SLA accounting and abuse response (90-day retention)
- customer Bitcoin private keys — the OC family signs in the user's wallet, never on our servers
- customer funds — bonded reputation stake is attestation-of-unspent, never escrow
- action contents beyond what compliance requires — receipts carry hashes of inputs, not raw inputs, unless a customer opts in
- a custodial wallet of any kind, for any purpose, ever
- a token, points balance, or any unit of account besides sats and USD
the data-flow, briefly
[ user wallet ] (private keys never leave this box)
│
│ bip-322 sign canonical message
▼
[ console.ochk.io api ] (we hold: operator metadata, oc-stamp
│ envelope hashes, ots proofs — never
│ emit oc-stamp envelope plaintext keys or funds)
▼
[ opentimestamps calendars ] (oc-stamp's anchor rail · 3 independent
│ · alice · bob · finney)
▼
[ bitcoin block ] (immutable, public, the canonical clock)
↑
│ verify with @orangecheck/stamp-core
│ no console.ochk.io reachable
[ verifier @ customer site ] (any laptop, offline, forever)anchor posture
Every action receipt, scope change, and revocation is an OC Agent action envelope (kind 30084) — content-addressed, BIP-322 signed, and reusing the canonical envelope structure of OC Stamp (stamp.ochk.io), the family's provenance primitive. The envelope binds BIP-322 authorship, the content hash, the delegation reference, and the OpenTimestamps proof into one auditable object. We dogfood our own family; you do not get a raw OTS proof with our brand on it.
Why this matters: action envelopes verify offline with @orangecheck/agent-core, completely independent of console.ochk.io. If we disappear, every receipt continues to verify against Bitcoin headers using a published, MIT-licensed library — no console-specific code path, no proprietary format.
Underlying rail: OpenTimestamps — three independent calendars (alice, bob, finney). A Stamp envelope is confirmed when at least one calendar has folded the proof into a Bitcoin block; we surface the block height in the envelope so verifiers can re-derive ordering with no trust in our service.
Nostr publication is over four independent relays (relay.damus.io, relay.nostr.band, nos.lol, relay.snort.social) so that third-party witnesses can see the same events we do without trusting the operator's relay choice.
disclosure
Found a verifier-impacting bug, an audit-export tampering vector, or a scope-bypass in a console-managed agent? Email security@ochk.io directly — please don't open a public issue. We acknowledge inside 48 hours, prioritize verifier-impacting issues over everything else, and publish a write-up after the fix is in.
compliance posture
SOC 2 Type 1: in progress. Targeting completion before general-availability launch. Enterprise tier customers will receive the report and continuous-compliance attestation.
Self-hosted option: Enterprise tier customers can run the managed components on their own infrastructure (VPC or on-prem). We provide the operator playbook, the helm charts, and the runbook; the protocol is the same.
Spec stewardship: any change to the wire format, scope grammar, or audit-bundle structure goes through an open PR against oc-agent-protocol or oc-pledge-protocol. There are no closed extensions and no closed conformance vectors. See /charter.