# What is metadata exposure in an encrypted service?

> Metadata exposure is what an encrypted service can still see: names, people, times, sizes and access patterns. Why it matters, and what a Crunu server sees.

URL: https://crunu.com/learn/metadata-exposure
Language: en
Updated: 2026-10-30

Metadata exposure is the information a service can read about your data even when the data itself is encrypted: what things are called, who has access, when they change, how big they are and who fetched them from where.

## Why it exists

A service has to organize what it stores. To show a list of projects, enforce access, keep an audit log or send an alert, it needs names, identities and times it can read. Encrypting all of that would leave the service unable to do its job. So every encrypted service makes a choice about what stays readable, and the honest ones document it.

AWS Secrets Manager is an example of documenting it clearly: it "encrypts the secret value, but it does not encrypt" the secret's name and description, its rotation settings, the ARN of its KMS key or its tags ([AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html)).

## What metadata can reveal

- **Names.** A project called `acquisition-target-2027` or a secret described as "prod DB root" says more than the value would.
- **Relationships.** Who has access to what maps your team and your systems.
- **Activity.** When values change, how often, and right before what event.
- **Location.** The addresses requests come from.
- **Size.** Whether a record holds a short key or a large certificate.

None of this lets someone use your credentials. It can still matter: for privacy, for competitive information, for planning an attack on the people rather than the encryption.

## Common mistakes

- **Secret names that are secrets.** Don't encode a client's name, a customer ID or a password hint into a name or description.
- **Taking "the server can't read your data" to mean "the server knows nothing".** Labels such as "zero-knowledge" often overstate this; see [what that label means for a vault](https://crunu.com/learn/zero-knowledge-architecture).
- **Forgetting backups.** Metadata in backups follows the backups wherever they are kept.

## What a Crunu server sees

Crunu's server stores only ciphertext of values, and it can't decrypt any of them. It does see metadata, by design, and the documentation lists it:

- the names of organizations, projects, environments, machines and access profiles;
- people's email addresses and names, memberships and roles;
- the audit log: sign-ins, devices, invitations, role changes, versions, rotations, machines, tokens, share links, denials and network rule changes;
- the sizes and times of versions, with contents padded to a multiple of 4,096 bytes to blur sizes;
- which versions of which environment were delivered to whom, when, how often and from which address, the record behind the exposure report;
- network rules, address lists and the address of each request.

Variable names and file paths are inside the ciphertext, not in this list. Environment and project names are signed inside access lists, so the server can't change them unnoticed, but it can read them. **Don't name a project or environment so that the name itself is a secret.** The same holds for a server you host: its operator, and anyone with a database backup, sees this metadata. Details: [what the server sees](https://crunu.com/docs/security/what-the-server-sees); comparison across vendors: [who can decrypt your secrets?](https://crunu.com/guides/who-can-decrypt-your-secrets).

## Sources

- [AWS Secrets Manager: Secret encryption and decryption](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html), checked October 30, 2026.