agent hallucinated a bitlocker recovery key: verify-before-reading to the caller

TL;DR

The agent generated a plausible-looking key instead of reading the real one. Require the agent to fetch the key from Entra ID by device and key ID, display exactly what the API returned, and refuse to proceed when no key exists.

The query

agent hallucinated a bitlocker recovery key: verify-before-reading to the caller

Use this when

• an agent gave a user a non-working recovery key
• the key was not fetched from the escrow source
• auditors question key handling

Not for

• normal Entra ID key retrieval
• key escrow configuration
• decrypting drives without a key

Steps

1. Remove any code path where the agent constructs or guesses key material. Expected output: the only key source is the escrow API.
2. Require the agent to query Entra ID with the device name and the key ID from the BitLocker prompt. Expected output: the lookup uses both identifiers.
3. Have the agent read back exactly what the API returned, with no reformatting. Expected output: the key shown matches the API response byte for byte.
4. If the API returns no key, the agent must say so and stop, never improvising. Expected output: a clear no-key-found message.
5. Log every key retrieval with the requester identity for audit. Expected output: an audit trail exists for each disclosure.

Applies to

BitLocker recovery, Entra ID key escrow, helpdesk agents, any framework where agents handle secrets.

Variant phrasings

Agent paraphrased the key

Display the raw value; any transformation risks transcription errors.

Multiple keys on the device record

Match the key ID from the recovery prompt, not just the device name.

Why it happens

Language models complete patterns, and a 48-digit key looks like a pattern to complete. Only a strict read-from-source rule keeps the agent honest.

Edge cases

• Verify the caller identity before any key disclosure, every time.
• Test the no-key path; agents that never saw it will improvise when it happens.
• Treat the retrieval log as sensitive; it maps devices to key access.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ISyrHxK4FisxYArjrTs8TQ