Skip to main content

Enterprise Deployment

Self-hosted verification, managed key infrastructure, and compliance evidence for teams that need to prove what agents did.

Talk to usTrust Center

Deployment Options

Self-hosted

Run the full stack in your own infrastructure. All signing keys, policy, and records stay in your environment.

  • Your keys, your infrastructure
  • No data leaves your environment
  • Apache-2.0, no CLA
  • Full source access

Managed keys

Originary manages key lifecycle, rotation, and attestation. You control policy and deployment.

  • Key generation and rotation
  • Hardware-backed attestation
  • Policy stays with you
  • Support SLA included

Full managed

Originary operates the verification layer. You integrate via SDK or gateway.

  • Deployment and operations
  • Monitoring and alerting
  • Compliance evidence bundles
  • Dedicated support

Security Model

What stays in your environment, what travels, and how verification works.

SigningEd25519 (RFC 8032). Keys generated locally or via managed HSM.
VerificationOffline via JWKS public keys. No callback to Originary or any vendor.
Key management5-state rotation lifecycle. 30-day overlap. Revocation support.
Data boundaryRecords contain policy hash and decision, not raw request payloads.
TransportCompact JWS (RFC 7515). Fits in HTTP headers, MCP metadata, A2A envelopes.
NetworkNo implicit fetch. No SSRF. URL fields are locator hints only.

Compliance and Procurement Evidence

How verifiable interaction records help in audits, disputes, and procurement review.

  • Verifiable evidence of what was accessed, under what terms, and what decision was made
  • Records are portable: export to any audit, dispute, or partner workflow
  • Policy binding: records reference the exact policy version in force at decision time
  • Third-party verifiable: any party with the public key can check the signature
  • No vendor dependency for verification: works offline, no phone-home
Discuss enterprise deployment

Example: Agent Access Audit

An agent calls your booking API. Three months later, a partner disputes the transaction.

1

At request time

Originary evaluates the agent request, applies the booking policy, and returns a signed interaction record with the decision, policy hash, and timestamp.

2

Record is stored

The signed record is stored by both parties. It is portable: no vendor lock-in, no proprietary format.

3

Dispute arises

The partner retrieves the record and verifies the Ed25519 signature using your published JWKS. No callback to Originary. No network required.

4

Evidence holds

The record proves: who acted, what policy applied, what decision was made, and when. The policy hash confirms the terms were not changed after the fact.