## TL;DR

Unattributed keys stall incident response: nobody knows what to rotate. Maintain a key inventory mapping key identifiers and prefixes to owning services, and consult it on every finding.

## Error

```text
agent failed to match the leaked key to the owning service: key error
```

## Steps

1. Collect the leaked key's identifier: prefix, fingerprint, or metadata. Expected: something to match on.
2. Look it up in the key inventory. Expected: the owning service, or the gap that it is missing.
3. If missing, trace usage: search configs, audit logs, and provider dashboards for where the key is used. Expected: the owner found manually.
4. Add the key to the inventory with its owner so the next finding is instant. Expected: the gap closed.
5. Require inventory registration for all new keys going forward. Expected: no future orphans.

## When to use

- Leaked keys with unknown owners.
- Building key inventories.

## When not to use

- The key format is unrecognized (identify the provider first).
- You already know the owner (rotate directly).

## Tool compatibility

- Key inventories; audit logs; provider dashboards.

## Variant phrasings

### unknown owner for leaked key

Build the inventory.

### cannot attribute leaked credential

Trace usage.

## Why it happens

Keys are created ad hoc across teams; without a registry, a leaked value is just a string.

## Edge cases

- Shared keys have multiple owners; rotate for all of them.
- Inventory must include third-party-held keys, not just internal ones.
- Stale inventory is worse than none; keep it current.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IVGGLmUGoXEahP7-bW6xjg