Organizations

What is an organization?

An organization is the top-level tenant in Mipiti. Organizations own workspaces, which in turn hold threat models, systems, and all other data. Every user belongs to exactly one organization.

Organizations provide:

• Tenant isolation — each org's data is stored in a separate encrypted database
• Member management — admins control who belongs to the org and their roles
• Resource boundaries — workspace limits, member limits, and credit quotas are scoped per-org

Members

Inviting members

Admins can invite users to an organization by email:

1. Navigate to Settings > Organizations and select your org
2. Enter the user's email in the Invite by email field
3. Click Invite (or press Enter)

The user must already have a Mipiti account. Inviting adds them to the organization.

Roles

• Admin is the org-level management role. Admins manage members, org settings, billing, and credit quotas within their organization. This role is only available in organizations with org-level billing (Organization or Enterprise tier).
• User is the default role for all members. Users have full access to threat models within the org's workspaces.

Changing roles

Admins can change a member's role using the dropdown next to their name in the members list.

Removing members

Click Remove next to a member's name. The user's account is not deleted — they are simply removed from the organization.

Editing your organization

Navigate to Settings > Organizations, select your organization, then modify the Name or Description fields and click Save Changes.

Compliance posture targets

Two org-level fields capture the compliance posture every model under the org should be assessed against. Both are optional, both are org-admin-gated, and both flow through to LLM prompts and exported auditor reports — so setting them affects what the platform generates for every model in the org, not just decoration.

Set them under Settings > Organizations alongside the name/description. Leaving them unset is fine — the prompt and report sections render only when at least one is populated, so non-62443 / non-CSF orgs see no noise. Per-Component grades (target_sl, eal, fips_level), per-CO cal, and per-framework target_level live on their respective entities; see Compliance for the full grade-encoding model.

Resource limits

Each organization has configurable limits on workspaces and members.

Enforcement

• Workspace limit: When an org reaches its workspace limit, creating a new workspace returns an error. Personal workspaces are excluded from the count.
• Member limit: When an org reaches its member limit, inviting a new member returns an error.

Usage monitoring

The Limits & Usage section shows current usage alongside configured limits with color-coded progress bars:

• Blue — under 70% utilization
• Yellow — 70-89% utilization
• Red — 90%+ utilization

Admins can also query usage programmatically:

GET /api/organizations/{org_id}/usage

Returns:

{
  "workspace_count": 5,
  "member_count": 12,
  "max_workspaces": 10,
  "max_members": 0
}

Credit pool

Each organization has a shared credit pool. Members consume credits from the org pool instead of personal balances.

How it works

• Org admin manages the subscription — credits from the org plan go to the shared pool
• Members consume from the pool — every generation, refinement, or control generation deducts from the org balance

Per-member quotas

Org admins can set monthly and daily credit limits per member to control spend:

1. Navigate to Settings > Organizations and select your org
2. In the Credit Pool section, click Set Quota next to a member
3. Enter monthly and/or daily limits (0 = unlimited within the pool)
4. Click Save

When a member exceeds their quota, generation is blocked until the period resets. Quotas reset automatically — monthly on the 1st, daily at midnight.

Viewing usage

The Credit Pool section shows:

• Organization balance — total credits remaining in the pool
• Per-member table — each member's monthly/daily usage and limits

Members see their own quota usage in Settings > Account > Billing with progress bars for monthly and daily consumption.

API endpoints

Running control generations

Controls are generated in the background after a model is built. Organization admins see the generations currently running, waiting, or paused in the organization's team workspaces under Organizations → Running control generations, and can pause or resume any of them. Pausing stops a run at its next step, keeps what it has done, and bills nothing more until it is resumed; resuming continues where it stopped. Generations in members' personal workspaces are not listed — those belong to the member alone.

Integrations (Jira / Confluence)

Jira and Confluence integrations are configured at the organization level. The connection belongs to the org, not to individual users.

How it works

1. Org admin configures the integration — selects the target Jira project and Confluence space from Settings > Integrations
2. Members connect their own Atlassian accounts — each member who wants to export authenticates via OAuth from Settings > Integrations > Jira
3. Members export — any connected member can use "Export to Jira" on their models

The org admin controls where data goes. Atlassian controls who can authenticate. Mipiti does not maintain a separate per-user whitelist — if a member can authenticate with Atlassian and has access to the configured project, they can export.

Authorization

Personal workspaces

Jira and Confluence integration is not available for personal workspaces (users not in an organization). If you need these integrations, join an organization where an admin has configured them.

Security

Org admins have access to security operations in Settings > Organizations > Security.

Database key rotation

Rotates the SQLCipher AES encryption key for the organization's database. This re-encrypts the database file with a new key without any data loss or downtime.

When to use:

• Periodic key rotation per your security policy
• After revoking access from a former team member who may have had infrastructure access
• As part of incident response

Click Rotate Database Key and confirm. The operation completes in seconds.

Jira token refresh

