Free During Beta: Receipt issuance, policy engine, provider verification, and public receipt verification are all free. No wallet required. No deposit needed.

The Machine-Readable Handshake

Legal & Financial Guardrails for Autonomous Agents

Cryptographic consent receipts + programmable guardrails + provider verification for AI agents. Your agent proves what it agreed to. Your policy controls what it's allowed to do. The API provider can verify both.

payload.json
{
  "agent_id": "agent-gpt4-0x7a...",
  "action_type": "data_access",
  "terms_url": "https://api.co/tos",
  "action_context": {
    "endpoint": "/v1/charges",
    "method": "POST"
  }
}
SHA-256
Ed25519
VERIFIED
Certificate of Consent
openterms
Agentagent-gpt4-0x7a...
Actiondata_access
Hasha1b2c3d4e5f6...9z
SignatureMEUCIQDx8n2o...YkFw==
StatusPending...

How It Works

Four steps. Deterministic. Verifiable. Both sides trust the proof.

01

Canonicalize

Agent payload is sorted, null-stripped, and serialized into deterministic canonical JSON per ORS v0.1 canonicalization.

02

Hash & Sign

SHA-256 hash computed, then signed with domain separated Ed25519 per ORS v0.1. The signature is bound to the exact payload.

03

Verify & Store

Anyone can verify the receipt using the ORS verification algorithm and public keys. The signed receipt is stored in the ledger.

04

Provider Verifies

API provider checks the receipt before serving the request. One GET call, public endpoint, no auth. Both sides trust the proof.

Privacy Guard

Built-in Privacy

Agents can be talkative; we ensure they aren't leaky. Openterms automatically scans and rejects receipts containing emails or SSNs, preventing sensitive data from being etched into your permanent transaction logs.

Email pattern: [a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}
SSN pattern: \d{3}-\d{2}-\d{4}
PII Scanner Output
action_context.endpoint
/v1/charges
action_context.method
POST
action_context.user_email
[email protected]Email detected
action_context.ssn
123-45-6789SSN detected
action_context.amount
0.001
Receipt REJECTED — 2 PII violations found. Sensitive data will not be etched into permanent logs.

Block receipts exceeding $0.05 USDC per transaction

{
  "type": "max_amount_per_receipt",
  "limit": 50000
}
Receipt: $0.03 USDCALLOW
Receipt: $0.08 USDCDENY
Policy Engine

Programmable Guardrails

Set hard limits on what your agents can do. The policy engine supports 7 rule types with deterministic evaluation, deny short-circuit, and escalation paths.

Max spend per receipt
Daily spend caps
Action type whitelist/blacklist
Domain prefix requirements
Escalation thresholds
Trust Architecture

Your accountant shouldn't also be your auditor

When your agent logs its own actions, enforces its own rules, and keeps its own records — you have a claim. Not proof. Openterms is the independent witness.

Internal Controls

You wrote the rules. You enforced them. You kept the logs. When something goes wrong, every answer to "who checked this?" is: you did.

Openterms as Third Party

You set the rules. A third party enforces them. The proof is cryptographic — Ed25519 signatures, independently verifiable, immutable. The math checks the work.

The Iterative Governance Loop

1
Deploy with no policy

Every action gets a signed receipt. The agent works freely. You build a verified record of everything it did.

2
Review the decision log

Query the audit trail. See every action type, terms URL, amount. Notice patterns.

3
Write rules based on what you observed

Now you know what the agent actually does, not what you think it does.

4
Simulate before enforcing

The /v1/policy/simulate endpoint tests rules against hypothetical payloads without blocking anything.

5
Activate, observe, iterate

Policies are versioned. Review the deny log. Relax rules that block legitimate actions. Tighten rules that let bad ones through.

"It's the difference between 'I followed the speed limit' and having a dashcam with a GPS timestamp. Both might be true. Only one is evidence."

Real-World Scenarios

What this looks like in practice

Three problems. Three policy configs. Zero ambiguity.

"My agent racked up $200 in API calls while I was at lunch"

For solo developers and indie hackers running agents against paid APIs

You give your agent access to a paid API and it enters a loop. With Openterms, you set a spending cap. When the agent hits it, the next receipt returns POLICY_DENIED. The agent stops. Your credit card doesn't.

Policy Config
{
  "rules": [
    { "type": "daily_spend_cap", "limit": 5000000 },
    { "type": "max_amount_per_receipt", "limit": 500000 }
  ]
}
POLICY DENIED

Reasons: Daily spend cap exceeded (projected $5.12 > $5.00 cap)
Do NOT proceed with this action. Notify the user.

"Prove to me your AI only accessed the systems it was supposed to"

For regulated industries — finance, healthcare, defense, legal

Your compliance team needs to know what the agent did and whether it was authorized. Openterms gives you guardrails that enforce before the action, cryptographic proof that can't be edited after the fact, and an audit trail your compliance team can actually query.

Policy Config
{
  "rules": [
    { "type": "allowed_action_types", "values": ["data_access", "api_call"] },
    { "type": "blocked_action_types", "values": ["purchase"] },
    { "type": "required_terms_url_prefix", "prefix": "https://yourcompany.com/" },
    { "type": "escalate_above_amount", "threshold": 1000000 }
  ]
}
Guardrails — Agent can only do what you've whitelisted
Cryptographic proof — Ed25519-signed, self-contained, verifiable by anyone
Queryable audit trailGET /v1/policy/decisions?decision=deny

