Getting Started

Your first threat model

1. Navigate to the Models page and click New

2. Describe the feature or system you want to threat model. For example:

   "A REST API that accepts file uploads from authenticated users, stores them in S3, and serves them via pre-signed URLs."

3. Press Enter and watch the agentic pipeline work through 5 steps:

   • Generate Assets
   • Refine Assets
   • Generate Attackers
   • Refine Attackers
   • Generate Matrix (trust boundaries, control objectives, assumptions)

4. Review the generated threat model in the expandable thought process view

Tips for good descriptions

• Be specific about data flows — what enters, exits, and moves through the system
• Mention authentication methods and user roles
• Include infrastructure details — cloud provider, databases, queues
• Name external systems the feature integrates with
• Don't worry about being exhaustive — you can always refine afterward

Understanding the conversation

Mipiti's conversation interface supports four types of interaction:

The intent is classified automatically. You don't need to use special commands — just ask naturally.

Single-entity refinements (e.g., "Add an attacker" or "Remove asset A3") are routed to fast targeted operations. Broader instructions use the full refinement pipeline.

You can also add, edit, and remove assets and attackers directly via UI buttons — see Working with Models for details.

The Dashboard

The Dashboard is the landing page after login. It shows a portfolio-level overview of your threat models:

Below the KPIs, model cards show each model's auto-generated name, three progressive maturity bars (Defined / Implemented / Verified — see Assurance), risk tier breakdown, source badge (Web, MCP, Jira), compliance next-steps, and integration status (Jira issue count, Confluence link). Hover over a model name and click the pencil icon to rename it.

The Activity Feed on the right tracks recent model lifecycle events — generation, refinement, export, deletion — from all sources.

Credits and Billing

Mipiti uses a credit-based billing model. Each LLM call consumes credits proportional to the tokens used. Cached responses consume zero credits.

Every tier includes a monthly credit allowance that resets on the 1st of each calendar month. Purchased credit packs stack on top and never expire.

• Credit balance is shown on the Settings > Billing page with a breakdown of monthly allowance remaining vs purchased credits
• A progress bar shows how much of your monthly allowance you've used
• When credits reach zero, generation and refinement are blocked (querying existing models still works)
• Buy credit packs on the Pricing page — purchased credits are permanent and stack on top of your monthly allowance
• Upgrade to Pro starts a 30-day free trial with access to compliance frameworks and gap analysis. Card required upfront; billing starts after the trial ends
• Manage Billing opens the Stripe Customer Portal for payment methods, invoices, and receipt history
• A usage table shows recent credit consumption with timestamps and amounts

Monthly allowances reset — they do not accumulate across months. Credits are consumed from the monthly allowance first, then from purchased credits.

Fair use limit

All plans are subject to a 2,000 AI requests per day fair use limit. An AI request is any operation that triggers LLM processing — generating, refining, querying, generating controls, running gap analysis, or compliance mapping. Cached responses do not count. If you reach the limit, requests return HTTP 429 and you can retry the next day (UTC).

Project Setup (End-to-End)

This guide walks through provisioning a new project with Mipiti — from developer environment to CI integration.

1. Sign in

Sign in at mipiti.io. All plans (Free, Pro, Organization, Enterprise) support the full setup below.

2. Create a workspace (optional)

Organization and Enterprise tier members can create dedicated workspaces for each project under their org. Free and Pro users use their default personal workspace — skip this step.

3. Create a developer-scoped API key

Go to Settings > API Keys and create a key with Developer scope. This key is used by your MCP client (Claude Code, Cursor, etc.) for threat modeling during development.

Organization/Enterprise users: select the target workspace from the dropdown. Free/Pro users: the key is automatically scoped to your personal workspace.

4. Configure the MCP server

Add the Mipiti MCP server to your AI coding tool.

Claude Code — run this CLI command:

claude mcp add --transport http Mipiti https://api.mipiti.io/mcp/

