Legal

Security Overview

Last updated August 2, 2026

How Presagon is built and operated: where it runs, how data is encrypted, how accounts and sessions are protected, how workspace data is isolated, when a human at our end can see your data, and how to report a vulnerability. Written to be checkable rather than reassuring.

1. Scope and honesty about our size

This page describes the technical and organisational measures we apply to Presagon. It is referenced by the Privacy Policy and forms part of the Data Processing Agreement.

Presagon is a small, independently run product. We do not hold SOC 2, ISO 27001, or any other third-party certification, and we will not imply otherwise. What follows is what we actually do. Where a control is inherited from a provider rather than built by us, this page says so.

2. Infrastructure

The application runs on Vercel and stores its data in a managed PostgreSQL database provided by Supabase. Public competitor pages are fetched through Cloudflare's browser rendering service rather than from our own infrastructure. Email is delivered by Resend, and payments are handled entirely by Paddle as Merchant of Record. Each provider and what it can receive is listed on the subprocessors page. We do not run our own servers, and we do not operate a physical office that holds customer data.

3. Encryption

All traffic to the site and the application is served over HTTPS with modern TLS; plain HTTP is redirected rather than served. Data at rest is encrypted by our database and hosting providers using the disk-level encryption their managed platforms apply. Secrets and API credentials are held in the hosting platform's encrypted environment store, never in the source repository.

4. Authentication

  1. (a)Passwords are stored only as salted one-way hashes. We never store, log, or transmit a password in a form we could read, and we cannot recover one for you.
  2. (b)Passwords must be at least 8 characters. Completing a password reset revokes every existing session for that account, so a reset ends any access an attacker already had.
  3. (c)Sessions are held in an HTTP-only cookie that JavaScript on the page cannot read, marked secure in production, and expire on their own schedule.
  4. (d)Each session records the IP address and browser it was created from, so unexpected access can be identified and investigated.
  5. (e)Authentication endpoints are rate limited to blunt credential stuffing and brute force.
  6. (f)Administrative privilege is not something any customer-facing input can set. The role field is server-controlled and cannot be granted through signup or profile editing.

5. Access control inside the product

Data is scoped to the workspace that owns it. Every query that reads watches, entries, insights, or product context is constrained to the caller's workspace, so one customer cannot reach another's data by guessing an identifier. Plan limits and feature entitlements are resolved server-side from a single table rather than trusted from the client.

6. Third-party client access

Where you connect an AI assistant or another Model Context Protocol client, it authenticates through a standard OAuth flow: it must be registered, you must sign in, and you must approve the access on a consent screen before a token is issued. Tokens are scoped to your workspace and grant read-only access; no tool exposed to a connected client can modify or delete your data. You can revoke a client at any time, and we can revoke one that is behaving abusively.

7. Staff access

Access to production data is limited to what is needed to operate the service. Administrative tooling can view a workspace as one of its members for support and debugging; when that happens the session records which administrator did it, so the action is attributable after the fact. We use this only to investigate a problem or a support request, and we will tell you if we access your workspace for a reason you did not raise with us.

8. Payment data

We never see, handle, or store card or bank details. The checkout is operated by Paddle as Merchant of Record and payment details go directly to it. We receive only your subscription status, plan, and billing-period dates. Payment webhooks are verified against a signing secret before they are acted on, so a forged billing event cannot change a subscription.

9. Monitoring and resilience

Scheduled jobs report a heartbeat to an external monitor, so a job that stops running raises an alert rather than failing silently. Operational events are delivered to a private channel we control. The database is backed up by our provider on its managed schedule. We do not currently publish a recovery time objective, and we do not offer a contractual uptime guarantee; the Terms of Service say so plainly rather than implying a commitment we do not make.

10. How we fetch monitored pages

We request only publicly accessible pages, at conservative rates, and we do not attempt to defeat access controls, bot protection, or rate limits at a source. Fetching happens through a third-party rendering service, which means the pages we monitor are never fetched from infrastructure that holds customer data. The Acceptable Use Policy sets out what may be pointed at the service.

11. Reporting a vulnerability

Email security@presagon.com. Include enough detail to reproduce the issue, and tell us if you believe it is being actively exploited. We will acknowledge a report within 3 business days and keep you updated until it is resolved.

We will not pursue a researcher who acts in good faith. Test only against your own account and workspace; do not access, modify, or retain anyone else's data; do not degrade the service for others; and give us a reasonable chance to fix an issue before disclosing it. We do not currently run a paid bounty programme, and we will say so up front rather than leaving it ambiguous.

12. Reporting a breach to you

If we become aware of a breach affecting personal data we will investigate immediately, contain it, and notify affected account holders by email without undue delay, along with any supervisory authority the law requires us to inform. Where we act as your processor, clause 10 of the Data Processing Agreement governs what we tell you and when.

13. Contact

Vulnerability reports: security@presagon.com. Security questionnaires, due-diligence requests, and questions about anything on this page: hello@presagon.com.

Related: Subprocessors · Data Processing Agreement · Privacy Policy