Skip to main content
ModuleX runs your workflows against the tools, models, and documents you connect. That means it holds things worth protecting: the keys to your connected services, your company knowledge, and the access rules for your team. This page is the plain-language tour of how ModuleX keeps each of those safe. It covers three layers: how you and your code prove who you are, how connected credentials are encrypted, and how each organization’s work stays separate from everyone else’s. Each section links to a detailed page when you want the exact mechanics.

Who can get in

People sign in once through a single identity provider, and code authenticates with API keys you can scope and revoke.

Your secrets, encrypted

The credentials you connect are encrypted before they are stored, and never shown back to you in full.

Kept separate

Every organization is its own boundary. One organization’s data, access, and bill never reach another.

​
How access works

ModuleX has one identity for people and a separate, purpose-built credential for code. Both have to be present before any request runs.

People sign in once

Everyone who uses the ModuleX app signs in through a single identity provider. ModuleX does not store your password, and there is no separate ModuleX login to manage.

Code uses API keys

Scripts, the SDKs, and your own product authenticate with a ModuleX API key. Keys are created in the app, scoped to what they need, and can be revoked at any time.
These are two paths to the same checkpoint. The app uses the human sign-in; the API and the SDKs use an API key. For the full picture of when each is used and how ModuleX tells them apart, see Auth model: JWT vs API key.

​
Authenticating from code

Every programmatic request carries two things: your API key as a bearer token, and the organization the request runs in. The API key always begins with mx_live_. 
curl https://api.modulex.dev/workflows \
  -H "Authorization: Bearer mx_live_2J9vK4xM7pQ1sR8tU3wY6zB" \
  -H "X-Organization-ID: 8a1f3c2e-9b4d-4e7a-bc11-7d6e5f4a3b2c"
The authentication header is Authorization: Bearer followed by your mx_live_ key, plus the X-Organization-ID header. These two headers travel together on every org-scoped request. See Authentication for the complete reference.

​
Keys you control

API keys are built to be handed out carefully and taken back cleanly.

Scoped to one organization

A key can be locked to a single organization. If a request uses that key for any other organization, ModuleX rejects it.

Never stored in the clear

ModuleX keeps a one-way hash of each key, not the key itself. The full key is shown only once, when you create it.

Rate limited

Each key and each user has a request limit, so a leaked or runaway key cannot overwhelm your account.
Because only a hash is stored, ModuleX cannot show you a key again after you create it. Save it somewhere safe, and if it leaks, revoke it and issue a new one.

​
Your credentials stay encrypted

When you connect a service, such as a GitHub account, a Slack workspace, or a model provider, ModuleX stores a credential: an encrypted record that lets your workflows act on your behalf. Protecting those credentials is the heart of ModuleX’s data security.
1

You connect a service

You authorize ModuleX through the service’s own login, or you paste in an API key. For services that support it, ModuleX uses the OAuth2 authorization flow with PKCE, so it never has to handle your password.
2

ModuleX encrypts it before storing

The secret part of the credential is encrypted before it is written to the database. Each credential is encrypted with a key derived for that one credential in that one organization, so a credential cannot be unlocked outside the organization it belongs to.
3

It is decrypted only to run your work

The credential is decrypted in memory only at the moment a workflow or agent needs it, then used to call the connected service.
4

You only ever see it masked

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.
🎬 MEDIA PLACEHOLDER · MX-MEDIA-4210 · [IMAGE] [IMAGE_DESCRIPTION]: A simple lifecycle diagram showing how a connected credential is encrypted at rest and decrypted only at run time. [IMAGE_DETAILS]: Left-to-right flow, four labeled stages: “You connect a service” (an OAuth or API-key icon), “Encrypted with a per-credential key” (a padlock over an organization boundary), “Stored in the database” (a database cylinder showing scrambled ciphertext), and “Decrypted in memory only to run your workflow” (a play icon feeding a workflow node). Add a small side note “Shown back to you masked: start***end”. 1600x900, light theme, ModuleX brand greys, no photography, minimal text inside shapes.
Each stored credential is encrypted with a key that is 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 decrypted as another, even within the same organization. The exact derivation and key-management details are documented for engineers in Data security & encryption.
API keys are stored as one-way hashes rather than recoverable values, so even ModuleX cannot read them back. The master secrets that protect credentials and hash API keys are required to be present and strong before ModuleX will start in a production environment, and they can be sourced from a managed secret store. The full configuration rules are in Data security & encryption.

​
Every organization stays separate

In ModuleX, an organization is the boundary around your work. Your workflows, credentials, knowledge bases, plan, and bill all live inside it, and stay separate from every other organization’s.

One boundary per organization

Every resource you create belongs to exactly one organization. Data is not shared across organizations.

Every request names its organization

Org-scoped requests carry the X-Organization-ID header. ModuleX checks that you are a member of that organization before it runs anything.

Membership is verified each time

ModuleX confirms your membership and role for the named organization on every request, not just at sign-in.

Keys can be locked down

An API key scoped to one organization simply cannot act on another, even if it is shared by mistake.
If a request leaves out the organization, or names one you do not belong to, ModuleX rejects it rather than guessing. The header handling, how an API key is bound to a single organization, and the exact error responses are covered in Org context & X-Organization-ID.

​
Roles decide who can do what

Within an organization, your role decides what you are allowed to do. ModuleX keeps this deliberately simple.

Owner

Assigned to whoever creates the organization. Owners can do everything an admin can, plus owner-only actions such as removing members.

Admin

Full working access: build and run workflows, use the AI Composer and the Assistant, and manage credentials and knowledge. Invited teammates join as admins.
There is no member role. A member role existed in earlier versions of ModuleX and was retired on 2026-06-20. The live roles are owner and admin only. If you see “member” referenced anywhere, treat it as legacy. See Roles & permissions for which actions require which role.

​
Where your data goes

Most of what ModuleX does runs against services you choose. Being clear about that is part of keeping your data secure.

Bring your own keys

When you connect your own model or tool provider, that usage runs on your account, at your provider, under your provider’s terms. ModuleX adds no markup and stores the credential encrypted.

Managed usage

When you use ModuleX-managed models or knowledge storage, ModuleX provisions the provider for you and meters the usage in credits.
Either way, the credential that authorizes the work is encrypted, scoped to your organization, and used only to run your workflows.

​
Trust, compliance, and sub-processors

This page covers how the product is built to protect your data. For ModuleX’s data-handling posture, retention, certifications, and the third parties that may process data on its behalf, see the Trust pages.

Trust & compliance

How ModuleX handles, retains, and protects data.

Compliance

ModuleX’s compliance posture and certifications.

Sub-processors

Third parties that may process data on ModuleX’s behalf.
Specific compliance certifications and the full sub-processor list are published on the Trust pages above. This overview does not assert any certification; confirm the current status there before relying on it.

​
Read the details

Auth model: JWT vs API key

The two authentication paths, how ModuleX tells them apart, and the exact headers.

Data security & encryption

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

Org context & X-Organization-ID

How the organization header scopes every org-bound request.

Roles & permissions

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