Forces a refresh of all Jira OAuth tokens for every connected member in the organization. Useful when tokens are suspected compromised or after Jira permission changes.

Click Refresh Jira Tokens and confirm. Results show how many connections were refreshed and how many failed (e.g., if a member's Jira access was revoked).

This endpoint is rate-limited to once per 5 minutes per organization to protect against Atlassian API rate limit exhaustion and token invalidation churn.

API endpoints

Platform encryption (superadmin)

Superadmins have access to additional platform-level encryption operations for rotating per-org Fernet DEKs (Jira, MFA, or all). These are KMS-wrapped key rotations that re-encrypt all affected secrets across the platform.

Single sign-on (SSO) and SCIM

SSO and SCIM directory provisioning are included in the Enterprise plan, and can be enabled for an organization on another plan by agreement. Once they're enabled for your organization, an org admin configures both self-serve from Organization settings → Enterprise. If they are later disabled, SSO sign-in and SCIM provisioning stop immediately.

Platform approval of your email domains. Mipiti can require that the platform approve each email domain before your organization uses it for single sign-on or SCIM. Where approval applies, the domain list in Organization settings → Enterprise shows each domain as Approved for single sign-on or Awaiting platform approval, and until a domain is approved: it can't be added, verified or saved in the SSO settings, sign-in through your identity provider is refused for addresses on it (members sign in with their password instead, or use password reset if they don't have one), the sign-in page doesn't offer SSO for it, SSO enforcement doesn't apply to it, and SCIM doesn't create or reactivate accounts on it. Contact Mipiti support to have a domain approved. Turning SSO or enforcement off, removing a domain, revoking a SCIM token and unmapping a group always work, whatever the approval state.

Single sign-on (OIDC / SAML)

Configure your identity provider (Okta, Microsoft Entra, Google Workspace, Auth0, Ping, JumpCloud, or any OIDC/SAML IdP):

• Register Mipiti in your identity provider — the SSO settings show the values your IdP app needs for the protocol you pick, each with a copy button. For OIDC, the sign-in redirect URI. For SAML, the single sign-on URL (ACS URL) and the Audience URI (SP entity ID). If the settings say a protocol isn't available on this deployment yet, SSO can't be enabled with that protocol; contact Mipiti support.

• Your organization's sign-in link — the SSO settings show a link of the form <your Mipiti address>/sso/<your-org-slug>, with a copy button. Opening it starts single sign-on for your organization immediately: no email to type, no organization to choose. Members can bookmark it, you can put it on an internal page, and it is the address to point your identity provider's Mipiti application tile at, so that one click from your IdP's dashboard signs a member in. The link is safe to publish — it begins a sign-in and grants nothing on its own; everything that decides who gets in still happens at your identity provider and in the checks Mipiti runs on what comes back. Pointing the tile at this link is the supported way to get one-click sign-in, because Mipiti does not accept identity-provider-initiated (unsolicited) sign-in: it only completes a sign-in that it started itself and can match to its own outstanding request, which is what lets it reject a replayed or misdirected response.

• Verify your email domains first — add each email domain and prove your organization controls it by publishing the DNS TXT record shown (mipiti-domain-verification=<token> on the domain apex), then click Verify. Only DNS-verified domains provision accounts, adopt existing accounts, and scope enforcement; an unverified domain has no effect. A domain can be verified by only one organization, and SSO can't be enabled until at least one domain is verified. Verification is hardened: lookups run over DNS-over-HTTPS across two independent resolvers that must agree, you can optionally require DNSSEC (strict mode rejects unsigned zones), the domain must have a live mail (MX) record (parked/expired domains are rejected), and a verification lasts 90 days and is re-checked periodically in the background — so a domain you no longer control loses access quickly. If your organization's last verified domain is removed or stops validating, SSO enforcement is turned off automatically so no one is locked out.

• Just-in-time provisioning — a member's first SSO sign-in creates their account and joins it to your organization automatically, matched by a DNS-verified email domain. No separate signup. If a user already has an account (password or GitHub/Google) under that email, SSO links to it — no duplicate. Linking an account that already exists is the one step that needs proof the address belongs to the person signing in: either your identity provider says it has verified the address, or Mipiti already holds its own confirmation of it (from signing up with a code, a password reset, or a provider that vouched for the address). If neither applies, that sign-in is refused and the member can confirm the address themselves — Mipiti emails them a code from the Confirm your email address link on the failed sign-in page, and their next SSO sign-in links normally. Confirming an address signs nobody in and creates no account.

• Role from IdP groups — optionally map an IdP group to the mipiti admin role; everyone else gets the default role.

