---
title: "Admin Device Keys"
method: GET
path: "/admin/device-keys"
---

# Admin Device Keys

`GET /admin/device-keys`

## Request

- Base URL: `https://api.local-mcp.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api.local-mcp.com/admin/device-keys`
- Auth: none declared. Required headers: `x-admin-key`

Where the device-key rollout is (lmcp-api#69): per platform, machines seen in the window
that have a live key, that have proved they can sign (`signs_approvals_at`), and that have no
key at all (section 8's count — the ones still on the OAuth path). Plus, over the window, how
many different-key enrolments were refused (`key_mismatch`) and how many heartbeats claimed
another machine's token (`token_machine_mismatch`). Bounded: tunnel_tokens/keys + an indexed
events window. lmcp-api#350: a machine id can hold several live keys (one per operating-system
user); a machine still counts once, `live_keys` is how many keys they hold together and
`several_keys` how many machines hold more than one.

`key_mismatch_refused` is the signal to watch (#91 review obs 2): once a bearer proof never
replaces a live key, a token holder can be the FIRST to enrol a key on a still-keyless machine
(section 8-A), and the owner's later enrol is then `409 key_mismatch` until an admin reset —
where before the bearer enrol silently healed it. A rising count here is where that shows.

## Query parameters

- `hours` integer

## Headers

- `x-admin-key` string, required

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/local-mcp/apis/lmcp-api.md) · [All operations](https://skmtc.dev/local-mcp/apis/lmcp-api/llms.txt) · [OpenAPI document](https://skmtc.dev/local-mcp/apis/lmcp-api/revisions/f1f1c502623a?raw)