Security at RiraTrace

Last updated 2026-11-03

An SR&ED claim is built from a company's most sensitive material: what it is inventing, what it spent, and who it pays. We designed the platform around that, and this page says what we actually do rather than what we aspire to. Where something is on the roadmap rather than in place, it says so.

1. Principles

• Fail closed. If a permission check, a configuration value, a budget or a safety check is missing or ambiguous, the action does not happen.
• Least data. We collect what the claim needs, and we ask clients to leave out what it does not (no SINs, bank details or health information).
• Least privilege. Invitation-only accounts, role-based permissions, read-only integrations, scoped provider keys.
• Evidence of method. The same audit ledger that defends a claim also records who did what on the platform.

2. Where data lives

The providers behind each row, and the countries involved, are listed in the Privacy Policy, as privacy law requires. A full sub-processor list with contract terms is available to clients on request at security@riratrace.com.

3. Client isolation

Every table that holds client data carries the identifiers of the firm and the client it belongs to. The API builds a client scope from the signed-in person's membership before any read or write, and every query runs inside that scope. Row-level security in the database enforces the same boundary a second time, so a bug in the application cannot reach across clients. Search indexes, file paths and AI prompts are all built within a single client's scope; the code refuses to assemble a prompt that would mix two clients.

4. Access control

• Invitation only. There is no self-service sign-up. An administrator invites each person to a specific firm or client with a specific role, and the invitation goes only to that address.
• Roles. Firm admins, senior consultants, consultants, and client contacts each see and do only what their role allows. Client contacts see their own company's workspace and nothing else. Within it, payroll, subcontractor and material costs, the estimated credit and the files sent for them are seen only by the client's lead and accountant (and the firm staff assigned to the client); other contacts see them locked. The database enforces the same rule.
• Per-client staff access. A consultant or senior consultant sees a client's workspace, files and notifications only while a firm administrator has put them on that client; taking them off takes the access away at once. Only firm administrators see every client of their firm. The same rule is enforced by the application and by the database, and every change is recorded.
• Passwords. Password sign-in with checks against known leaked-password lists; one-time, expiring links for invitations and resets. Sessions are held in secure, HTTP-only cookies.
• Two-step sign-in (multi-factor). Required for everyone who signs in with a password or an emailed link: a 6-digit code from an authenticator app, checked by both the web app and the API. "Continue with Google" is also available and relies on Google's own two-step sign-in; access is still by invitation only. An administrator can reset two-step sign-in for a lost phone, and the reset is recorded.
• Agreement to terms. Every sign-in asks the person to agree to the Terms of Use and Privacy Policy, and the agreement is recorded with its version and time; if it cannot be recorded, the person is not signed in. The platform refuses any session without a recorded agreement to the current version, so when the terms change, everyone agrees again at their next action.
• Our team. Access to production is limited to named engineers over SSH keys; platform-admin actions are logged. There is no shared account.
• Engagement letters. A senior consultant approves every engagement letter before it can be sent. The client's lead signs it in the platform with a typed signature; the name, title, time, IP address, browser and a SHA-256 fingerprint of the exact text are recorded, a signature on a version that has since changed is refused, and a signed letter can no longer be changed. Each firm's contract templates are kept version by version, and a saved version never changes, so every signed letter keeps the exact text it came from. Letters, signed copies and firm logos stay in our Canadian storage.
• Files with employees' personal information. Every upload is scanned on our server in Canada before its text is stored. A file holding a Social Insurance, health card, driver's licence, passport or payment card number is refused: its bytes are deleted and no text is kept. A file with employees' pay, health information, bank details, birth dates or home addresses opens only for the client's lead, the client's accountant and the firm's consultants on that client; other contacts see it locked, without its name. A file not yet checked is restricted the same way (fail closed). The API enforces this on every list, download and text read, and the database keeps the page text of restricted files from everyone else as a second wall.
• Platform administration. A small number of our staff are platform administrators. They can add a firm with its first administrator, see who has access to each firm (name, email, role) and remove access. They do not see client names, files or claims through this, and they are not members of the firms they administer; each action is recorded in that firm's audit ledger.
• AI agents. An AI agent reaches the platform only with an agent key a platform administrator creates: stored as a one-way hash, limited to named permissions, expiring within 180 days, revocable at any time, and refused once its administrator loses that role. Our own agent is our coding assistant, which can read open problem reports and record a proposed fix; it cannot read client workspaces, and it cannot close a report, approve, file or send anything. Every key change and every agent action is recorded.
• A client's own AI assistant. If the client's lead allows it, a contact at the client can connect their own assistant (for example Claude, ChatGPT or Microsoft Copilot Studio) to our MCP address with OAuth 2.1: the assistant registers, the contact signs in to RiraTrace and approves it on a page that says exactly what it may read, and the code is bound to the assistant with PKCE. The assistant can then only read that one client's claim years, projects, documents and their text, never payroll, never another client. If the contact allows it, it may also propose: a suggested evidence link or a summary document, each confirmed or dismissed by a person; it can never change, approve, file or send anything. Its access token lasts an hour and its refresh token is replaced at every use; both are stored only as one-way hashes. Every read is recorded in the client's ledger. The contact or the client's lead can disconnect it at any time, and the lead turning own assistants off disconnects them all.

