Security & trust

Your schedule is your most confidential document. We built like it.

A program plan exposes your launch dates, vendor dependencies, and risk posture. Foreweave's tenancy, access, and AI data-handling models were designed for exactly that sensitivity — partner and client schedules living on the same platform without ever seeing each other.

Org A — your company Org B — another customer Product launch Platform migration R&D program Their joint plan Their migration a query that forgets its tenant filter… …is refused by row-level security in the database, not by code remembering to filter

Tenant isolation, enforced in the database

Every organization is a hard boundary, and it is enforced twice: authorization checks tenant scope before it checks your role, and row-level security in PostgreSQL backs it up — a query that forgets its tenant filter still returns no cross-tenant rows. It fails closed, so anything running outside a request (a background job, a maintenance command) sees nothing until it declares whose data it is acting on.

Two-layer, role-based access

An organization role governs membership; a per-project role (Owner, Editor, Viewer) governs every action. Users hold different roles on different projects, and authorization is checked in the model — not left to the UI.

Accounts that resist the boring attacks

Sessions are hashed, expiring bearer tokens with both an absolute and an idle clock, revocable at any time. Passwords are length-checked against a breached-password list; repeated failures back off without ever letting an attacker lock an owner out of their own workspace. Sign-up and sign-in answer identically whether or not an address already exists, so neither can be used to enumerate your people.

Verified addresses, and a service that refuses to start misconfigured

A new account proves its email before it can reach any plan. On our side the configuration itself fails closed: with debug off, the service will not boot without a real secret key, a pinned host list, a proxy count and a shared cache — because a rate limit that silently degrades to per-process is not a rate limit. Dependencies are pinned by hash and audited on every build.

Encryption and authentication, table stakes done right

All traffic over TLS with HSTS, data encrypted at rest, sign-in through your identity provider via OpenID Connect against an allow-list of issuers, and no secrets in client code. An append-only audit trail records who changed what, when, on every schedule — and you can replay any task's date history from it.

Every file you upload is treated as hostile

MS Project XML is parsed with external entities and entity expansion disabled, and oversized documents are refused before parsing rather than after. Spreadsheet ingestion is bounded on size, sheets, shapes, cells scanned and wall-clock time, with a decompression ratio ceiling so an archive bomb cannot spend your workers. Exports are bounded too, and refuse with an explanation rather than timing out.

AI agent data handling

The agent is powerful. So it's caged.

The scheduling agent uses an external model provider — and we treat that as the confidentiality decision it is. Here is exactly how schedule content is handled:

  • Off by default, per user too Disabled for every tenant until an admin explicitly opts in — the disclosure acknowledgement is recorded (who, when) — and during staged rollout each individual account additionally needs an explicit, audited platform grant before the agent will respond to it at all.
  • Zero retention Model calls go through a zero-data-retention endpoint under a data-processing agreement that prohibits training on your data.
  • Redaction everywhere Configured confidential identifiers — program codenames, client names, part numbers — are tokenized in every payload sent to the provider, including the agent's own tool results, and restored only for your authorized members. Stored conversations keep the tokenized form; the mapping is encrypted.
  • No privileged path Agent tool calls run through the same validation as human edits. It drafts into scenarios; only you touch the baseline. Provenance on anything it writes is derived on our side and cannot be supplied by the caller.
  • Schedule content is data, not instructions Your tasks, notes and uploaded files reach the model inside explicit untrusted-content delimiters. Text that looks like a command in a task name is treated as a task name.
  • Fully audited and metered Every prompt, response, and tool action is logged per tenant, linked to the conversation and the scenario it touched, with per-user and per-organization token and cost reporting.

Document Studio — a different data path, stated plainly

The one place the zero-retention promise does not apply

Document Studio builds a .pptx, .docx or .pdf from a slice of your schedule. It runs on the provider's document-authoring skills and code-execution sandbox, and that path is not zero-retention — nor can we redact it, because tokenised names would land in the finished file. So the control is consent and scope instead:

  • It is off at the platform level and stays off until an operator enables it. Ask us; it is not a switch you can flip by accident.
  • Once on, five gates must all pass before a single document is built: the platform switch, a recorded organization-admin acknowledgement of the retention difference, a per-project enable, an AI-access grant covering that account — held individually or through your organization's approved access — and a write role on that project. Revoking any one of them stops the next build.
  • Only the slice you declare is sent — out-of-scope tasks and cost data never leave, and an empty scope is reported as empty rather than invented.
  • The provider-side copy of the finished file is deleted immediately after we retrieve it.
  • The scheduling agent's own path is untouched by any of this: it remains zero-retention and redacted.

Commitments at a glance

AreaCommitment
Availability99.5% monthly availability target for the API, with public status reporting.
IsolationShared schema with Postgres row-level security, failing closed. One model for every customer — we do not offer a dedicated-database tier today, and would rather say so than imply one.
Agent regionThe AI agent's model endpoint can be pinned per project to a specific region. This is endpoint routing, not full platform data residency — ask us what that means for your obligations.
AuditabilityAppend-only change history per project; deterministic engine means any computed schedule is reproducible from its inputs, and any simulation from its stored seed.
InterchangeYour data is never locked in — full MS Project XML export at any time, plus per-view PDF/PNG and a task-table CSV.

Questions, security reviews, or a vendor questionnaire to fill? Talk to us — we enjoy these conversations more than most vendors.