Browse docs

Mighty Platform

Understand API keys, permissions, content logging modes, billing status, and safe key handling in the Mighty dashboard.

The Mighty dashboard is where your team creates API keys, controls what each key can scan, and chooses how much content should appear in platform logs.

Use the platform to create server-side keys. Use the API docs to wire those keys into your product.

API Keys

Create API keys from the dashboard at /api-keys.

The key is shown once when it is created. Copy it immediately. After you leave that screen, Mighty only shows a short prefix so your team can identify the key later.

Use the key name to separate local development, staging, production, batch jobs, and high-risk workflows. Mighty does not require a different key type for each environment.

Keep every key on your server:

MIGHTY_API_KEY="YOUR_MIGHTY_API_KEY"

Do not ship API keys to browser code, mobile apps, customer-visible logs, or public repositories.

Permissions

Choose the narrowest permission that matches the integration.

PermissionScopeUse when
Full AccessscanThe service scans text, images, and documents.
Text Onlyscan:textThe service only scans text, OCR output, model output, or agent output.
Images & Documentsscan:multimodalThe service scans images, PDFs, documents, or visual evidence.

If a key shows legacy permissions, revoke it and create a new key when practical. New keys use the current permission model.

Content Logging

Content logging controls what Mighty stores for debugging and audit workflows. It is set when you create an API key.

ModeWhat Mighty storesUse when
NoneNo scanned content is logged.Production default and privacy-first workflows.
HashedA SHA-256 hash of scanned content.You need to debug duplicates, retries, or correlation without storing raw content.
FullFull scanned content.Local development debugging only. Avoid for production sensitive data.

Default value: none.

Hashed Versus Full Logging

Use hashed when you need a stable fingerprint but do not want raw content stored in logs. The hash can help answer questions like:

  • Did this exact content appear before?
  • Did a retry send the same payload?
  • Are two logs about the same submitted material?

A hash is not the original content. Mighty does not use the hash to recover scanned text or files.

Do not treat hashing as a universal privacy guarantee. If content is short, predictable, or easy to guess, someone with the same input could compute the same hash. For sensitive production workflows, use none unless you have a clear debugging need.

Use full only when you are debugging locally or in a controlled development environment. Full logging can store the material your users submitted, so it is usually the wrong choice for production.

Billing Status

The platform requires an active subscription state before creating API keys. If billing is not active, the dashboard blocks key creation and API usage can be blocked until the account is fixed.

If you are not a superadmin, use the dashboard action to notify a superadmin. Superadmins can open billing and resolve the account state.

Key Hygiene

  • Name keys by environment and service, such as production claim intake.
  • Use scan:text for services that never touch files or images.
  • Use scan:multimodal for file or image workers that do not need text-only services.
  • Revoke keys when a service is retired, a secret may have leaked, or a teammate leaves.
  • Rotate production keys on a schedule that matches your security policy.
Next step

Ready to scan real traffic?

Create an API key, keep it on your server, then wire Mighty into the workflow that handles untrusted material.

AI-Agent Prompt

AI-ready prompt
Configure Mighty platform access

Paste this into Cursor, Codex, Claude Code, or Windsurf.

Configure Mighty platform access for this product.

Requirements:
- Create separate API keys for local development, staging, and production.
- Keep MIGHTY_API_KEY on the server only.
- Pick the narrowest permission: scan, scan:text, or scan:multimodal.
- Use content logging mode none for production unless debugging requires hashed.
- Use hashed logging only when duplicate or retry correlation is needed.
- Do not use full logging for production sensitive data.
- Add a key rotation and revocation procedure.

Acceptance criteria:
- No API key appears in client-side code.
- Production keys use the minimum required scope.
- Logging mode is documented per environment.
- Revocation is tested by removing a key and confirming requests fail safely.