# Mighty Platform

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

Source URL: https://trymighty.ai/docs/platform

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:

```bash
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.

| Permission | Scope | Use when |
| --- | --- | --- |
| Full Access | `scan` | The service scans text, images, and documents. |
| Text Only | `scan:text` | The service only scans text, OCR output, model output, or agent output. |
| Images & Documents | `scan:multimodal` | The 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.

| Mode | What Mighty stores | Use when |
| --- | --- | --- |
| None | No scanned content is logged. | Production default and privacy-first workflows. |
| Hashed | A SHA-256 hash of scanned content. | You need to debug duplicates, retries, or correlation without storing raw content. |
| Full | Full 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.

## AI-Agent Prompt

### Configure Mighty platform access

```text
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.
```