Security and subprocessors

This page describes, factually, Agreely's hosting, named subprocessors, encryption, authentication and incident handling. It is written to be attached as is to a vendor risk questionnaire, not to persuade.

Last updated: October 24, 2026

Version: 1.2

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

Agreely's production is hosted in Québec, at OVH, in Beauharnois, on two servers: the first runs the application and its PostgreSQL database, the second runs the background jobs. Database backups are encrypted and kept in two repositories, one on each of these servers, both in Beauharnois.

For our customers, entrusting Agreely with keeping personal information in Québec is a communication (P-39.1, s. 18.3) or release (A-2.1, s. 67.2) necessary for performing a mandate or a contract for services, not one made outside Québec (P-39.1, s. 17; A-2.1, s. 70.1). The emails Agreely sends for its customers do, however, go through the Zoho Mail relay, in the United States: that part remains a communication outside Québec, which calls for each customer's own privacy impact assessment. Cookie categorization for banners also relies on Anthropic, in the United States, using metadata designed to contain no personal information. See our privacy policy for the full scope.

We administer both servers ourselves: the operating system, the firewall and patching are Agreely's responsibility. OVH provides the servers, the data centre and the network.

The public status page, status.agreely.ca, is also hosted at OVH, in Beauharnois: it only checks that our services are available and holds no customer data.

3. Named subprocessors

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

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, no personal information in the clear. 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 is encrypted with TLS: the PostgreSQL server refuses any unencrypted network connection. Its certificate is not, however, verified by a certificate authority; between our two servers, the connection also runs through an encrypted WireGuard tunnel, which authenticates each machine by its key.

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.

What Agreely checks before anchoring

Since October 22, 2026, Agreely's application computes an authentication code, using a key held by Agreely, at the moment it records an item. Before anchoring a root on chain, Agreely checks that every item the root groups is covered by a valid code. An item altered or added directly in the database without that key is not anchored, and Agreely's operations team is alerted. The key is kept on Agreely's servers: this check is defence in depth against access to the database alone, not against someone who controls those servers or the application's code, and no one outside Agreely can verify the code. It does not cover an event the application never recorded, anything done through the application or its API with valid credentials (even stolen ones), the label that ties a root to an organization on chain, or roots anchored at or before Base block 52929948 (October 22, 2026) and the items they group.

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

Questions about this page, or a security issue to report?

David Tucker, person in charge of the protection of personal information
Ophelios Studio
david.tucker@ophelios.com