5. Encryption and infrastructure

• TLS 1.2+ for every connection, with HTTP Strict Transport Security; the API is never exposed without it.
• Encryption at rest for the database, file storage and backups.
• Uploaded files live in a private bucket; they are served only through short-lived, signed URLs issued inside the caller's client scope, never from a public path. Each file is stored under its content hash and verified against it on backup.
• Security headers (content-type sniffing off, frame embedding restricted, strict referrer policy) on every response.
• Secrets are injected from configuration, never committed; every provider key is scoped to the one job it does.

6. AI safeguards

• Off by default, per client, decided by the client. AI calls check the client's consent flag first and do nothing if it is off. Only the client's lead turns it on, by agreeing to the exact text in the platform with their typed name; the text, its version and the change are recorded in the ledger. Firm staff can turn it off, never on.
• The client's own provider. The client's lead can run the AI steps on the client's own provider (its own Anthropic key, an OpenAI-compatible endpoint, or Amazon Bedrock in a chosen region). The key is encrypted with AES-256-GCM on our servers in Canada, never returned to a browser, and only its last four characters are shown. We call only public HTTPS endpoints and refuse any address that resolves to a private or internal network, checked again at connect time, so an endpoint cannot be pointed at our own systems. Calls time out, the firm's daily budget still applies, and every call is in the usage ledger.
• Not used for training. Content sent to the model provider is covered by terms that prohibit training on it and limit how long it is retained.
• One client per request. A prompt can only be assembled from a single client's scope.
• Citations we can verify. Drafts cite evidence by identifiers our own tools returned; identifiers produced by the model are rejected, so a draft cannot point at evidence that does not exist. Technical write-ups cite the log months they were built from the same way: a sentence citing a month or field we did not give the model is dropped.
• Untrusted input. Document text is treated as data, not instructions; the model cannot act on the platform, only return text.
• Budgets and a usage ledger. A hard daily token budget per firm; the call fails closed when the limit is reached. Every request is recorded per client (the step, model, tokens and how it ended, not the text), and the client sees a 30-day summary on AI controls.
• Restricted files stay out of AI. Text of a file the upload privacy check has not found clear is never chunked, indexed, searched, or sent to any model, including a client's own assistant. Account numbers and birth dates are replaced in the stored text. The optional Privacy check agent (off by default, on only by the client's lead, and only while AI is on) reads only files the pattern check found clear, at most 12,000 characters, and can only restrict a file. Each check is recorded with the kinds and counts found, never the values.
• Human sign-off. A senior consultant's recorded approval is required before anything is filed or sent. There is no code path around it.

7. Connected services

