Privacy Policy

Crew Platforms, Inc. ("Crew") provides a service that companies use to direct work. Where a company uses Crew, that company decides what information is put into its workspace, which systems are connected, and what its AI employees are permitted to do. Crew processes that information to provide the service on the company's instructions.

If you are an individual whose information appears in a Crew workspace — for example, because you corresponded with a company that uses Crew — that company is responsible for it, and requests about it should be directed to them. Crew will assist a customer in responding to such a request.

This policy also covers the limited information Crew collects directly, such as an account holder's own details and a request submitted through this website.

Crew collects four kinds of information. Each is described in the section that follows.

Account information

The name and email address of each person in a workspace, their role, and the workspace's own details. Account identity is handled by Crew's authentication provider; where a person signs in with Google or Apple, Crew receives the identity that provider returns rather than a password.

Customer content

The material a workspace works with. Described in section 3.

Credentials

Authorisations for the services a customer connects, and keys a customer stores. Described in section 4.

Operational and usage information

Crew's record of what the service did. Described in section 5.

Crew does not run advertising or analytics trackers, and does not buy or receive personal information from data brokers.

"Customer Content" means the material a workspace works with: messages and documents an AI employee reads from a connected service, files uploaded to it, code and documents it produces, the messages exchanged in a conversation, recorded company knowledge, and the work it delivers.

Most Customer Content is not stored by Crew. It is retrieved from the customer's own systems while an employee is working, used for that work, and not retained. Content is stored durably only where retention is the purpose — recorded knowledge, an employee's saved notes, conversation history, delivered files, and the body of an inbound event while it is being processed.

Customer Content is confidential. It is reachable only from within the workspace it belongs to, and is not used for any purpose beyond providing the service to that workspace. Section 7 describes how it is treated in relation to model providers and training.

When a customer connects a service, Crew stores the authorisation needed to act on that service. When a customer stores an API key, Crew stores that key. Both are encrypted with AES-256-GCM before they are written and are decrypted only at the moment of the call that requires them.

A stored credential is never returned to a browser, never written to a log, and never included in the context sent to a model provider. Where a credential must reach an external service, Crew makes the request itself and returns only the result. Each stored key carries its own restrictions — which hosts it may be sent to, which employees may use it, and whether each use requires an approval.

Credentials are excluded from a customer's own export: the export replaces each with a marker indicating that the key should be rotated with its provider.

Crew keeps a structured record of what the service did: which capability ran, which employee ran it, which workspace it belonged to, how long it took, what it cost, whether it succeeded, what required approval and who decided it, and what was retried. This is how the service bills accurately, presents an audit trail, and is diagnosed when it fails.

These are bounded fields rather than free text. The content an operation acted on is not part of this record — an execution record names the capability and the provider, not the message that was sent.

Crew also receives error reports from the application. Request bodies, cookies and authorisation headers are removed before an error is sent, session replay is not enabled, and reports that cannot be established as safe are discarded rather than delivered.

Crew uses information to:

• –provide the service — running the work a customer directs, and operating the connections it authorises;
• –authenticate people, enforce roles and permissions, and maintain an audit trail of decisions;
• –meter and bill usage accurately;
• –diagnose, secure and improve the reliability of the service; and
• –communicate with customers about their account, billing, security and material changes to the service.

Crew does not sell personal information and does not share it for cross-context behavioural advertising. Crew does not use Customer Content for product analytics: the analytics projections defined in the codebase are limited to operational fields, and content columns are excluded from them by an explicit list.

Where Crew analyses how the service is performing, that analysis uses operational information. Crew does not currently operate a data warehouse and no process reads across customer workspaces.

Crew's AI employees run on large language models provided by third parties. To perform work a customer has directed, Crew sends the working context of that task to a model provider: the relevant company knowledge, the employee's notes, the conversation, the results of tools it called, and the material it read.

Crew does not use Customer Content to train models. Crew does not operate model training, and no pipeline in the product exports content for that purpose.

Model providers are subject to their own terms, which govern what they do with what they receive. Crew identifies each provider in the Subprocessors disclosure so that a customer can review those terms directly. Crew does not restate a provider's commitments as its own.

