Unrecognized secret in parameters
A machine-generated value is used as a secret, key or token, but matches no known credential format.
Why it is risky
Section titled “Why it is risky”Plenty of services issue keys with no recognizable prefix. When an agent puts one in a command or a tool call, it can end up in logs, transcripts or another service, just like a key with a known format. Credential exposure only reports formats it knows, so this rule covers the rest at a lower severity.
Example
Section titled “Example”An agent runs a deploy script with --client-secret 9fK2qX7vLm4TzR8wPb3N for a service whose keys carry no prefix.
This is a fictional example, not an event from a customer.
What Omnodex Detects
Section titled “What Omnodex Detects”The rule looks for a value in a place named for a secret: a field or variable such as CLIENT_SECRET= or "signingKey":, a flag such as --client-secret, or an Authorization header with a scheme other than Bearer, such as token or Basic. The value must look generated, so a git hash, UUID, file path or ordinary word in such a field is not reported. A value the credential exposure rule already reports is not reported again.
| Rule ID | Event category | Tier | Base severity |
|---|---|---|---|
RULE_UNRECOGNIZED_SECRET | credential_exposure | Community | LOW |
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 whether the value is a live credential and where the call sent it. If it is real and the recipient should not have it, rotate it with the issuing service. Prefer environment variables or the tool’s own secret handling over passing keys in arguments.
False positives
Section titled “False positives”Generated values that are not secrets, such as build IDs or random test fixtures in a field named key, can match. The LOW severity reflects that this is a heuristic with no vendor format behind it, and the rule can be muted on its own.
False negatives
Section titled “False negatives”A secret in a field whose name gives no hint, a short value, an encoded or split value, or one passed in a way the call’s parameters do not show is not reported.
Technical details
Section titled “Technical details”The rule does not validate keys with any service. It reads the captured parameters of a call, not 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.