Integrations

Mipiti integrates with external tools to fit into your existing workflow. Configure integrations on the Settings page.

Jira

Export your threat model to Jira for tracking and implementation:

• Implementation Controls are pushed as Jira issues under the source issue that triggered the model (or a container issue for web-generated models)
• The issue type for exported controls is configurable (Story, Task, Sub-task, etc.)
• Status syncs back from Jira through the organization's own webhook endpoint, signed with its own secret; each model lists the status changes it received and what became of each
• When you soft-delete an asset or attacker, any controls whose work targeted the removed pair become orphaned. Their Jira tickets are automatically transitioned to Done on the next export and stamped as Mipiti-closed. If you later restore the asset/attacker (or remap the control to a live CO), the same ticket is reopened — ticket history and any work logged against it are preserved, not duplicated under a new key. Controls that were already IMPLEMENTED or VERIFIED when they got resurrected keep their Done state (no misleading "regressed" signal).

To get started:

1. Ask your org admin to configure Jira integration (select a project in Settings > Integrations, and create the organization's Jira webhook in Settings > Organizations — see Organizations > Integrations)
2. Connect your own Atlassian account from Settings > Integrations > Jira
3. Use the "Export to Jira" button on any model

Note: Jira integration is an organization feature. It is not available for personal workspaces (users not in an organization). If you need Jira integration, join an organization where an admin has configured it.

MCP (Model Context Protocol)

Connect AI coding agents (Claude Code, Claude Desktop, Cursor) to Mipiti for programmatic threat modeling as part of your development workflow.

Authentication

Two ways to authenticate MCP connections:

• OAuth (recommended) — MCP clients with OAuth support automatically prompt you to log in via your browser. No API key needed — just point the client at the URL and approve access when prompted. Tokens refresh automatically until the authorization reaches its lifetime (see Connected MCP clients), after which the client prompts you to log in again.
• API key — For clients without OAuth support, or headless/CI environments, create an API key in Settings and pass it via the X-API-Key header.

Connection options

• Hosted — connect directly to https://api.mipiti.io/mcp. No installation needed.
• Standalone — install the mipiti-mcp Python package locally for stdio-based connections.

The Settings page has configuration snippets for both options.

MCP Tools Reference

Pagination and Filtering

Retrieval tools return counts and summaries only by default to stay within AI context limits. For example, get_controls returns total/implemented/not_implemented counts without listing individual controls, and assess_model returns only the summary counts.

To drill into details:

• offset / limit — page through results (e.g., offset=0, limit=20 for the first 20 items)
• status — filter by status (e.g., status="not_implemented" on get_controls, status="at_risk" on assess_model)
• control_id — get full details for a single control (e.g., control_id="CTRL-01" on get_controls)
• co_id — filter controls mapped to a specific control objective
• include_cos — include control objectives inline on get_threat_model (excluded by default)
• include_assessment_summary — inline per-model assurance counts on list_threat_models (mitigated / at_risk / unassessed + message). Lets an agent answer "which of my models are at risk?" in one call instead of looping assess_model per model.

Common Workflows

Generate and track implementation:

1. generate_threat_model — create a model from a feature description; the result carries the proposed control build and its estimate
2. start_control_build — once the model is reviewed, start that build naming the model_version and set_revision it shows; poll get_control_generation_status until it is terminal
3. get_controls with status="not_implemented" — see what needs implementing
4. refine_control — if a generated control is overly prescriptive, propose a refined description with justification. AI evaluates whether the mitigation group still satisfies all mapped COs
5. update_control_status — mark controls as implemented with notes
6. assess_model — check overall assurance posture

Evidence verification (prove controls are implemented):

1. get_controls with status="implemented" — find controls needing evidence
2. Analyze your codebase to identify implementing code artifacts
3. submit_assertions — create typed, machine-verifiable claims (e.g., function exists, test passes)
4. Run mipiti-verify in CI to independently verify assertions against the codebase (Tier 1 + Tier 2)
5. get_verification_report — check verification status and detect drift

See Evidence Verification for the full guide on assertion types, the mipiti-verify CLI, and CI integration.

Gap discovery (find missing implementations):

1. get_scan_prompt — get a structured guide for scanning against not-implemented controls
2. Scan the codebase following the prompt, noting checked locations and missing patterns
3. submit_findings — record gaps with evidence of what was checked
4. update_finding — transition findings through acknowledge → remediate → verify

See Negative Findings for the full lifecycle and remediation bridge.

Compliance gap remediation:

1. list_compliance_frameworks — see available frameworks
2. select_compliance_frameworks — link a framework to your model
3. get_compliance_report with status="uncovered" — find gaps
4. auto_remediate_compliance — propose and apply missing assets and attackers for uncovered requirements, and propose the control build their new objectives owe (LLM-driven, reports progress natively); controls are written when you start that build

Aggregate posture across all models:

1. list_threat_models with include_assessment_summary=True — one call returns every model's mitigated / at_risk / unassessed counts
2. Inspect results to pick models needing attention
3. Drill into specific models with assess_model(model_id, status="at_risk") for per-CO detail

Long-Running Operations

generate_threat_model, refine_threat_model, auto_remediate_compliance, auto_map_controls, and check_control_gaps run LLM pipelines that may take several minutes. They block until complete and report progress automatically — no polling needed.

A control build is different: it runs in the background once started, so start_control_build returns at once and get_control_generation_status reports its progress, with a hint naming the next action. regenerate_controls only proposes a build and returns at once.

REST API

All features available via MCP are also available as REST API endpoints, callable directly with an API key (X-API-Key header) or OAuth Bearer token. This is useful for custom integrations, CI pipelines, or external tools that don't use MCP. Constraint-flow guidance describing the preview-then-apply norm for platform-emitted structural findings ships in the MCP server's instruction block — see the connected MCP server's instructions for the agent-driving narrative.

Finding endpoints (gap discovery + structural-correctness remediation):

Risk-tier audit endpoints (per-CO factor history):

Assertion endpoints (evidence verification):

See the full API reference for all available endpoints.

Connected MCP clients

Settings > Integrations lists the coding agents currently authorized to act as you: the client, the workspace it reaches, when it was authorized, when it was last used and when the authorization expires. Revoke ends one immediately; that client can reconnect by authorizing again.

An MCP authorization has a lifetime. It ends after 30 days without use, and in every case 90 days after it was granted — at which point the client asks you to log in again, which re-checks your identity provider, your account, and any single sign-on policy your organization applies. Individual access tokens last an hour and refresh on their own within that lifetime.

Organization admins see the same list across their members under Settings > Organizations, and can revoke any of them.

If a renewal token is ever presented twice, Mipiti treats the authorization as compromised: it is invalidated for everyone holding it, the event is recorded in your organization's audit log, and the genuine client signs in again.

API Keys

Create API keys on the Settings page to authenticate MCP connections and direct API calls. Keys are shown once at creation and stored securely — they cannot be retrieved later.

Tip: If your MCP client supports OAuth (Claude Code, Claude Desktop, Cursor), you don't need an API key — just use the OAuth config from Settings and log in when prompted. API keys are still useful for headless/CI environments and direct REST API calls.

Key scopes

Choose the scope when creating a key. Verifier keys are intended for CI pipelines that submit evidence verification results — they carry restricted permissions scoped to verification operations.

Workspace scoping

Every API key is scoped to a workspace, selected when the key is created. When the key is used for authentication, the workspace resolves automatically — no X-Workspace-Id header is needed.

This means a CI pipeline using a workspace-scoped verifier key can call mipiti-verify run --all to verify every threat model in that workspace in a single invocation. To change the workspace scope, revoke the key and create a new one — this ensures CI pipelines never silently switch context.

Key lifetime

New keys expire after 90 days unless you pick a different lifetime when creating one. The key you are shown at creation says when it expires, and the key list shows the expiry alongside when each key was created and last used, so you can renew before a pipeline breaks.

Keys created before default expiry existed have no expiry, and are not expired retroactively — they keep working, and the list marks them Never expires so you can see the exposure and decide. Revoke and re-create such a key to put it on a lifetime.

When a key stops working

A key stops authenticating as soon as it is revoked, when it expires, after 90 days without use, and whenever the account that owns it is disabled, deactivated by your organization's directory, or has its password reset. Those account-level events end every credential the user holds at once — API keys and connected coding agents together — not only their browser sessions.

Confluence

Mipiti can sync threat models to Confluence pages automatically:

• Pages are created or updated on model save
• Content is rendered as structured XHTML
• The target Confluence space is configured by your org admin in Settings > Integrations

Note: Confluence integration is an organization feature. It is not available for personal workspaces.

Verification Badge

Add a dynamic badge to your README that shows your threat model's verification status. The badge updates automatically as controls are verified in CI.

Setup

1. Enable the badge on your threat model — go to the model detail page and toggle "Public Badge" on (or use PATCH /api/models/{model_id}/badge)
2. Add this to your README.md, replacing MODEL_ID with your threat model's ID:

[![Mipiti Verified](https://img.shields.io/endpoint?url=https://api.mipiti.io/api/badge/MODEL_ID)](https://mipiti.io/models/MODEL_ID)

Find your model ID on the model detail page URL: mipiti.io/models/{MODEL_ID}.

Badge states

Badge	Meaning
	All COs fulfilled and verified by CI
	All controls implemented, verification in progress
	Some controls implemented, gaps remain
	Threat model exists but no controls generated

Scope

The badge covers every control objective in the model. There is no framework-scoped badge, and a framework parameter is refused rather than ignored, so a whole-model reading is never returned in answer to a request for a framework attestation.

How it works

The badge endpoint (/api/badge/{model_id}) is unauthenticated — Shields.io fetches it publicly. It serves a stored reading rather than running an assessment per request, and returns a Shields.io endpoint JSON response. cacheSeconds is 300.

The stored reading is rewritten when the model is assessed and when the badge is enabled. The badge is therefore as current as the last assessment, not as current as the last fetch: a CI run that fails, or a code change that breaks a control, is reflected once the model is next assessed.

The badge reads unknown in grey whenever it cannot make a current claim — no reading has been stored, the model was deleted, or the reading was produced under a superseded version of the rule that decides posture. It reports unknown rather than falling back to a weaker claim.

Privacy: Badges are opt-in. The verification status (fulfilled/at-risk CO counts) is security-sensitive — it reveals where gaps are. Only enable badges for projects where you're comfortable showing this publicly (e.g., open-source projects). The endpoint returns identical "unknown" responses for non-existent and non-enabled models.