Quorai

Privacy

Last updated October 20, 2026. Quorai is offered by SnoXLi Ventures LLC.

Draft. Not reviewed by counsel. This page was written by the team that built Quorai, from the product's own schema, so that a design partner can see exactly what the software does with their data. It has not been reviewed by a lawyer and it is not a contract. It will be reviewed before Quorai has a paying customer. If you are reading this during a design partnership and something here matters to you, write to privacy@quorai.ai and we will answer in writing.
In one paragraph. Quorai is a control plane for the AI agents a company runs. To do that job it records what agents exist, what they did, what a policy decided, and what it cost. It does not record the replies you get back from a model, and it records the prompts you send in one case only: when a policy holds a model call for a person to approve, the first 400 characters of that request are kept with the approval. It holds provider API keys you give it, encrypted. Everything is scoped to your organization. Quorai's application and database run in the United States, and the outside services named below handle data under their own terms. When your organization is purged its data is deleted, except its entries in the audit chain, which are kept; the section on deletion says exactly what that means.

Who this is

Quorai is offered by SnoXLi Ventures LLC. Questions about anything on this page go to privacy@quorai.ai, and we answer in writing.

Quorai is pre-release software. It is currently used by its makers and by a small number of named design partners. It is not open for public sign-up.

What Quorai collects

The kinds of data below, and nothing else. Each row says what it is for. The last three rows exist only if your organization uses the feature they describe.

