Reveal Permissions and Roles

Not everyone who can see that an account exists should be able to see its password. StretchVault draws a firm line between viewing metadata and revealing a secret, and this article explains exactly who can reveal and how to manage it.

Two levels of access

StretchVault separates two things people often conflate:

• Viewing metadata — seeing an item's title, username, URL, tags, notes, strength, and exposure status. This is what appears in every list and dashboard.
• Revealing the secret — decrypting and displaying the actual password, key, or card number. This is a distinct, logged action.

Many workflows only need metadata ("which account is this, and is it healthy?"). Reveal is reserved for the moment someone actually needs to use the credential.

Who can reveal

Reveal permission comes from one of two sources:

1. Role. Owners and admins of the organization can reveal items in the vaults they administer. These are the people responsible for the workspace's credentials.
2. Grant. Any other teammate can reveal a specific item only if they hold an active grant on it with reveal (or edit) scope. A view-scope grant explicitly does not allow reveal.

If someone without permission attempts a reveal, StretchVault refuses it with a clear "you do not have permission to reveal this secret" message. There's no partial reveal and no workaround — the correct path is to be granted access.

Giving someone reveal access

To let a specific teammate reveal a specific item:

1. As an owner, admin, or the item's manager, open the item.
2. Choose Share.
3. Enter the person's email.
4. Set scope to reveal (or edit if they also need to change it).
5. Optionally set an expiry.
6. Confirm. They can now reveal that one item.

To remove reveal access, revoke the grant from the Sharing tab. See Sharing Secrets and Managing Access Grants for the full sharing workflow.

A realistic example

Meridian Studio's junior coordinator, Priya, helps set up client tools but shouldn't have blanket access to every password. The owner keeps Priya as a standard member (no admin role), then grants her reveal access to just the three onboarding-related items she needs this week, each with a two-week expiry. Priya can reveal exactly those three secrets and nothing else. When onboarding finishes, the grants expire automatically — and the access log shows precisely which of the three she used.

Designing your access model

• Reserve owner/admin roles for the small group genuinely responsible for credential governance. Admin implies reveal across administered vaults, so keep the circle tight.
• Give everyone else access per item, at reveal scope, matching real need. This is the principle of least privilege in practice.
• Use expiry for anyone temporary — contractors, freelancers, short projects.
• Separate sensitive credentials into their own vault so that admin over one area doesn't imply reveal over everything.

Tips

• Prefer grants over promotions: giving someone reveal on three items is far safer than making them an admin so they can "just get in."
• Audit reveal access periodically by filtering the Sharing tab per vault — it answers "who can currently see these secrets?"
• Combine reveal control with 2FA on the underlying accounts so a revealed password alone isn't enough to sign in.

Troubleshooting

A teammate can see the item but not reveal it. Their grant is view scope. Re-share at reveal scope, or confirm they hold a reveal/edit grant.

An admin can't reveal an item. Confirm they administer that item's vault and that encryption is configured (Health tab). Encryption problems block reveal for everyone.

Access I granted stopped working. The grant may have hit its expiry or been revoked. Check the Sharing tab and re-grant if appropriate.

FAQ

Does being able to reveal let someone change the secret? No — reveal scope shows the secret; edit scope is required to change it.

Are reveals by admins logged too? Yes. Every reveal, regardless of who performs it, is recorded in the access log.