• Require SSO (enforcement) — optionally require SSO for the org. Members whose email is on one of your SSO domains must sign in via SSO (password and social-OAuth are refused). Members with a different email domain (who can't use your IdP) are not locked out: they keep their account and personal workspace/models, but lose organization access while SSO is enforced — their membership is preserved, so turning enforcement off restores it, and they can rejoin org access by signing in via SSO with an org-domain email. Superadmins are never affected. To avoid lockouts, enforcement can only be enabled after one successful SSO sign-in has proven the configuration works; enabling it revokes affected members' active sessions so it takes effect immediately.

• Turning enforcement on ends the credentials of members who must now use single sign-on — their sessions, their API keys and their connected coding agents — so the policy applies to their agents and not only to the next time they sign in. They re-authorize through your identity provider. Members already signing in through it are unaffected.

• Turning SSO off — Disable SSO turns single sign-on (and enforcement) off, and Turn off enforcement lifts enforcement while leaving SSO on. Each does only that one thing, so it works even when other settings can't be saved.

• Security — the OIDC client secret is encrypted at rest and never shown again; OIDC ID tokens are validated against your IdP's JWKS; SAML assertions are signature-verified against your IdP certificate. SSO composes with org-enforced WebAuthn — a configured second factor still applies.

What your identity provider must send

• OIDC — Mipiti requests the scopes openid email profile, plus groups when a groups claim is configured. The ID token must carry email; sign-in is refused without it. email_verified: true is not required to create a new account, and is one of the two ways to link an account that already exists (see just-in-time provisioning above). Later sign-ins match the identity provider's subject (sub), so a changed email keeps the same account.
• SAML — the signed assertion must carry an emailAddress-format NameID (an email attribute is accepted as a fallback), an audience restriction matching the Audience URI, conditions with an expiry, and a recipient matching the ACS URL. Sign-in must start from Mipiti; identity-provider-initiated sign-in is not supported. A persistent NameID is recommended so a changed email keeps the same account.

Provider notes (behavior varies by configuration, so confirm with Test sign-in):

• Okta — users need a verified email address (for example, activated through the activation email) for Okta to send email_verified: true. A custom authorization server must still include the email claim in the ID token, and email_verified if you want existing Mipiti accounts linked without a separate confirmation.
• Microsoft Entra ID — ID tokens often do not include email_verified. New members still sign in and get an account, and so does a member whose account your directory created over SCIM. A member who already had a Mipiti account under that address confirms it once (or you configure the claim, or use SAML) and is linked from then on.
• Google Workspace — Workspace account emails are verified by default. Leave the groups claim blank; Google rejects a groups scope.

Troubleshooting sign-in

• Test sign-in — in the SSO settings, Test sign-in signs you in at your identity provider with the saved settings and checks what comes back: the token or assertion signature and audience, the email and whether it is verified, which proof a first sign-in would use to link an existing account, whether the email's domain is verified and approved for your organization, and what the first sign-in would do (create an account, link an existing account by its verified email, sign in an account already linked, or refuse). It works while SSO is off, signs nobody in to Mipiti and changes no account. Save your changes first; the test uses the saved settings. The result is visible only to you for 10 minutes.
• Recent sign-in problems — the SSO settings list refused SSO sign-ins from the last 30 days, newest first, with the reason and how to fix it, the protocol, a masked email (for example j***@acme.com) and the names of the claims the identity provider sent. Claim values, tokens, assertions and full email addresses are never stored. Repeated identical refusals are shown once with a count, and failed test sign-ins are marked Test. Members still see a short, generic message when sign-in is refused.

SCIM 2.0 provisioning

Connect your IdP's directory to provision and deprovision users automatically:

• Mint a per-org SCIM token (shown once) and give it, with the SCIM base URL, to your IdP.
• Users are created, updated, and deprovisioned automatically as directory membership changes. Deprovisioning disables the account and ends every credential in that person's name — sessions, API keys and connected coding agents — so their agents lose access at the same moment they do.
• SCIM and SSO together — an account your directory creates counts as your organization vouching for that email address, as long as the address is on one of your verified, approved domains. That member's first SSO sign-in links to the account it created even if your identity provider sends no email_verified claim, so no one has to confirm their address by email. An address outside those domains is still provisioned, and linking it works as described under just-in-time provisioning above.
• Group → workspace mapping — map an IdP group to a workspace; membership changes on that group automatically grant/revoke workspace access. This is how you scope users and teams to workspaces centrally from your directory.

Coding-agent access (managed MCP config, service tokens) — Organization

Available on the Organization plan and above:

• Managed MCP config — download a ready-to-deploy Mipiti MCP configuration for Claude Code, Cursor, and Codex and push it to developer machines via MDM (Jamf/Intune). It uses OAuth, not static API keys: each developer signs in once (via your SSO when enabled), and their token is scoped to their workspace server-side, so usage is attributed per developer.
• Device authorization — headless/input-constrained clients obtain a token by having a person approve a short code, binding the approver's workspace.
• Service tokens — an admin mints a long-lived, workspace-scoped token for non-interactive CI, owned by a service account so usage bills to the org rather than an individual.

Organizations vs. workspaces

Organizations and workspaces serve different purposes:

A typical setup: one organization per company, with workspaces for different teams or projects within that company.