Skip to main content
When you run a workflow on ModuleX, your data passes through it: the documents in your knowledge bases, the credentials that connect your tools, and the records of what ran and when. This page explains, in plain language, how ModuleX handles that data, how it keeps each organization’s data separate, and how long it is kept. For the engineering mechanics behind these promises, see Security overview. For certifications and the third parties involved, see Compliance and Sub-processors.

Kept separate

Every workflow, credential, and document belongs to exactly one organization, and stays there.

Handled with care

Connected credentials are encrypted, sensitive values are hidden from logs, and secrets are never shown back in full.

Kept only as needed

Your records live as long as your organization does. Delete the organization and its data is removed with it.

​
Every organization is its own boundary

In ModuleX, an organization is the unit that owns your work and the line that separates it from everyone else’s. Your workflows, runs, credentials, knowledge bases, chats, plan, and bill all live inside one organization.

One owner per record

Every resource you create is stamped with its organization. There is no shared pool, and one organization’s data is never visible to another.

Checked on every request

Org-scoped requests carry the X-Organization-ID header. ModuleX confirms you belong to that organization, and your role in it, before it runs anything, not just at sign-in.

Keys can be locked to one org

An API key scoped to a single organization cannot act on another, even if it is shared by mistake. ModuleX rejects the request.

No cross-org reads

Every read and write is filtered by organization, so a query can only ever return the data of the organization the request runs in.
Because the organization is the boundary, tenancy isolation is something ModuleX enforces on every database read and write, not a setting you have to turn on. For exactly how the organization header is checked and how a key is bound to one organization, see Org context & X-Organization-ID.

​
How your data is handled

ModuleX holds a small set of things worth protecting: the credentials that connect your tools, the documents you upload, and the logs of what happened. Each is handled differently.
When you connect a service, ModuleX stores a credential: an encrypted record that lets your workflows act on your behalf.
  • The secret part of every credential is encrypted before it is written to the database, with a key derived for that one credential in that one organization.
  • A credential is decrypted in memory only at the moment a workflow or agent needs it, then used to call the connected service.
  • When you view a credential in the app or through the API, ModuleX returns a masked value such as start***end, never the secret in full.
The encryption and key-management details are documented for engineers in Data security & encryption.
Each stored credential is encrypted with a key unique to that credential and its organization, derived from a master encryption key that ModuleX keeps as a managed secret. Because the per-credential key depends on both the organization and the credential, ciphertext from one credential cannot be unlocked as another, even within the same organization. ModuleX requires that master secret to be present and strong before it will start in a production environment, and it can be sourced from a managed secret store. The full rules are in Data security & encryption.
This is a data-handling commitment, not a code-level fact, so it is not asserted here. TBD — confirm ModuleX’s stance on using customer data for model training on the Compliance page before relying on it. When you bring your own model provider, that usage runs under your provider’s terms; see LLM providers.

​
How long data is kept

Your records are kept for as long as you need them, and removed when your organization is.

Active for as long as your org is

Workflows, runs, credentials, knowledge bases, and chats stay available while your organization exists, so your history and your connected tools keep working.

Removed when the org is deleted

Deleting an organization removes the data tied to it, including its workflows, runs, credentials, knowledge bases, and wallet records.
When an organization is deleted, its records are removed as a group. Some history that records who did something keeps the action but unlinks the person, so removing a teammate’s account does not erase the record that an action occurred. The exact relationships are documented in the Data model reference.

​
The audit trail

ModuleX keeps a unified audit log per organization that records important actions: who did something, what they did, and when. It exists so an organization can review activity for accountability and compliance.
  • The configured retention for the audit log is 365 days (one year).
  • Audit entries are scoped to the organization, like every other record.
The 365-day figure is the audit-log retention configured in ModuleX. Whether older entries are automatically purged on a managed deployment, and any contractual retention or deletion commitments, are not asserted here. TBD — confirm the operative retention and deletion terms on the Compliance page or in your agreement.

​
Compliance posture

ModuleX’s compliance details, including any certifications and audits, data residency, and the formal data processing terms, are maintained on dedicated pages rather than asserted here, so the information you rely on is the current, verified version.
This page does not claim any specific certification (such as SOC 2, ISO 27001, GDPR alignment, or HIPAA), data-residency region, or signed data processing agreement. TBD — those claims are unverified at the time of writing. Check the pages below, or contact the ModuleX team, before relying on any compliance statement.

Compliance

ModuleX’s compliance posture, certifications, and data-residency details.

Sub-processors

The third parties that may process data on ModuleX’s behalf, and how changes are announced.

​
Where to go next

Security overview

The plain-language tour of how ModuleX secures access, credentials, and tenancy.

Data security & encryption

How credentials are encrypted at rest, plus key management and production checks.

Roles & permissions

The owner and admin roles, and which actions each can take.