Integrations (today, GitHub and QuickBooks Online) are read-only and connected by the client's lead with the narrowest scope the service offers. We import metadata and the records the claim needs, not whole repositories. We store no long-lived tokens: access uses short-lived GitHub App installation tokens, and each installation is bound to exactly one client. Uninstalling the app on GitHub ends our access. In the platform, the client's lead chooses which of the shared repositories are read, and can pause a connection or disconnect it at any time on Data sources; nothing is read while it is paused or disconnected, and every change is recorded in the client's ledger. Once disconnected, the lead can remove what it brought in; documents the claim cites are kept, hidden. A connection whose reads keep failing is marked as needing attention and retried daily; each read is logged with its counts and a short error, without secrets, for 90 days.

QuickBooks Online. The client's lead connects the books through Intuit's OAuth 2.0 sign-in, with a link sealed to them that expires in 30 minutes; one set of books can be bound to one client only, and books not kept in Canadian dollars are refused. Intuit grants only one accounting scope (com.intuit.quickbooks.accounting), which covers reading and writing; RiraTrace's code only reads. The access and refresh tokens are long-lived, so they are sealed before storage with AES-256-GCM under a key derived for each value from a master key held only on our servers, kept in a table no signed-in user can read, never logged, and refreshed by one process at a time. Disconnecting asks Intuit to revoke the grant and deletes the tokens; if Intuit refuses a refresh, reading stops and the lead is asked to reconnect. Payroll by person is never read.

Email forward. Each client has its own evidence address. Amazon SES in Canada (Central) receives the mail over TLS, scans it for spam and viruses, writes it to a private, encrypted S3 bucket in Canada and notifies our server through SNS; our server accepts only notices from our own topic whose AWS signature verifies, and reads the message with a key that may only read and delete objects in that bucket. An email is added automatically only when its sender is on the client's team and the email proves it came from that sender's domain (DMARC, or SPF for the same domain); a forged sender, anyone else, or a client with no open claim year is held for the client's lead, and nothing is added until the lead accepts it. An address that belongs to no client is discarded. Each client is handled separately, even when one email is sent to two clients' addresses. Attachments go through the upload privacy check; the email's text is copied only when the privacy patterns find nothing in it. The stored copy is deleted once the email is settled, and a bucket rule deletes anything left after 30 days.

8. Audit trail and backups

• An append-only ledger records uploads, status changes, approvals, access grants, consent changes and administrative actions, with who and when. Status changes go through a state machine; there is no way to set a status directly.
• The database is backed up nightly by the hosting provider, with seven days of restore points. Files are copied daily to a server in Canada, checked against their hashes; a deleted file is kept for 30 days and then removed. A backup run that fails raises an alert.
• Logs carry counts and identifiers, not client content. Sign-in links are never logged.

9. Development practices

• Strict typing, automated tests on every change, and database constraints that mirror the application's rules.
• Code review before merge; dependency updates tracked; third-party code and its origin recorded.
• Any new service that would receive client data outside Canada must be documented and disclosed before it is used.
• A written threat model and security design maintained alongside the code.

10. Incident response

We have a written incident process: contain, assess, notify, fix, and review. Clients are told about any incident that affects their workspace. Where a breach creates a real risk of significant harm, we notify affected individuals and the Office of the Privacy Commissioner of Canada (and the Commission d'accès à l'information du Québec where it applies) as soon as feasible, and keep the records the law requires.

11. Compliance and frameworks

We are a small firm and do not yet hold a third-party certification. Our controls are designed against the following, and we are honest about which is which:

Clients who need to complete a vendor security questionnaire, or want the detailed version of this page, can write to security@riratrace.com.

12. Reporting a vulnerability

If you believe you have found a security issue in the platform or the website, email security@riratrace.com with enough detail to reproduce it. We acknowledge reports within two business days and keep you informed until the issue is resolved. Please do not access, change or keep any client data beyond what is needed to show the issue, and do not test with denial-of-service or social-engineering techniques. We will not take legal action against research that follows these rules. The same contact is published in machine-readable form at /.well-known/security.txt on this site and on the application host.