WhatExamplesWhy
Account and organization Organization name and slug, the name and role of each person or token with access, who granted that role and when, the email address of anybody invited or signed in through Google or Microsoft, session records. For a Google sign-in, the account's identifier at Google, its verified address and its Google Workspace domain, which decide whether that person may approve a database guard change. For a Microsoft sign-in, the account's identifier and its organization's tenant identifier at Microsoft, and its verified address. API tokens are stored hashed, never in plain text. To know who you are, which organization you belong to, and what you may do.
Agent metadata Agent name, handle, owner, team, risk classification, lifecycle stage, which model and connector it uses, the skills and tools it declares. If you import an agent definition file, Quorai keeps each version of the file in full, including the instructions it gives the agent, as written and without redaction. The registry. This is the inventory the whole product is built on.
Usage records Per request: provider, model, tokens in and out, cached tokens, cost, latency, outcome, the purpose an operator typed, and a salted one-way hash of the request used to detect an agent looping on itself. Usage that your own systems report to Quorai, with the counts, cost and the reference, workload and skill names they send. Spend, attribution and loop detection. See "what is never collected" below.
Settings and records you create What people in your organization set up or record in the console: policies and standing rules, routing rules, budgets and spend holds, budget pauses (when a budget paused its agents, and the name of who resumed them), named workflows and their proposals, value claims, access reviews, if your organization turns on the weekly reminder digest, which holds and access reviews each digest listed and the week it was sent, maturity self-assessments, verifications, playbooks, and the runs of your agents with how they ended, how they were graded and the commits they made, the code a run or a tool call points at when an agent reports it (a repository, a commit, a file path and a line range, refused when the path looks like it holds personal data), with whether Quorai checked it against your GitHub connection, when, and the id of the file version it checked, and requests to add a new agent with the name of who asked and the purpose they gave. If people in your organization have agents act for them: each delegation a person issues to an agent (the person's email address, the agent, the tools and run it covers, when it expires and who revoked it), the rules that say which person or group may use which tool and up to which risk, and the settings for those checks. If you use the database guard: the databases you register (a name, its environment, the tool names and identifiers that tell Quorai a call is aimed at it, and its policy, including the table and column names you give it), each change to a database that waits for a second person (its settings before and after, who proposed it, who approved, rejected or withdrew it and when, the note they wrote with that decision, and, when the change is closed because the database changed after it was proposed, who changed it and the reason Quorai recorded in place of a note), each change to your organization's sign-in domains that waits for a second person (the domain, who proposed it, who decided it and when, and the note they wrote with that decision), whether your organization counts approvals only from people signed in through its own sign-in provider, and for each database statement an agent sends through Quorai, its kind, the tables it touches, which of the columns you marked as personal data it touches, the guard's decision and reason, and who the call acts for. When the call carries a delegation Quorai verified, that person is recorded. The record also keeps the value the calling software puts in the x-quorai-subject header, up to 200 characters, which is the caller's claim and which Quorai does not check. The guard's record of a statement keeps it with its values removed. The tool call record for the same call keeps only the shape of its arguments, unless your organization switches on storing argument values. Then it keeps the statement as sent, redacted as described below and cut to 2,000 characters, so a value the redaction does not recognize, such as a name or an amount, is stored there. These are the controls and records the product runs on, and they are what your evidence is built from.
Tool call records Tool name, what the gate decided, per-argument path verdicts, and the reason an agent gave when it asked to proceed. By default no argument value is stored. A reason the agent wrote inside the call's arguments counts as an argument value: by default the record keeps only its length and a code. A reason sent in the x-quorai-justification header is stored as written, redacted as described below, and may name a person. The record keeps the shape of the arguments: each name, the type and length of its value, and a short code per value computed with a secret key that Quorai holds. Argument names are kept as written when they look like ordinary field names, so a person's name or an ID used as an argument name, such as jordan_doe, is stored. A name with a space, an at sign, a run of four digits, two or more dots, or a dot and a hyphen is kept only as a code, so a name such as acme.com or jordan.doe is kept as written. A file path or web address that a path verdict names is kept the same way, as its kind and a code. An owner of your organization can switch on storing argument values, and that change is written to your organization's audit log, naming who made it and when. With it on, the arguments are kept in redacted and truncated form (up to 2,000 characters) and paths as written. For a call that is held for approval, the record keeps only the shape of the arguments and a keyed fingerprint whichever way the switch is set, and the exact arguments are kept separately, encrypted, as described below. For a call your own tools report to Quorai after it ran: the tool server, a digest and the shape of the arguments, the result's status, size and digest, how long it took and what it cost, and the arguments themselves only if your organization switches that on, redacted. If a tool's response contains text that looks like a prompt injection, the matching phrases are kept on the record and in the audit chain, redacted. When the call was made for a person under a delegation, the record names that person and the delegation. If an agent posts its own step log onto a run: for each step its number, its time, the tool, the shape of its arguments, the decision the log records (allow, deny or held), the reason the log gives, redacted, and whether a human cleared a hold. This is the evidence that an agent was or was not allowed to touch a thing. Without the arguments the record cannot answer the question it exists for.
Approvals Each request for a person to approve something: the action, the risk, the agent or person who asked, who decided and when, and a context field. Context an agent writes, and the preview of a held tool call, are redacted before they are stored. Context a person sends through the approvals API is stored as written. For a held model call, the context is the first 400 characters of the request, redacted when your organization's redaction policy is on, which it is by default. If the optional policy judge is switched on, its verdict and reasoning are kept with the approval. For a call made for a person, that person is kept with the approval too. So the person deciding can see what is being asked, and so the decision can be checked later.
Audit events Timestamp, actor, event name, a short detail, and two hashes that link each row to the one before it. Since October 4, 2026, 6:10 AM Pacific, audit rows hold a person's recognized identifiers (email addresses and named person fields) encrypted under a key for that person, so that destroying the key makes them unreadable without breaking the chain. A name typed into free text is not recognized and stays readable. Rows written before then are stored as written and stay readable, as can a few rows written just after it by servers still running the previous version. A separate key table holds each person's key, itself encrypted, and a keyed hash of the identifier, never the identifier itself. The audit chain. It is append-only by construction: a row cannot be edited or removed without breaking every hash after it, which is the point of it, and which has a consequence for deletion described below.
Credentials you give us Provider API keys (for example your Anthropic or OpenAI key) when you route traffic through the Quorai gateway. Webhook and notification endpoints. To make the call you asked for on your behalf. Stored with envelope encryption. In bring-your-own-key mode the master key is supplied by you at runtime and is never written to the database, so a copy of the database on its own does not decrypt them.
Feedback you send When somebody uses the feedback button in the product: their email address, the text they wrote, and the page they were on, with the device type, operating system and its version, browser and its version, window and screen size, pixel ratio, whether it is a touch screen, language, time zone, the app version and the screen they came from. So we can read it, answer it and fix what it reports.
Connector and GitHub data Only for connectors your organization switches on. From the GitHub App: the installation and account it was installed on, and for each pull request the repository, number, state, dates, target branch, merge commit id, line counts, test coverage figures if a coverage app reports them, whether the merged code was still there 30 days later if that check is switched on, which of your agents opened it if that can be told, the author's login and the reviewers' logins and verdicts. From a Google Workspace or Okta connector, or a scan you upload: which applications have been granted access, with what scopes, and by which user, which can be an email address. From a spend export: the tools, vendors, teams and monthly amounts it lists. From a GitHub repository scan: the organization's repositories and the AI libraries their manifest files name. If this deployment checks code references, the file a reference names is read from GitHub at that commit to count its lines, and only GitHub's id for that file version is kept. The tokens these connectors use are stored encrypted. To find AI tools and agents you have not registered, and to connect agent spend to the work it produced.
Telegram approvals Only if a person links Telegram to approve holds: their Telegram user id, chat id and username, and for each hold sent to them, the text of the message we sent and what they tapped. So an approval tapped in Telegram can be checked against the message it answers and the person it was sent to.
Passkeys for approvals Only if a person adds a passkey to approve high-risk holds: its public key (the private key never leaves their device), the name they give it, when it was added, confirmed and last used, a fingerprint of the sign-in session that added it, the browser family it was added from, the Telegram chat and message id of the confirmation, and for each approval it signs, a one-use challenge kept as a fingerprint. So a high-risk approval can be tied to a device the approver unlocked at that moment, and checked afterward.
Assistant connections Only if a person connects an AI assistant (Claude or ChatGPT) to Quorai: the assistant's name as it states it, the address it returns to, the person who consented, their role at that moment, what they allowed, when the connection was made, last used and ends or was cut, and its sign-in codes and tokens kept as fingerprints only. So the assistant can read that organization's records for that person's connection and no others, and the connection can be shown and cut.

Separately, the public site collects the four fields on the demo request form, which are name, email, company and a free-text note, plus ordinary server request logs. Nothing else on the site is recorded.

What Quorai never collects

About redaction, stated honestly

Unless your organization switches on storing argument values, the tool call record keeps no argument value at all, only its shape and a short code per value. The code is computed from the value with a secret key that Quorai holds, changes every day and differs between agents. Without the key, a reader of the record still sees each value's type and length, and whether two values sent by one agent on one day are equal. Lengths alone can tell some answers apart, such as yes from no. Whoever holds the master key can test guesses against the code, so a value with few possible answers, such as a number, a yes or no, a date of birth or a staff email address, can be recovered by a key holder. What follows describes what is stored when that switch is on.

Tool call arguments, including database statements, and the reasons agents give for a call pass through a redaction step before they are stored. It first removes known shapes of secret, such as API keys, access tokens and long runs of hexadecimal characters. It then removes five classes of value by pattern: email addresses, US Social Security numbers written with dashes, North American phone numbers, payment card numbers that pass the card number checksum, and US street addresses. Pattern matching is not a guarantee. It catches the common shapes and it will miss an unusual one, and it does not recognize names. In the stored arguments of the tool call record, each removed value is replaced by its kind and a short code computed from the value with a secret key that Quorai holds, so that loop detection can tell a call repeated with the same value from calls with different values. The code changes every day and differs between agents, so it links calls about the same value only within one agent and one day. Without the key, the code shows only the kind of value removed and whether it equals another value from the same agent on the same day. But whoever holds the master key can recover short redacted values, such as Social Security, phone and card numbers, from the tool call record by trying candidates, and can do the same for a value they expect, such as an email address from a list they already have. In local-key mode the master key is stored in the same database, so we recommend supplying your own master key. An agent can also send text that looks like a placeholder, which is stored as sent, so a placeholder in the record does not prove that a redaction happened. Treat the tool call record as reduced-sensitivity, not sanitized, and do not put a secret in a tool argument on the assumption that Quorai will strip it.

Held calls

When the gate holds a call for a person to decide, Quorai keeps the exact arguments of that call, unredacted, so the call can run as approved. They are stored encrypted and tied to that one call. An owner or operator in your organization can ask to see them, and every time anybody does, that is written into the audit chain before the arguments are shown. When the hold ends because it was approved and run, denied or withdrawn, the stored arguments are erased at once. When a hold expires, an approved call that never ran included, they are erased the next time the service cleans up, normally within a day. Erasing them removes them from the live table. Copies of the encrypted value can remain in the database's internal storage until it is cleaned up and in backups until they expire, and they stay readable with the same key until then.

Where it is stored, and who processes it

All traffic to Quorai is over HTTPS and HTTP is redirected. Quorai's own application and database are in the United States. The services named above that sit outside Quorai (a model provider you configure, Anthropic for the optional features, Telegram, Resend, Google, Microsoft, GitHub, Okta and any spend export address you give us) handle data under their own terms and in their own locations, which may be outside the United States. Several of them are used only if your organization switches on the feature that needs them.

The typefaces these pages and the console use are served by Quorai itself, so loading a page sends nothing to a font service.

Who can see your data

How long it is kept

Honestly: for as long as your organization exists. Quorai does not yet enforce an automatic retention window, and no page here will pretend otherwise. Practically:

A retention policy you can set per organization is planned and does not exist today. When it does, it will be described here.

Deleting your data

Write to privacy@quorai.ai from an address on the account and say what you want removed. We will confirm in writing what was done.

Removing your organization happens in two steps that we carry out. First we close it: every sign-in, credential, invitation and agent credential stops working at once, and your sign-in domains are removed. Then, when you ask or when a signed agreement says so, we purge it: your registry, policies, approvals, usage records, tool call records, credentials, sessions, invitations, connectors and webhooks are deleted. A record that your organization existed (its name and identifier) is kept so the identifier is never reused.

What a purge does not delete. Your organization's audit rows are kept after a purge, unchanged, including any email address recorded in them, because the audit chain is one hash chain for the whole service and removing or editing any row would break verification for every customer. An audit row holds a timestamp, the actor (a person's email address or an agent's name), the event name and a short detail. In rows written since October 4, 2026, 6:10 AM Pacific, email addresses and named person fields are encrypted under per-person keys, and a purge destroys your organization's keys, so those identifiers become unreadable while the chain still verifies. Rows written before then keep them readable.

Removing one person. Quorai can revoke a person's access at once. That does not delete their records. An owner of an organization can also erase one person from it: the person's own records there (such as their credentials and invitations) are deleted, their name or address is removed from records that mention them, and their key is destroyed, so their identifiers in audit rows written since October 4, 2026, 6:10 AM Pacific become unreadable. Erasure does not reach audit rows written before then, a name typed into free text, copies already exported or sent as notifications, or backups until they expire. If you ask us to remove a person, we will tell you in writing what was removed and what stays.

Backups. Deleted data can remain in the database host's backups until those expire on their normal cycle.

Cookies

Quorai sets five cookies and none is for tracking:

There are no advertising cookies, no analytics cookies and no third-party cookies.

Decision, 2026-09-07: there is deliberately no consent banner. This was considered and answered rather than skipped, so it is written down here where a reader can see it. All five cookies above are strictly necessary, one to keep you signed in, two to complete a sign-in safely, one to collect a one-time credential safely and one to gate a page that is not public yet, and none is a thing anybody can meaningfully decline while using the product. There is no analytics or advertising cookie to consent to at all. A banner asking permission for a session cookie would teach a reader that our banners mean nothing, which is worse than no banner. The first non-essential cookie brings a consent banner with it, and this paragraph is rewritten on the same day.

Security

What is true today: HTTPS is enforced and HTTP is redirected; secrets are envelope-encrypted at rest with an optional customer-held master key; API tokens are stored as hashes; the console cannot be framed; cross-organization reads are covered by an automated isolation suite; consequential actions taken through the console and API are written into a hash-linked audit chain, and a separate verifier that shares no code with the writer can check it.

What is not true today, said plainly: Quorai holds no security certification. It has not been through a SOC 2 audit, an ISO audit or a third-party penetration test. Any control mapping the product shows you is a mapping we assert, not an attestation anybody has verified. See the terms for more on that.

Your rights

You can ask what we hold about you, ask for a copy, ask for a correction, and ask for deletion, at privacy@quorai.ai. Deletion works as described above, including what the audit chain keeps. We do not require a particular legal basis to be cited before we act on a request from somebody on the account. If you are in a jurisdiction that gives you specific statutory rights, we intend to honor them, and the mechanism is the same email address.

Changes to this page

The date at the top changes when the text does. A material change during a design partnership is emailed to the partner, not left to be discovered.