Security and privacy

What Sedge stores, what it never stores, and who can see it.

Sedge sits inside communities where people talk to each other. The design assumption throughout is that the less of that we hold, the better.

What is stored

Counters: how many messages, how many links, how many mentions, in which window.
Content hashes, so a repeat can be recognised without keeping the text.
A bounded message excerpt — but only when a rule actually fires, and only for as long as your retention period allows.
Member display names and identifiers, and phone numbers where the provider gives them.
The full reasoning behind every moderation decision.
An audit trail of every change a person or the system made.

What is never stored

Conversations. Message bodies travel through the analysis queue and are not written to the database.
Anything from a group you did not mark as protected.
Presence, online status or “last seen”.
Read receipts.
Direct messages of any kind.
Media files. Media is counted and typed, never downloaded or kept.

Tenancy

Isolation enforced in the database, not in a query.

Frontend filtering is not isolation, and neither is remembering to add a WHERE clause. Sedge enforces the boundary a layer below the application.

Row-level security: PostgreSQL row-level security is forced on every tenant-scoped table, under a database role that cannot bypass it. A query that forgets its tenant returns nothing rather than everything.
The tenant comes from the session: Never from a parameter, a header or a request body. There is no endpoint anywhere in the API that accepts an organisation id from the caller.
Background jobs are scoped too: Workers open the same tenant scope before touching anything, so a queued job cannot reach across an organisation boundary either.
Live updates are per organisation: The event stream subscribes to a channel derived from the verified session. There is no query parameter that selects a tenant.

Support access

Nobody at Sedge can read your data by default.

Support access is off. Turning it on takes a stated reason and an expiry, and every grant and every use of one is written to your audit trail where you can see it.

Platform staff can always see aggregate counts — how many groups, how many members, how many failed jobs — because that is what running the service requires. They cannot see a message, a member or a moderation case without an active grant from you.

Access inside your organisation

Six roles, gated on permissions rather than titles.

Endpoints check a permission, not a role name, so adding a role later does not mean auditing every check. A role can never grant a role at or above its own rank.

Owner: Full access, including billing and deleting the organisation.
Admin: Runs the product. Cannot delete the organisation or change the plan.
Moderator: Acts on members and can override a decision.
Reviewer: Works the review queues. Cannot change the rules that fill them.
Billing: Sees and manages the subscription. No access to moderation.
Read only: Can see everything, change nothing.

Credentials

Session material never reaches a browser.

A WhatsApp session is the most sensitive thing Sedge holds, and it is treated that way.

Session material and provider credentials are sealed with authenticated encryption before they are stored, and are decrypted only inside the worker that needs them.
The API strips pairing codes, session blobs and credentials from every connection response. There is no endpoint that returns them.
Sign-in uses an http-only cookie on the same origin as the app, so no token is readable from JavaScript and no cross-origin credential sharing is required.
API keys are stored as hashes, are scoped to a subset of the creator’s own permissions, and can never reach the platform console.

The honest part

Risks we cannot engineer away.

A security page that lists only strengths is marketing. These are the things you should weigh before choosing Sedge.

The unofficial provider carries account risk

This is not an official Meta integration. Connecting an account this way is outside WhatsApp’s Terms of Service and the number you link may be restricted or banned by WhatsApp. Use a number you can afford to lose, and read the risk guidance before continuing.

The official API is limited by design. Groups are capped at 8 participants and it only works in groups the business created. Choosing the compliant path costs capability.
Rules get things wrong. A weighted score is not a judgement. That is why monitor mode is the default, why removals open a review case, and why every decision can be reversed.
Excerpts are still personal data. When a rule fires, part of a real message is stored. You control how long for, and you can delete a single member’s data on request.
Members of your groups are not Sedge’s customers. Telling them the group is moderated, and how, is your responsibility. We give you the audit trail to back it up.

Ask us the hard questions before you buy.

We would rather answer them now than have you find out later.