Enterprise deployment for signed records
Deploy Originary for agent, API, MCP, and automated workflows with self-hosted, hybrid, or managed options designed for review, procurement, and high-trust operations.
Who this is for
Teams that need signed records to survive audits, disputes, partner review, and cross-boundary automated workflows.
Enterprise AI platform teams
Give agent-driven actions a signed record that can be reviewed outside the runtime and verified without a callback to a vendor service.
API operators and tool publishers
Return a signed record on important responses so another party can verify what was authorized, under what terms, and when.
Security and compliance teams
Export records for audit, review, disputes, and procurement without relying on screenshots or internal dashboards.
Governed runtime operators
Use signed records to carry runtime decisions, tool actions, and cross-boundary interactions into review workflows that outlive the original system.
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.
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
What Leaves Your Environment?
Verification never depends on Originary being online.
| Data | Self-hosted | Managed keys | Full managed |
|---|---|---|---|
| Signing keys | Stays local | Managed by Originary | Managed by Originary |
| Policy files | Stays local | Stays local | Originary hosts |
| Request payloads | Never collected | Never collected | Never collected |
| Signed records | Stays local | Stays local | Originary stores |
| Verification | Local, offline | Local, offline | Local, offline |
| Network calls to Originary | None | Key lifecycle only | Record storage only |
How evaluation usually starts
Start with a technical review, architecture walkthrough, or pilot scope. Teams usually begin with one workflow where signed records help with review, disputes, audit export, or cross-boundary verification.
Example: Agent Access Audit
An agent calls your booking API. Three months later, a partner disputes the transaction.
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.
Record is stored
The signed record is stored by both parties. It is portable: no vendor lock-in, no proprietary format.
Dispute arises
The partner retrieves the record and verifies the Ed25519 signature using your published JWKS. No callback to Originary. No network required.
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.