Legal and security
Trust and security
How Tenure handles your subscribers' data, your billing, and your AI agents.
Encrypted at rest
AES-256-GCM under a key the deployment holds, never the database.
Five roles
Plus an IP allowlist by CIDR. A role change drops existing sessions.
Hash-chained log
Every decision recorded so an edit or a deletion is detectable.
Signed events
HMAC-SHA256 over timestamp and body, eight retries with backoff.
Tenant isolation
Every record is scoped to an organization id and every query is filtered by the signed-in user's organization or the API key's organization. Public widget keys can only create and resolve cancel sessions.
Credentials
Passwords are bcrypt-hashed. API keys are shown once and stored as SHA-256 hashes; they carry scopes, an optional expiry and a test-mode flag. Sessions are encrypted, HttpOnly, SameSite cookies that are invalidated on password change, on password reset and by "Sign out everywhere".
Secrets at rest
The credentials you connect (Stripe, Chargebee, Paddle, Braintree, Maxio, Anthropic, Resend, HubSpot, Mailchimp, Salesforce, live and test billing keys, and webhook and widget signing secrets) are encrypted at rest with AES-256-GCM under a key (SECRETS_KEY) that lives only in the deployment environment, never in the database. Keys can be rotated with a documented script; the dashboard shows only the last four characters.
Access control
Five roles gate every configuration action server-side: owner (everything, including roles and deleting the workspace), admin (configuration, integrations and invites), developer (reads everything and manages API keys and webhooks, but not billing execution settings or the team), member (works cancel sessions, settings read-only) and viewer (read-only). Owners and admins can restrict the dashboard to an IP allowlist (CIDR). Changing someone's role signs their existing sessions out. The full permission matrix is in the security documentation that ships with Tenure.
Billing safety
Offers execute only from the approved library, only after an explicit accept, only server-side. Agents receive guardrails (max discount, no improvisation) and cannot call billing directly. The cancel path always proceeds even if Tenure is down.
Outbound webhooks
Signed with HMAC-SHA256 over timestamp + body (x-tenure-signature, x-tenure-timestamp) so your backend can verify origin and reject replays. Every delivery is recorded with status, attempts and response code; failed sends retry with exponential backoff (up to 8 attempts) and can be replayed from the Webhook deliveries list on the Integrations page. Stripe webhooks are verified with your signing secret.
Data minimisation
Tenure stores the fields you send (plan, MRR, tenure, usage signals) and cancel-session outcomes. Customers can be erased with all their sessions from the dashboard or by deleting them via the API. Owners can export the whole workspace as JSON or delete it outright (all child records cascade).
Auditability
Every decision, execution, email and admin change is written to a hash-chained, verifiable audit log per organization: each row's SHA-256 hash covers the previous row, so deletions or edits are detectable with the Verify integrity check. The log is exportable as CSV or JSON by owners and admins, and retention is configurable per workspace (default 365 days; 0 keeps it forever). Rows past that age are purged nightly, and the purge itself is written to the log. Requests carry an x-request-id that is echoed in responses and structured logs for correlation.
How the control group works
A fixed percentage of cancelling customers (default 10%, configurable) is assigned by a deterministic hash of the customer id and never shown an offer. Lift is the difference in retention (did not confirm cancellation) between offered and holdout subscribers, computed with the same rule for both groups; revenue kept counts only saves beyond what the holdout shows would have happened anyway. Test-mode, email and unfinished cancel sessions are excluded. Experiments use two-proportion confidence intervals with a sample-ratio check.
Decisioning model
The fit score is a transparent weighted model over tenure, lifetime value, usage, recency, discount-seeking and prior saves; offer ranking is a Thompson-sampling bandit per segment (with per-offer eligibility rules and budget caps). Claude is used only for talking points and the negotiating chat when you supply an API key; no customer data is used to train models.
Subprocessors
Only the services you connect receive data: your billing provider (Stripe, Chargebee, Paddle, Braintree or Maxio) for billing changes, Resend (email), Anthropic (talking points and chat, when enabled), HubSpot, Salesforce and Mailchimp (customer import). Nothing is sent to a service you have not configured. The encryption key for stored secrets lives in the deployment environment's secret store, never in the database, and Tenure uses no external key-management service.
Data residency
Tenure is a hosted service. Your workspace's data is stored in the region of your deployment and is isolated from every other workspace by organization id on every query.
Responsible disclosure
Found a vulnerability? Email security@trytenure.co (see /.well-known/security.txt). Please do not test against other tenants' data.