AWS secret access key: format and detection

What it is

The secret access key is the private half of an AWS key pair and is what signs requests. It is masked by default in the Credentials pack.

In Maskflare this is the detector aws_secret_access_key, labelled "AWS secret access key", category password or access key, in the Credentials pack.

Format

• 40 characters from A to Z, a to z, 0 to 9, slash and plus.
• Context one: a name that contains aws and later secret, an assignment (=, : or =>), optional quotes.
• Context two: an access key ID (any of the five prefixes) followed within about 63 characters by a non-key character and then the 40-character value.

How Maskflare recognises it

Context, 40-character body and an entropy floor of 4.0.

A value made only of hexadecimal characters is on the allow list, so a 40-character git commit hash or SHA-1 is not masked.

Why this page shows no sample key

A realistic sample key would look like a live credential to secret scanners and to anyone skimming the page, and an obviously fake one would not pass this detector's length and entropy rules. The format above is enough to recognise the key: the prefix, the length and the character set.

Regex and validation caveats

• A secret key with no label and no access key ID nearby is not matched. Forty random-looking characters are too common without context.
• The second context lets a secret be found when the variable names are unusual, as long as the ID sits just before it.
• The key may contain a slash or plus, which some tools treat as a separator, so a regex written for plain alphanumerics will cut it short.

How to detect it in LLM traffic

Credentials files (~/.aws/credentials), Terraform provider blocks and Docker environment lists all place the ID and the secret within a few lines of each other, which suits the second context.

Maskflare reads the whole request body, including the system prompt, earlier messages and tool arguments, and replaces each match with a token such as mf_mask_d7e0 before the request goes out. Coding agents are covered through hooks that mask tool inputs and results, so a key printed by a shell command does not travel onward in the next prompt. On ChatGPT, browser protection blocks prompts that contain API keys, tokens or private keys outright.

If you build the detection yourself

1. Scan the raw text rather than parsed fields: keys sit in code, JSON strings, headers, shell output and pasted logs, often with no label at all.
2. Match the prefix and the exact length for the AWS secret access key. Where the key has no fixed prefix, require the provider's name and an assignment next to the value instead of matching any long string.
3. Compute the Shannon entropy of the candidate and reject low values, and keep an allow list of placeholders (${KEY}, repeated characters, the alphabet run), because documentation and templates are full of them.
4. Mask the value before the text is sent anywhere. If the key was already sent, treat it as exposed and rotate it; masking later does not recall it.

How Maskflare handles it

• Protect now, Finance - Protect now, Healthcare, Developer and Monitor first: mask (a reversible token).

The available actions are mask (reversible token), redact, partial, hash, format-preserving encryption, generalize, alert and block. Masked values are kept encrypted for 30 days so that answers can be restored, then they expire; prompts and responses are not logged. The full list of detectors is in the detector reference.

Compliance profiles that include it

All 6 compliance profiles include the Credentials pack, and applying them turns this detector on: HIPAA Safe Harbor, GDPR - EU/EEA, UK GDPR, PCI DSS, US personal data and Switzerland - nDSG health data. A profile is a floor: it never turns anything off or weakens a rule that is already stricter.