RoboGrant9000 — Security Overview
Last updated: June 1, 2026 Status: Living document — see "Questions and contact" below.
At a glance
RoboGrant9000 is a premium, low-volume B2B service for Canadian nonprofits, operated by CHUDAK INC. (o/a RoboGrant9000). Security is built into how the product works, not bolted on. The summary: customer data is stored in Canada, isolated per organization at the database level, encrypted in transit and at rest, and every output is reviewed and signed off by a human before it is used.
Tenant isolation
Every organization's data is separated at the database layer by row-level security (RLS) — not by application code alone. Two database-resident helpers, current_org_id() and has_portal_access(), back the access policies on every product table, so the database itself refuses cross-organization reads and writes. This boundary holds even if an application route guard were bypassed, because it is enforced inside Postgres, beneath the application.
We test this isolation automatically: a cross-tenant RLS isolation test runs in our build pipeline, so a regression that could cross organizations fails the build before it ships.
Encryption
Customer data is encrypted in transit (TLS) and at rest, on our infrastructure providers' platform-standard encryption.
Data residency
Customer data is stored in Canada — Supabase Postgres and Storage in the AWS Canada–Central region (ca-central-1, Montréal), aligned with PIPEDA. The region is a permanent choice. Some processing needed to deliver the service (AI research and drafting, embeddings, sign-in, payments, hosting, background jobs, transactional email, and error monitoring) occurs in the United States and on global infrastructure; this is detailed in the Privacy Policy (at /privacy) and the sub-processor list (at /sub-processors).
Authentication and access
Sign-in, user accounts, organizations, and seat invitations are managed by Clerk. Access to grant work product is licensed per seat: a member must both belong to the organization and hold a portal seat to see product data, and a billing-only stakeholder is walled off from grant work. Seat limits are enforced by the database itself (a trigger the service role cannot bypass), not just in the application.
Least-privilege service role
Elevated database credentials exist only in server-side code, never in client code, prompts, or the repository. The service role used for backend operations bypasses row-level security but not the database triggers and CHECK constraints — so the seat cap and the product's integrity constraints hold regardless of how a write arrives.
Audit logging
Sensitive billing and account actions are recorded in an audit log (who did what, when), so account activity can be reviewed when something needs investigating.
Abuse and spend controls
AI endpoints are protected by two independent backstops: a per-organization monthly cost ceiling and a per-organization request rate limiter. Both fail safe — they never block legitimate work on a transient error — and they sit behind authentication, so they protect the platform without affecting normal use.
Secrets handling
Live credentials are namespaced (for example, production keys are kept separate from development keys) so local development never touches production. Secret values are never logged — operational scripts read configuration at runtime and print only names and prefixes, never values.
Error monitoring
Error monitoring runs through Sentry and captures technical error reports (error details and internal record identifiers), not personal information. We limit error reports to non-personal technical data.
Human-in-the-loop trust rule
The product's core correctness guarantee is that a human always reviews and signs off before anything is submitted to a funder. The AI drafts; your team reviews, edits, and decides. Research citations carry their sources, exact quotes, and retrieval dates, and only independently verified statistics are assertable in a draft — a figure that could not be verified is flagged to your team, never silently included.
Deletion / right to be forgotten
On a verified request, an organization can be fully erased across our systems. The deletion path removes uploaded files from storage and the organization's records from the database (across every org-scoped table, with the database's foreign-key cascades as the backstop), then cancels billing and removes the organization from our authentication provider. Certain records survive as the Privacy Policy (at /privacy) describes — for example, billing and tax records we are legally required to keep.
SOC 2 and certifications — trajectory, not a claim
We do not currently hold a SOC 2 (or comparable) certification, and we do not claim one. We treat formal certification as a roadmap item: as enterprise demand warrants, we intend to scope a SOC 2 Type 1 engagement and build toward it. Until then, this page describes the controls that are actually in place today — accuracy over marketing.
Known hardening items (honest caveats)
No system is perfectly secure, and we won't pretend otherwise. Items on our hardening list include finishing storage-bucket access rules, a written breach-response runbook, and the broader monitoring and backup-restore drills that accompany an enterprise launch. We would rather name these than imply they are already complete.
Questions and contact
This is a living document; it will change as our controls mature. For a security questionnaire, our data-processing terms, or any question about this overview, contact support@robogrant9000.com.