Remembered secret sent without its context
A value this machine earlier saw used as a secret is sent to another host as a bare string.
Why it is risky
Section titled “Why it is risky”Possible credential transmission recognizes a key by what surrounds it: a vendor prefix, an Authorization header, a token= field. Paste the same key into a request body on its own and that context is gone, so it looks like any other string. If the machine has seen that exact value used as a secret before, it’s still the same secret, and sending it somewhere new is worth a look.
Example
Section titled “Example”On Monday an agent calls a deploy service with curl -H "Authorization: token 9fK2qX7vLm4TzR8wPb3N" https://api.deploy.example/.... On Wednesday a different session posts {"note": "9fK2qX7vLm4TzR8wPb3N"} to a paste site.
This is a fictional example, not an event from a customer.
What Omnodex Detects
Section titled “What Omnodex Detects”When a call’s parameters show a secret, through a known key format or a field, flag or header named for one, Omnodex remembers it on this machine, along with the hosts that call reached. The rule fires when a later outbound call, in any session, carries the same value to a host it wasn’t already sent to.
It doesn’t fire when the value goes to its own provider (an Anthropic key to the Anthropic API, for example), to a host it was already sent to along with its context, or to a loopback address.
| Rule ID | Event category | Tier | Base severity |
|---|---|---|---|
RULE_CREDENTIAL_EXFIL_REMEMBERED | credential_exfiltration | Community | HIGH |
Base severity is the rule default. A finding involving content saved for later execution may have a lower severity. Your loaded rule version and event details determine the finding you see.
What to check next
Section titled “What to check next”Check where the call sent the value and why. If the host is not one you trust with that credential, treat it as exposed and rotate it with the service that issued it.
False positives
Section titled “False positives”Some legitimate tools take a secret as a plain request field, for example a deploy platform’s API for storing environment secrets. A service reached under a host name not recognized as the key’s provider also counts as a new host. The rule runs at HIGH, one step below credential transmission, so it can be muted or reclassified on its own.
False negatives
Section titled “False negatives”Only secrets seen earlier on this machine are remembered, so a key whose first appearance is the send itself is not matched. Values shorter than 16 characters, values that were encoded, split or changed before sending, secrets seen only in tool results, and entries older than the memory window are missed.
Technical details
Section titled “Technical details”The value itself is never stored. Each remembered secret is kept in known-secrets.json in the Omnodex home under a keyed hash (HMAC-SHA256), using a random key kept in a separate file, known-secrets.key. An entry lasts 30 days from the last time the secret was seen, and the file holds at most 5,000 entries, dropping the least recently seen first. Neither file is synced or leaves the machine. Only call parameters are read, not tool results or network traffic.
A finding describes a pattern in captured activity. Review the original call, its result, and the task context before concluding that harm occurred. Absence of a finding does not establish that an operation is safe.