Security and reliability

• Our API and console run on Render in Ohio, in the US East region.
• Our database is Neon Postgres in AWS US East 2, also in Ohio.
• This website and our docs are static pages served through Render's content network.
• Some other providers also handle customer data for us, including our support email and the AI tools our team uses. Our sub-processors page has the details.
• Our Terms, Privacy Policy and Data Processing Agreement say the same thing about location.

Each time your tool asks us for a decision, we keep a record of the decision itself: which agent key and tool, which of your customers, which plan, the limit, what's left, allow or deny, the reason, the retry key you sent, and when it happened.

With our SDKs, the contents of your API call never reach us. They send only the tool's name, a retry key and, if you set one, the mode. If you call our API directly, we ignore any other fields and don't store them. So please keep personal data out of tool names and retry keys.

• Every answer and every record carries a request ID, so if a decision is ever questioned, we can both look up the exact one.
• You can export your decision history from the console as CSV or JSON at any time, for as long as we keep it (90 days in the beta sandbox).

Every decision writes one record in the same database step that updates your count, so the record and the count can't drift apart.

Decision records are append-only. The database itself refuses edits to them. Records are removed only through our own deletion paths: when they pass your history limit, when an account is cancelled or deleted, or when you reset your sandbox. Every deletion is written to a separate append-only log, with counts.

To be clear about the limits: this is a record-keeping control, not a tamper-proof guarantee. It doesn't stop someone with full database admin access from changing or deleting records.

• Agent keys are stored only as hashes. We show you a key once, when you create it, and we can't recover it afterwards. If one is lost, you make a new one.
• Sign-in has no passwords. We email you a single-use link that expires after 60 minutes, and we store it only as a hash.
• Console sessions are protected. Your session cookie can't be read by scripts on the page, and it's only sent over HTTPS. Sessions last 30 days or until you sign out, and console forms are protected against cross-site requests.
• IP addresses are hashed. Where we use your IP address, for example to limit sign-in attempts, our database holds only a salted one-way hash of it.

• Every connection to our site, docs, console and API uses HTTPS, and browsers are told never to fall back to plain HTTP.
• Our site, docs and API use modern TLS (1.2 and 1.3) and refuse outdated versions like TLS 1.0 and 1.1.
• Connections between our service and our database are encrypted.
• Neon, our database provider, encrypts stored data at rest (Neon's security overview).
• Our website and docs send browser security headers that, among other things, stop other sites from framing our pages.

Your tool shouldn't stop working because we had a bad minute. With our Node SDK, the default is to fail open. If we're slow to answer or can't be reached, your tool runs as normal and the SDK logs a warning. If you'd rather block in that case, you can set that for any tool. One exception keeps limits safe: if a tool was just denied for being over its limit, it stays blocked for up to a minute even while we're unreachable.

The fail-open setting never overrides a clear answer from us. If we deny a call because it's over its limit, the key is wrong, or the key is sending too fast, the call is blocked either way. Two things have their own settings: shadow mode, which only reports and never blocks, and what happens if live keys are off. If live keys are off, test keys keep working and your data stays.

To protect our own service, each key has a request limit and a cap on checks at once, which helps keep one busy key from slowing everyone else down. If a check takes too long on our side, we stop it and roll it back before your SDK's timeout, so nothing is counted twice. See the decide API docs for the current limits.

• Our database can be restored to any point in the last 7 days. We use that only to recover the service.
• We've tested this once so far: in October 2026 we restored our database to an earlier point in time as a separate copy and checked the data. It worked, and we noted a few follow-ups.
• Our production database is protected against accidental deletion or reset.

Every change to our code, site and docs is reviewed and runs through our automated tests before release. Each release is pinned to a reviewed version with a planned way to roll it back.

An automated check also calls our API about every 2 hours and confirms it can reach the database. This is internal monitoring. We don't have a public status page yet.

Each account has one owner, who signs in with a one-time link sent to their email.

We'd rather be plain about this than let you assume.

• No security certification. We don't have SOC 2 or ISO 27001. SOC 2 isn't in our plans right now, and we'll revisit it when our customers need it.
• No SLA or uptime commitment while we're in beta.
• One server. Our API runs on a single server in one region today.
• No published speed numbers yet. We'll publish them once we've measured them properly under load.

These are planned, not live. None of them have dates yet.

• A daily encrypted copy of our database, kept 30 days at a separate provider in Canada, with restore tests every month.
• Restore drills on a regular schedule, with the time each one took written down.
• A second API server, so one server going down doesn't take us offline.
• Outside uptime monitoring and a public status page.
• Teammates on your account, free accounts included, each signing in with their own email.
• A deletion log kept outside the database, so deletions stay deleted even after a restore.

We'll update this page as each one goes live.

The Ordainer team