"Let the AI handle the small stuff. Flag the big stuff for me."

For teams adopting agentic AI with graduated autonomy

Under $5 per action? The agent handles it automatically. Over $5? It pauses and asks you. Over $100/day total? Hard stop. Your team gets the speed of automation for routine tasks and human judgment for the decisions that matter.

Policy Config
{
  "rules": [
    { "type": "escalate_above_amount", "threshold": 500000 },
    { "type": "daily_spend_cap", "limit": 10000000 },
    { "type": "allowed_action_types", "values": ["purchase", "api_call"] }
  ]
}
ESCALATION REQUIRED — Human approval needed

Reasons: Amount $8.50 exceeds escalation threshold of $5.00
Do NOT proceed. Ask the user to approve this action.

Verification Network

API providers can verify agent consent before serving requests

Your agent carries proof. The provider checks it. Both sides trust the math, not each other.

Agent
Openterms
API Provider
issue_receipt
receipt + headers
webhook notification
API call + X-Openterms headers
verify/{hash}
receipt data (verified)
response (served)

Agent gets receipt + headers

When your agent calls issue_receipt, the response includes:

X-Openterms-Receipt: <canonical_hash>
X-Openterms-Verify: /v1/receipts/verify/<hash>

The agent forwards these headers in its API call.

Provider checks the hash

The provider's middleware calls one public endpoint:

GET /v1/receipts/verify/{canonical_hash}

No API key needed. Returns receipt data with cryptographic verification. Valid → serve. Invalid → reject.

Both sides have proof

The agent has a signed receipt proving consent. The provider has verification proving the agent agreed.

Both backed by Ed25519 signatures and ORS standard JWKS distribution at /.well-known/jwks.json.

5-line provider middleware

middleware.py
# Provider middleware — 5 lines
receipt_hash = request.headers.get("X-Openterms-Receipt")
if not receipt_hash:
    return {"error": "Consent receipt required"}, 403

result = requests.get(f"https://openterms.com/v1/receipts/verify/{receipt_hash}")
if not result.json().get("valid"):
    return {"error": "Invalid consent receipt"}, 403

# Receipt verified — serve the request

What providers see

Provider Dashboard
Receipts (24h)147
Receipts (7d)1,203
Unique agents23
Deny rate1.3%
Action types
api_call891
data_access312
Webhook deliveries147/147 (100%)

Register your API in 30 seconds

One POST request. You get an API key, a webhook URL, and a dashboard. Domain verification via .well-known — same pattern as SSL certificates.

POST /v1/providers
{ "name": "Your API", "terms_url_prefix": "https://yourapi.com/terms/", "contact_email": "[email protected]" }

Technical Proof of Work

Production-ready API. Try it now.

terminal
curl -X POST https://openterms.com/v1/receipts \
  -H "Authorization: Bearer openterms_sk_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: unique-req-001" \
  -d '{
    "agent_id": "agent-gpt4-0x7a3b...",
    "action_type": "data_access",
    "terms_url": "https://api.example.com/tos/v2",
    "action_context": {
      "endpoint": "/v1/charges",
      "method": "POST",
      "scope": "read:transactions"
    }
  }'

Verify any receipt — public, no auth

terminal
# Anyone can verify a receipt by its hash
curl https://openterms.com/v1/receipts/verify/a1b2c3d4e5f6...

{
  "valid": true,
  "receipt_id": "rcpt_abc123",
  "agent_id": "my-agent",
  "action_type": "api_call",
  "terms_url": "https://api.example.com/tos/v2",
  "verification": {
    "hash_matches": true,
    "signature_valid": true,
    "key_id": "key_2026_02"
  }
}
Verification Explorer

Verify Any Receipt

Paste a canonical hash or full receipt JSON to verify its cryptographic integrity in real-time.

Open Standard

Built on an Open Standard

Openterms implements the Open Receipt Specification (ORS), a portable format for cryptographic agent policy acknowledgement receipts. ORS is published as a standalone standard so anyone can build compatible implementations.

What the spec covers

Receipt schema with signed payload fields
RFC 8785 canonicalization with null stripping
Domain separated Ed25519 signatures (ORSv0.1\x00 prefix)
JWKS public key distribution
Verification algorithm with 12 test vectors
HTTP header conventions (ORS-Receipt, ORS-Verify)
Extension namespaces for chaining, commitments, and anchoring

Why an open standard matters

ORS is a data format and a verification algorithm. It is not a network protocol, not a policy engine, and not a billing system. Any team can write a conforming implementation and interoperate with Openterms or any other ORS issuer.

The spec includes a reference verifier (verify.py), 9 example receipts, and 12 canonicalization test vectors. Implementations that pass all vectors are guaranteed to produce identical bytes for identical payloads.

Read ORS v0.1 on GitHub

Openterms is the reference implementation

Every receipt issued by Openterms conforms to ORS v0.1. Every receipt can be verified by any ORS conforming verifier. The standard is the contract.

Free During Beta

Receipt issuance, policy engine, provider verification, and public receipt verification are all free. No wallet required. No deposit needed.

100% Free — No Limits

Everything is free during beta. We'll announce pricing changes well in advance. Current users will be grandfathered.

Beta
All Features
Free
No wallet required · No deposit needed
Ed25519 signed receipts
PII detection & rejection
Programmable policy engine
Provider verification
Webhook notifications
Public receipt verification
Admin console
Unlimited receipts