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

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 — Enterprise

SSO and SCIM directory provisioning are available on the Enterprise plan. Once your organization is on Enterprise, an org admin configures both self-serve from Organization settings → Enterprise.

Single sign-on (OIDC / SAML)

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

• 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.
• 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.
• 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.

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 (disabled, sessions revoked) automatically as directory membership changes.
• 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.