You'll be prompted to log in via your browser (OAuth). To use an API key instead, add the server manually in your MCP settings:

{
  "mcpServers": {
    "mipiti": {
      "url": "https://api.mipiti.io/mcp",
      "headers": { "X-API-Key": "mk_your_developer_key" }
    }
  }
}

Other MCP clients (Cursor, Claude Desktop) can use either the OAuth or API key JSON config above.

5. Install mipiti-verify locally

pip install mipiti-verify[all]

This provides local assertion verification (no API key needed) and the full CI verification pipeline.

6. Create a verifier-scoped API key for CI

Go to Settings > API Keys and create a key with Verifier scope. This key is used by your CI pipeline to submit verification results. The key is scoped to a workspace and can verify all models within that workspace. Verifier keys require workspace owner permissions — Free and Pro users are implicitly owners of their personal workspace.

Note: For Free and Pro users, the developer and workspace owner are the same person. CI verification provides automated evidence collection and demonstrates due diligence, but auditors may note the lack of segregation of duties. Organization and Enterprise tiers enable separation — a security lead owns the workspace and verifier key while developers submit assertions, satisfying independent verification requirements.

7. Create a verify environment with your API key

In your GitHub repository: Settings > Environments, create an environment named verify. Add a secret MIPITI_API_KEY with the verifier key value.

8. Add mipiti-verify to your CI pipeline

Add a verification step to your CI workflow using the Mipiti Verify GitHub Action:

# .github/workflows/verify.yml
name: Verify Threat Model
on:
  push:
    branches: [main]
  pull_request:

jobs:
  verify:
    runs-on: ubuntu-latest
    environment: verify
    permissions:
      contents: read
      id-token: write       # OIDC attestation — proves results came from CI
      attestations: write   # Sigstore content attestation
    steps:
      - uses: actions/checkout@v4
      - uses: Mipiti/mipiti-verify@a4abc180daa1d3035a06f454ce1ccb02794c6dd0 # v0.14.0
        id: verify
        with:
          api-key: ${{ secrets.MIPITI_API_KEY }}
          all: true
          tier2-provider: openai
          tier2-model: gpt-4o-mini
          tier2-api-key: ${{ secrets.OPENAI_API_KEY }}
      - name: Attest content hash
        if: steps.verify.outputs.content-hash != ''
        uses: actions/attest-build-provenance@a2bbfa25375fe432b6a289bc6b6cd05ecd0c4c32 # v4.1.0
        with:
          subject-digest: ${{ steps.verify.outputs.content-hash }}
          subject-name: mipiti-verification

The action runs both Tier 1 (deterministic) and Tier 2 (AI-assisted) verification. All assertions are re-verified on every run to catch regressions. Exit code is non-zero if any assertion fails. Use reverify: false to only check new assertions (e.g., to reduce Tier 2 API costs on PRs). Omitting tier2-provider runs Tier 1 only — controls won't reach "verified" status without Tier 2.

The attest-build-provenance step records the content hash in Sigstore's public transparency log, enabling auditors to independently verify the assertions shown in reports match what CI verified — without trusting the Mipiti platform. Verify with: gh attestation verify --digest <content_hash> --repo <your-repo>.

Development workflow

Once set up, the ongoing workflow is:

1. Generate threat model — happens naturally via the MCP server's built-in instructions when your AI agent enters plan mode
2. Submit assertions and evidence — during implementation, the agent submits typed assertions via MCP and verifies them locally before submitting
3. CI verifies assertions — on every push/PR, mipiti-verify independently checks assertions against the actual codebase and submits results

Referral Codes

Referral codes let you invite colleagues to the platform. When someone signs up using your code, you earn 25 bonus credits added to your balance.

Codes are earned through engagement — each month, the platform's most active users receive a referral code as a reward. You can have up to 3 unused codes at a time. Codes are single-use and expire after 90 days.

View your codes and share them from Settings > Account.