Security and Subprocessors

1. About this page

Agreely equips specific Law 25 obligations for its customers; it does not, on its own, guarantee their compliance, which remains each organization's own responsibility. This page describes a different register: our own security posture, as a vendor, for the Agreely service itself.

It complements our privacy policy, which details what Agreely collects and why. The register of security measures the product keeps for each customer, in support of that customer's own section 10, is a separate tool, filled in and declared by that customer, not by us.

2. Hosting and data residency

The primary production database runs on Fly Postgres (app agreely-db, region yyz), in Toronto, Ontario, co-located with the application tier. Our entire production fleet runs in that same region.

Toronto is in Canada, but outside Quebec. Under Quebec Law 25, entrusting personal information to a database in Toronto is a communication outside Quebec (section 17), which triggers, for each customer, its own privacy impact assessment. See our privacy policy for the full scope.

The production database is a managed instance run by Fly.io: the operating system, firewall and patching of that host are that provider's responsibility, not Agreely's. We do not administer that server ourselves.

The residency above covers personal information at rest. Some subprocessors, for example for payment, process limited data outside Canada: see the next section.

3. Named subprocessors

A small number of providers process personal information on our behalf, each for a specific task.

Provider	Role	Location
Fly.io, Inc.	Hosting for the application and the production database.	Toronto, Ontario, Canada
Stripe	Payment processing and subscription billing. Card numbers never touch our servers.	United States
Zoho Mail	Transactional email relay: invitations, verification codes, confirmations.	To be confirmed
Anthropic, PBC	Cookie categorization by language model, for sites using the Témoins product.	United States

The payload sent to Anthropic is designed to carry no personal information: cookie names and attributes, domains. The one possible residue is the scanned page's title, truncated to 300 characters, which could exceptionally contain a person's name.

Anchoring on the public Base blockchain is not in this table: only opaque cryptographic commitments are written there, never personal information. See section 7.

We keep this list current as our providers change.

4. Encryption in transit and at rest

In transit

Every public Agreely surface (the website, the app, the citizen portal, the verifier) enforces HTTPS. Calls to our named subprocessors are also made over encrypted connections.

The link between our application and its database does not use PostgreSQL-layer TLS: protection there rests on a private, non-public network address, and on the application-layer encryption already applied to the most sensitive fields (next section). This is a known gap we are working to close.

At rest

The most sensitive fields are encrypted at the application layer before they are written, under a key specific to each customer: a master key wraps a randomly generated encryption key for that organization (libsodium, authenticated encryption). A compromise of one customer's key can never decrypt another's data.

This protection covers, among other things, consent declarations and receipts, your customers' retained contact details, the guardian's name behind a minor's consent, and the entire rights-request pipeline.

The access log and the cookie registry are deliberately not encrypted this way: they are anchored by cryptographic commitment (section 7), a different and equally real protection, built on a pseudonymous reference and a destroyable salt rather than on ciphertext.

5. Authentication and access control

Passwords are hashed with Argon2id (libsodium), never stored in plain text or in a reversible form.

Login attempts are throttled, by IP address and by account, with a temporary lockout past a threshold: a brute-force attack cannot try an unlimited number of passwords.

Two-factor authentication is available to every user, enrollable individually (an authenticator app, a one-time email code, or a WebAuthn passkey), and an organization can require it for its owner and admin roles.

Sessions are kept server side, in the database, never in an ephemeral file; the session cookie is HttpOnly, SameSite=Lax, and sent only over HTTPS in production.

Access to sensitive account settings (verified domain, did:web identity, billing) is limited by role: not every member of a customer organization holds the same rights.

API access uses a key specific to each organization, compared by constant-time hash, and every request is scoped to the organization that presents it.

Citizens who manage their own consent authenticate without a password, using a phishing-resistant passkey.

6. Tenant isolation

Every record that belongs to a customer carries that customer's identifier, and every query is scoped by that identifier as its first parameter. There are no joins across two customers' data anywhere in our code, a rule enforced by convention and checked by automated tests.

The application connects to the database with a dedicated, least-privilege role: it is never the database's administrator. Administration follows a separate path.

This isolation, combined with the per-customer encryption in section 4, makes each customer a cleanly separated unit.

7. Signing and proof

Every consent decision recorded by the platform is hash-chained and anchored on the public Base blockchain (mainnet, chain id 8453): any alteration after the fact becomes detectable.

Only opaque cryptographic commitments are written on chain. No personal information, and no readable claim, is ever placed there.

The receipt is signed with your organization's registered DID key. That key is hosted by Agreely: generated and held on our side, sealed under your organization's own encryption key. This proves attribution, that a specific registered identity signed a specific claim, never non-repudiation. We say so plainly rather than borrow a stronger word than the mechanism supports.

This proof demonstrates the integrity of a record, recorded and unaltered. It never demonstrates, on its own, the legal validity of what it records.

8. Incident handling and reporting a vulnerability

If we identify, or are notified of, a security incident affecting the Agreely service itself, we investigate, contain and remediate it, then notify the customer organizations affected and, where the law requires it, the Commission d'accès à l'information du Québec (article 3.5).

This is distinct from the confidentiality-incident register the product keeps for each customer about that customer's own obligations (section 3.8): that register is filled in and declared by the customer, not by us.

If you believe you have found a security vulnerability, write to us at the address below. Describe the issue and the steps to reproduce it, avoid accessing information beyond what demonstrates the issue, and give us a reasonable amount of time to respond before any public disclosure. We acknowledge reports and work with you in good faith.

We do not run a paid bug bounty program today.

9. What we do not hold

We do not hold a SOC 2 report, an ISO 27001 certification, or a published independent security audit today. What we have is this page: a factual account, which we will keep current.

No Law 25 certification exists in Quebec: no body issues one, and the Commission d'accès à l'information does not approve or endorse any product.

10. Contact us