What we do with what you give us.

Termn holds signed agreements, bank instructions, and the evidence that money moved. That is a serious thing to hand a company you have not met. Below is what happens to it, written so you can check the claims rather than trust them: each one names the file in Termn’s own codebase that makes it true.

Send a security question About the company

No customer data leaves the providers named here · Termn never holds your money · Nothing on this page is a certification

Where your data lives and who touches it

The service runs on a small, named set of providers. Each one is here because some part of the product cannot work without it.

The application, its background worker, and its database run on Fly.io in a single primary region, San Jose (sjc). Document rendering runs as a separate Fly application in the same region, reachable only from the app.
fly.toml
Uploads and recorded evidence are held in S3-compatible object storage, in two separate buckets: one for what people upload, one for evidence filed against an agreement.
termn/settings.py
Email is delivered by Resend. Every message Termn sends is recorded first, with its purpose, so what was sent on your behalf is auditable rather than assumed.
apps/core/email_backends.py
Card and bank payments are processed by Stripe, on the receiving organization's own connected account. Money settles to them; it does not pass through a Termn account.
apps/movements/connect.py
Google's tag loads only on public marketing pages and on one generic post-signup receipt page that carries no account, organization, or participant data. It is never served on an application screen or a participant link, and it is absent entirely unless a container id is configured.
apps/core/middleware.py

What never reaches a Termn server

The most useful security property is the data we arranged not to hold.

Card numbers. Payment details are entered inside Stripe's own hosted element; the application never receives or stores a card, routing, or account number from a payer.
templates/participant/fund.html
Receiving bank instructions are never placed in an email, a link, or an analytics payload. They are shown behind a link scoped to funding, and only after the signatures that unseal them.
apps/core/models.py
Behaviour is never used to identify a person. A browser is bound to an identity only when someone signs in, which is their own act.
apps/portal/auth_views.py
Termn never takes custody of money or of any asset an agreement moves, and never asks a payer to connect their bank account to Termn.
apps/movements/models.py

Who can see what

Authority in Termn is a membership in an organization, and every screen checks it. Participants are not members: they hold single-purpose links instead.

Every application screen resolves the acting organization first and refuses the request when there is none. Administrative screens check for an owner or administrator separately.
apps/portal/views.py
Participant links are single-purpose. Signing, viewing funding instructions, confirming money arrived, reading a record, and paying for a workspace are five different credentials; holding one does not open another.
apps/core/models.py
Sign-in links work once and expire in thirty minutes. A spent link is recorded as spent, so a forwarded email cannot be replayed.
apps/portal/auth_views.py
Accounts can add a TOTP second factor, checked before the session is created.
apps/portal/auth_views.py
Pages carrying participant data are served no-store, so a shared or borrowed browser does not keep them.
apps/core/middleware.py

Keeping, and deleting

Evidence is worth something because it cannot be quietly changed, which puts real limits on what deletion can mean. Those limits are stated, not implied.

Every consequential action is written to an append-only audit record naming who did it and when.
apps/core/audit.py
Evidence, signatures, and audit records are kept for as long as the organization exists, because a record that can be quietly revised is not evidence.
templates/public/privacy.html
A completed agreement's settlement record is emailed to every participant, so the parties' copies do not depend on Termn continuing to exist.
apps/agreements/services.py
Anyone who was sent an agreement can recover everything sent to their address at /my, without an account, by proving the address.
apps/portal/hub.py

The application itself

Ordinary hardening, listed so you can check it rather than assume it.

HTTPS is forced at the edge and in the application, with HSTS set to one year including subdomains. Session and CSRF cookies are secure and same-site.
termn/settings.py
A Content Security Policy is set on every response, with framing denied, no object sources, and a script allowance narrow enough that Stripe is the only third-party origin on an application page.
apps/core/middleware.py
Outbound requests made on your behalf, such as webhooks, are checked against private and link-local address ranges before they are made.
apps/api/urlguard.py
The public API is generated from a published schema, and a test fails when the published schema drifts from the running one.
apps/api/tests.py

What this page does not answer yet

These are the questions a legal or procurement reader asks that cannot be answered by reading the code, so they are not answered here. Listing them is not a substitute for answering them. Until they are answered, write to us and a person will tell you where each one stands.

The company's registered address
KindredPath LLC's registered business address and jurisdiction of formation. The name is already on the terms, the receipt, and every footer; the address is what a procurement form asks for.
An accountable human
A named person, or at least a named role, and a security contact address for reporting a vulnerability, separate from sales@termn.ai.
Encryption at rest
Whether the database volume and the object storage buckets are encrypted at rest, and by whom. The providers very likely do this; nothing in this repository proves it, so it must not be claimed here until someone confirms it against the provider's own configuration.
Backups and recovery
Backup frequency, retention period, where backups are held, and whether a restore has ever been tested. No backup configuration lives in this repository.
Deletion on request
What happens when a customer asks for their data to be deleted, given that evidence and audit records are deliberately immutable. This needs a written answer and probably a mechanism; today there is neither.
Incident response
Who is notified, how fast, and by what channel when there is a breach or a significant outage. Including the notification commitment made to customers.
A Data Processing Agreement
Whether a DPA is available on request, and the standard contractual clauses position for customers outside the United States.
Support expectations
The response time a customer can actually expect, on which channels, and what changes about that with an Operator subscription.

Why it reads like this

A security page is easy to write and hard to mean. Most are a list of adjectives with nothing behind them, and the parts a buyer actually relies on are the parts nobody checked. So this one only says things that are true in the code, names where each one lives, and keeps a visible list of what it cannot answer yet. When something on that list gets a real answer, it moves up the page.

Finish what the agreement started

Your first workspace is free: one live workspace, unlimited agreements inside it, no card.

Close your first deal free

Rather talk it through first? Contact us at sales@termn.ai.