Tokens and keys

MopokeHQ has three kinds of credential. Each is shown once, when you make it; MopokeHQ keeps only a hash. Making and revoking any of them is recorded in the evidence log.

	CI token	Runtime check-in token	API key
For	Pipelines: scans, deploy reports, the fix runner	Production servers reporting which PHP or Node.js they run	Scripts, the public API and AI assistants over MCP
Where	Organisation menu, CI tokens	Organisation menu, CI tokens, kind Runtime check-in	Settings, Integrations, API keys
Who makes it	Owners and admins	Owners and admins	Any member, for themselves
Belongs to	The organisation	The organisation	One person in one organisation
Can do	Upload scans and SBOMs, report deploys, collect fix merge requests	Report runtimes, nothing else	What its owner can do, within its scope
Usually stored as	MOPOKE_TOKEN in CI	MOPOKE_TOKEN on the server	A secret in your script or assistant’s settings

CI tokens

A CI token lets a pipeline send results to your organisation. Make one per place you store it, so you can revoke one without touching the others: one per GitLab group, GitHub organisation or CI server is a good shape.

1. In MopokeHQ, open the organisation menu and choose CI tokens.
2. Kind CI pipeline. Name it after where it will live, for example acme/clients or github: acme.
3. Copy the token. It is shown once.
4. Store it in your CI as MOPOKE_TOKEN: a masked CI/CD variable in GitLab, a secret in GitHub, Gitea or Forgejo, a secured variable in Bitbucket. The setup guides say where: GitLab, GitHub, Gitea and Forgejo, any other CI.

The tokens page shows each token’s name, kind, when it was made and when it was last used. Revoke stops it at once; any pipeline still using it gets That token is unknown or was revoked. and its scan job warns (it does not fail the pipeline).

Caution

A CI token can upload scans and report deploys for any repository in your organisation, and the fix runner uses one to collect work. Keep it in masked or secret CI settings only, never in a repository.

Runtime check-in tokens

A server can report the PHP or Node.js it actually runs, so MopokeHQ knows about runtime security releases that affect it. Because that token sits on every production server, it is the narrowest kind: it can only report runtimes. A leaked one can raise false alarms, never hide a real problem or close anything.

Make one on the same page with kind Runtime check-in, named after the servers that use it (for example client-portal production). Have each server report at start-up and once a day, for example from cron:

curl -fsS -X POST https://app.mopokehq.com/api/v1/ingest/runtime \
  -H "Authorization: Bearer $MOPOKE_TOKEN" -H "Content-Type: application/json" \
  -d '{"source": {"path": "acme/client-portal"}, "environment": "production",
       "runtime": {"php": "8.3.12"}, "host_label": "web-1"}'

source.path is the repository’s path as your scans send it (add "subpath" for an app inside a monorepo). Send runtime.php, runtime.node or both. A check-in counts for seven days; a server that goes quiet is never read as fixed. Reporter packages for PHP and Node.js that do this for you are coming.

API keys

API keys are for the public API and the MCP server. Any member makes keys for themselves under Settings, Integrations, API keys; owners and admins also see and can revoke everyone’s.

• Acts as you. A key can never do more than its owner can, follows your role and teams, and stops working when you leave the organisation.
• Scope. Read covers every read. Read and write also lets the key act: acknowledge, record a triage decision, request upgrade merge requests. A read key that tries to act gets 403 insufficient_scope.
• Expiry. 30 days, 90 days (the default) or a year.
• The key starts mpk_api_. The list shows its last four characters and when it was last used.

Give an AI assistant a read key unless you want it to act on the fix list for you. Whatever it does with a read and write key is recorded under your name.

If a token leaks

1. Revoke it on its page. It stops working at once.
2. Make a new one and put it where the old one was.
3. For a CI token, check the evidence log and the Overview’s recent activity for uploads or deploy reports you don’t recognise.

If a token was committed to a repository, MopokeHQ’s own secrets scanner will usually find it first: see Secret rotation.