Security

This page describes how onTerms (operated by Rated Counsel Limited, registered in England and Wales, company number 11812572) approaches security. onTerms is a business-to-business service for standardised, content-addressed contract terms with verifiable signing and a public transparency log. Our security model is built on a simple idea: wherever possible, you should not have to trust our assertions, because you can verify the cryptography yourself. This page is an honest engineering overview, not a certification, and it should be read together with our Privacy Policy and Terms of Service.

1. Non-custodial signing

onTerms never holds the private keys that parties use to sign agreements.

• Humans sign with passkeys (WebAuthn). Signing keys are generated and held by your own device or platform authenticator (for example a phone, security key, or operating-system keystore). The signature ceremony asserts a challenge that is exactly the hash of the order being signed, and we verify the assertion against the registered public key. We never see, store, or transmit the private key, and we cannot sign on your behalf.
• Agents sign with party-held Ed25519 keys. Software agents produce detached Ed25519 signatures over the order hash using keys their principal controls. Again, the private key never touches onTerms.
• onTerms holds exactly one private key:the operator key that signs transparency-log tree heads. By design, and in code, this key signs only tree heads. It never signs a party’s order, so a compromise of our operator key could not forge an agreement; it could at worst mis-attest the state of the public log, which independent verifiers checking consistency proofs would detect.

A consequence worth stating plainly: because signing is non-custodial, losing your passkey or Ed25519 key is like losing a physical key. We cannot recover it for you, and we cannot use it without you.

2. Content addressing and tamper evidence

Every order is canonicalised with JSON Canonicalization (RFC 8785 JCS) and hashed with SHA-256 to produce a content address, the order_hash. Signatures are made over this hash rather than over a rendered document: we sign the data, not the PDF. Any change to any field of a signed order, however small, produces a different hash, so tampering is detectable by anyone who recomputes the hash, with no need to trust onTerms. The verification code is open source (Apache-2.0), so the check itself is independently auditable and runnable offline.

3. The transparency log

Executed orders are anchored in an append-only Merkle transparency log modelled on RFC 6962 (the Certificate Transparency structure):

• Each anchored entry is a hash (the content hash and its leaf hash), never the order body. The public log does not contain party names, addresses, or commercial terms.
• Every append produces a signed tree head over the full tree, plus an inclusion proof for the new leaf. Consistency proofs let any observer confirm that the log is append-only and that history has not been rewritten.
• Verification is free and public. The verify endpoint returns inclusion proofs and status, not order content, and anyone can check proofs against the published tree heads with the open-source tooling.

The log’s append-only design is a security feature with a data protection trade-off: hashes of anchored content remain in the log even where the underlying stored plaintext is later deleted. How we handle this for erasure requests is described in the Privacy Policy.

4. Agent authorisation: capability and authority kept separate

Agent execution runs on two deliberately separate planes, and the server never lets one substitute for the other:

• Capability (OAuth 2.1).Paid agent tools sit behind an OAuth 2.1 resource server. Every request is fully validated: token signature, issuer, expiry, and audience. Tokens are audience-bound (RFC 8707), so a token minted for another service is rejected, and we never forward a client’s token to an upstream provider. Authorization-code flows require PKCE (S256). Scopes are least-privilege and the free tier carries no paid scopes, so gates fail closed.
• Authority (verifiable mandates). A valid token is never treated as authority to bind a principal. Before an agent can execute an order, the server independently verifies a principal-signed verifiable mandate: did:web key resolution and Ed25519 proof verification, a no-self-authorisation rule (an agent cannot be the source of its own authority), live revocation checks against a status list, scope-envelope checks, and a human-ratification threshold for higher-value orders. Execution defaults to deny when no mandate is presented and fails closedwhen the principal’s authority cannot be resolved or verified.

5. Dispute tooling and binding awards

Our dispute tools are tiered, and the security-relevant point is that conformance is enforced in code: the open-source verifier refuses to validate a purported binding award that does not conform to the published rules and schema. Binding arbitration (Tier 2B) is built but is switched off pending counsel sign-off on the draft arbitration rules; it is not operational, and no binding award can be produced through the platform while the gate is closed. See the Terms of Service for the current status of each dispute tier.

6. Platform and infrastructure security

• Encryption in transit. All connections to onTerms use TLS (HTTPS). There are no unencrypted service endpoints.
• Secrets management. API keys, the operator signing key, and other credentials live in environment configuration on our hosting platform, never in source code or the public repository.
• Session and ceremony cookies. Authentication uses a sealed session cookie via our identity provider, and the passkey registration ceremony uses a short-lived (5 minute) httpOnly challenge cookie. Details are in the Cookie Policy.
• Hosting and storage. The application runs on Vercel (serverless, US) with data in Neon Postgres (AWS, US). Encryption at rest is provided by those platforms. The full list of providers is in our Sub-processors page.

7. Payments and identity verification

Payments are fully delegated to Stripe. Card details are entered on and processed by Stripe’s PCI-DSS-certified systems; cardholder data never touches onTerms servers. Where identity verification (KYC) is enabled, it is performed by Stripe Identity: onTerms stores the verification status, not your identity documents.

8. Our providers’ attestations (and what they are not)

Our infrastructure providers maintain their own independent security attestations. These are their certifications, not ours, and we do not claim them for onTerms itself:

9. What we do not yet have

We would rather tell you what is missing than imply maturity we have not earned. As a pre-launch service, onTerms does not yet have:

• an independent penetration test of the onTerms application itself;
• a SOC 2 report or ISO 27001 certification for onTerms (as opposed to our providers’ own attestations above);
• a formal bug-bounty programme with monetary rewards;
• operational binding arbitration (built, but gated off pending counsel review, as described in section 5).

What we do have today is a design where the most important guarantees (signature validity, content integrity, log inclusion and consistency) are independently verifiable by anyone, with open-source tooling, rather than resting on our internal controls alone.

10. Responsible disclosure

If you believe you have found a security vulnerability in onTerms, we want to hear from you. Please email hello@ratedcounsel.com with enough detail to reproduce the issue. We ask that you:

• give us a reasonable opportunity to fix the issue before any public disclosure;
• do not access, modify, or delete data belonging to other customers; if you encounter someone else’s data in the course of testing, stop and report it immediately;
• do not run disruptive testing (for example denial of service) or social-engineer our staff or providers.

We commit to acknowledging good-faith reports, keeping you informed of progress, and crediting you (if you wish) once a fix has shipped. We will not pursue good-faith security research conducted within these guidelines.

11. Contact and changes

Questions about this page can be sent to hello@ratedcounsel.com. We will update this page as the security posture evolves (for example, when independent testing or attestations for onTerms itself are completed) and the date above reflects the latest revision. See also the Privacy Policy, Cookie Policy, and Terms of Service.