Security and data handling
You are being asked for channel data and contract terms. Here is what happens to them.
Written to be forwarded. It includes the things that are built, the things that are not yet built, and the questions a security reviewer would ask that we cannot answer with a yes.
Tenant isolation
One schema, a tenant identifier on every table, and Postgres row-level security enforced per request. The application connects as a database role that cannot bypass it, so isolation does not depend on every query being written correctly.
Because that makes row-level security correctness-critical, it is tested as such: a suite runs the codebase’s queries as one tenant while another tenant’s data is present, and any leakage fails the build rather than producing a ticket.
A dedicated database per tenant is available as a priced option for organisations whose policy requires it. It is not the default, and we would rather tell you that than imply everyone gets one.
Region
Separate database clusters and separate object storage per region. A tenant is pinned to exactly one region, and no data, log, backup or inference request is meant to leave it. Singapore, the EU and the United States are the regions being built for.
The honest state of this today: region pinning is an operational control — configuration and deployment — rather than a property enforced at the routing layer. The routing control is specified and in build. Until it ships, we will describe region residency as operationally assured and not as technically enforced, and if that distinction matters to your policy it should matter to your decision.
Models, and what they are allowed to see
- All model access goes through a single gateway. No provider library is imported anywhere else, and a build check enforces it.
- Inference is pinned to the tenant's region. A Singapore tenant's data is inferred in Singapore or not at all.
- Identifying fields are redacted before they leave the boundary for any task that does not need identity to do its job.
- Provider agreements prohibit training on submitted data. Prompts and templates are versioned with immutable identifiers, so any output can be traced to the exact instruction that produced it.
- Files supplied by partners are treated as untrusted input. A spreadsheet containing instructions aimed at the extractor is a realistic attack and it is tested for.
Your partners never get an account
Distributors upload through a single-use link scoped to one expected file. There is no partner portal, no partner password, and no partner user record — which removes a whole category of credential risk, and happens to be why partners actually send the file.
Email that goes to a partner is plain text, sent on your behalf and signed by your team. No template, no logo, no tracking pixel. A person is accountable for it, so it should look like a person wrote it.
Who can see what
| Role | What it can do |
|---|---|
| Channel ops analyst | The collection console, mapping review, and the agent activity feed. Cannot approve a dispute. |
| Commercial leader | Read across the tenant, plus the reports. No approval rights. |
| Account manager | Only the partners on their assignment list. That is a row filter applied to every query, not a check in the interface — a manager who can see one partner outside their list is a defect. |
| Finance approver | Approves and rejects exceptions, and cannot approve one they created or last edited. That rule is a database constraint, because a rule about who a person is cannot live in a role. |
| IT admin | Users, roles, retention settings, audit export. No access to commercial decisions. |
Every agent action and every human edit is written to an audit trail you can export, with the actor, the time, the inputs and the rule version applied.
What our own staff can see
The design is: read-only, nothing at all without a consent window that your administrator opens, time-boxed to four hours by default and twenty-four at most, and every action written into your audit log under the operator’s own identity rather than the identity of the person being impersonated. If it was us, your audit trail should say so.
The honest state of this today: that mechanism is specified and not yet built. Until it is, support access is a documented manual process with your written approval each time, and the role exists in the specification rather than in the code. That is the safe direction to be wrong in, and it is the kind of thing you should expect a vendor to tell you before you have to ask.
What we do not do, and what we do not have
- Your data is not used to train models, ours or anyone else's.
- Nothing is shared across customers. Cross-customer benchmarking is a later idea and it would be opt-in and anonymised; it does not exist and nothing today depends on it.
- Nothing is written back into your ERP in the first version. Windrose reads and proposes.
- There is no SOC 2 report, because there is no operating history to audit yet. When that changes it will be stated here with the date and the scope, and not before.
A security questionnaire will get a direct answer, including where the answer is no. Send it to hello@windrosechannel.com.