Secure from row one

Isolated at the row

Every tenant-bearing table carries a row-level policy, and the runtime connects as the role those policies apply to. A connection that has not declared its tenant sees nothing and can write nothing. A forgotten call site fails closed, never open.

Isolation is a tier you choose, and it is configuration rather than code: a shared schema with a tenant key on every row, a schema per tenant on the same migrations, or a dedicated database. Moving up a tier changes no model, no screen and no engine.

Permissions that hold on every door

The rule is one line: effective data = grants ∩ scope. A grant says what a role may see and do; a scope, a saved selection of members, can only narrow it, never widen it. The same rule walls every grid, chart, run, export, scenario, the explanation panel and the governed SQL console. There are no side channels.

The selections that define access are the same named sets that filter a grid or scope a forecast run: one grammar for analysis, execution and access. And the sets themselves are securable objects.

Nothing changes without a record

Configuration is versioned and diffable, with change sets that roll back automatically when a step fails. A plan edit carries who, when, what-from and what-to, and its source. A published cycle is an immutable snapshot you can compare against; upgrades arrive as a three-way diff against your own customisations, with conflicts named rather than overwritten.

Every run is governed: it carries its own scope record: what it ran on, with which parameters, what it wrote, so a number can be traced to the run, the version and the inputs that produced it.

Governed execution

User-authored code enters through one door only: as a versioned plug-in that runs sandboxed, resource-limited and lineaged, behind an explicit execute permission. There is no ungoverned inline script step anywhere in the product, and a hostile source is refused at registration.

Behind the plug-in contract sits a governed SQL workspace: read-only by default, audited always, and walled by the same grants as every other door.

Observability with zero external egress

Metrics, traces and logs are collected by a self-hosted observability stack inside the deployment. Nothing is sent to a service of ours to make the platform work: no telemetry phone-home, no usage beacon, no external dependency on the request path.

Where your data lives

The fact store is an adapter, not a dependency: an embedded columnar engine on a single machine or a scale-out column store, chosen by configuration, with Apache Arrow as the interchange between them. A cloud-warehouse adapter is designed behind the same contract; two adapters are in the tree today. The control plane, the model, the policies, the audit, is a relational database you host.

So the answer to "where is our data?" is decided by the adapter you pick and the place you run it: your cloud account, your data centre, or a single machine. The model, the math and the screens are the same in all three.

Reporting a vulnerability

If you believe you have found a security issue in the platform or in this website, write to security@plansieve.com. Include what you found, where, and the steps to reproduce it; a proof of concept helps, a working exploit is not needed.

A person acknowledges every report and keeps you informed until it is resolved. Good-faith research reported privately is welcome; please do not access or alter data that is not yours, and give us reasonable time to fix before disclosing publicly.

Certifications

Sub-processors

This website uses a small number of service providers: the host and its verification and analytics services, and the relay that carries the contact form. They are listed, with their roles, on the sub-processors page. A platform deployment adds none of ours: it runs where you run it.