Security | GRADE

The short version

GRADE processes a customer's product documentation (the documents uploaded to its account) and its inbound inquiries (the message as received, any attachments, and the inquirer's name, company and email address). Each customer's data is isolated to that customer, is never used to serve or train for anyone else without written consent, and is deleted from our live database and file store within 30 days of a deletion request made in the app by the customer's administrator, unless the request is cancelled first. Every AI-drafted output requires explicit human approval before it goes anywhere.

What we hold

To run the service we also store the product data we extract from those documents, and any text we have collected from public web pages and published patents about its products; the screening result, recommendations and drafted reply for its inquiries, with the representative's edits, the record of who approved the reply and the outcome; the notes, reply templates, rules, supplier lists and dashboard figures entered for its account; the customer's company profile, divisions and settings, its user accounts, roles and sign-in records, and a log of actions in its account; its support requests and problem reports; and the invoices we issue to it.

Architecture choices that reduce risk

Tenant write-isolation. A customer's data is isolated on writes as well as reads.
Deterministic screening. Hard requirements (regulatory limits, specifications) are enforced by fixed rules in our software, applied to the customer's own product records, not by model judgment. A model reads the requirements out of the inquiry text; it takes no part in the comparison. Every elimination carries an auditable reason.
Verbatim provenance. Extracted values must trace to an exact source sentence in the customer's own documents; values without a source are rejected, not stored.
Human-in-the-loop by design. The system drafts; a named representative reviews, edits, and approves. Nothing sends automatically.

Operational controls

Encrypted transport (TLS) on all endpoints; access-controlled application endpoints; rate limiting; structured audit logging.
Encryption at rest. Stored data is encrypted at rest at the storage level by our managed database host; database backups are additionally AES-256 encrypted before they are stored. The backup job runs outside our hosting environment, at GitHub, where it reads the database and encrypts the copy. The job keeps two encrypted copies: one at GitHub, in the same account as the decryption key, and one with a separate storage provider that does not hold the key.
Scoped credentials for our automated jobs' access to code; secrets kept out of source control; routine dependency vulnerability scanning.
Subprocessors: model inference via Anthropic under contractual confidentiality; hosting on established cloud infrastructure (Railway for the application and its database, and Cloudflare for file storage, inbound inquiry email, this website and the network that carries traffic to the application); outgoing email, such as sign-in links, invitations and notices, via Resend; our company email and the booking form linked from this site via Google; sign-in through Google or Microsoft for users who choose it; scheduled backup and data-deletion jobs on GitHub, whose machines connect to the database to run them and which keeps the database backup; and a second copy of that backup, kept off-site at Backblaze.

Reporting a vulnerability

Email [email protected] with details. We acknowledge promptly, investigate in good faith, and will not pursue action against good-faith research.

Service status