Crew uses a small number of vendors to provide the service — for hosting and data storage, model processing, connected-application infrastructure, execution environments, search and retrieval, payments and error reporting. Each receives only the information required for its function.

The Subprocessors disclosure lists every one of them, the purpose it serves, and the categories of data it may process. It is maintained from the application's own source and is updated when a vendor is added or removed.

Crew may also disclose information in connection with a merger, acquisition or sale of assets, in which case the recipient remains bound by this policy or a successor to it.

Services a customer connects — mail, file storage, code repositories, messaging, payment accounts — are not Crew's vendors. Crew accesses them on the authorisation the customer granted, for the actions the customer's permission settings allow, and holds no relationship with those providers of its own.

Information sent to or received from a connected service is governed by the customer's agreement with that provider. Where a provider supports programmatic revocation, disconnecting in Crew revokes the authorisation with that provider before Crew deletes its own record of it; where it does not, the product identifies what the customer must do directly.

Crew's default is to retain a workspace's information for as long as the workspace exists, so that a customer's history remains available to them. Information is deleted when a customer deletes it, or when the workspace is erased under section 11.

Three categories are the exception and expire on a defined schedule:

Inbound event payloads — 7 days

The raw body of an incoming webhook, which for a mail trigger is a message. It is size-limited on arrival and removed after seven days. A permanent diagnostic record is derived from it first, containing the payload's structure, the provider's own message identifiers, and the result of the customer's filter — including the value at the path that filter examined, limited to 200 characters. That record is what allows a customer to establish later why a rule did or did not fire, without Crew retaining a copy of the message.

Unaccepted invitations — 90 days

An invitation that was never accepted is an email address retained for no remaining purpose once its link has expired.

Generated exports — 7 days

A generated export is a derived copy; the information it contains remains in the systems it was drawn from. The file and its stored object are removed after seven days.

Every table in the application declares its retention rule alongside what it holds, and an automated test checks those declarations against the live database, so a new store of information cannot be added without one.

Export

An owner may request a structured export of the whole workspace from the product's settings. It is assembled from a defined list of tables rather than produced as a dump with exclusions; stored credentials are withheld and replaced with a marker; and operator notes are excluded. The file is delivered through an authenticated route that issues a sixty-second link rather than a durable URL, and it expires after seven days.

Deletion

An owner — and only an owner — may delete a workspace. Deletion requires the workspace name to be typed in full and a fresh proof of identity: a password, or a one-time code sent to the address on the account where that account signs in with an identity provider. Connected services are revoked with their providers immediately, and all scheduled and running work stops in the same operation that schedules the deletion.

Grace period

A deleted workspace enters a thirty-day grace period, during which an owner may cancel the deletion. At the end of it, the data is erased across the database, file storage, the employees' execution environments and the connector accounts. Crew retains a minimal accounting record of amounts billed, in a form structurally incapable of holding Customer Content. After erasure Crew cannot recover the workspace.

Individuals may also contact Crew at the address in section 16 to ask what information is held about them, to correct it, or to request its deletion. Where the information belongs to a customer's workspace, Crew will direct the request to that customer and assist them in responding.

Each workspace's data is isolated at the database level; credentials are encrypted at rest and used through a broker rather than handed to the components that need them; AI employees run in isolated execution environments with configurable network restrictions; and inbound events are cryptographically verified before they are processed.

The Security page describes these controls in more detail. No system is completely secure, and Crew does not represent that its service is.

Crew may disclose information where it is required to do so by law, or where it reasonably believes disclosure is necessary to comply with a legal process, to enforce its terms, or to protect the rights, safety or property of Crew, its customers or the public.

Where Crew receives a legally binding request for a customer's information, it will notify that customer so they may respond, unless it is prohibited from doing so or the request relates to an emergency involving a risk to life.

Crew is a service for businesses and is not directed at children. Crew does not knowingly collect personal information from anyone under 18. If you believe a child has provided information to Crew, contact the address in section 16 and it will be deleted.

Crew may update this policy as the service develops. The date at the top of this document indicates when the current version took effect, and is the last date on which every statement in it was checked against the product.

Where a change materially affects how information is handled, Crew will notify customers before it takes effect.

Questions about this policy, or requests concerning information Crew holds, may be sent to the address below.