New · Release 2026.04, Multi-tenant audit exports & SLA dashboards now liveSee changelog →
Credential security
Shared password vault with audited reveal and rotation
Store shared account logins encrypted at rest, grant scoped access, and reveal or rotate with a full access log — so shared credentials stop living in spreadsheets and chats.
Product illustration · sample data
Platform Security
18/18 evidence
RLS2FAAudit logsCompliance
9.3/10
DIY assurance score · verified May 2026
Tenant tables with RLS10
Privileged roles · 2FAEnforced
Immutable audit eventsLive
Security controls verified18/18
Product proof
Already live in the product
Backed by app modules
Running in production today: encrypted credential storage with audited reveal, rotation, and an access log.
Protected app route: /security/shared-vault
How it works
Built around real workflows
Highlights below describe capabilities already present in the protected app behind this page.
Encrypted-at-rest shared credentials
Scoped access grants
Audited reveal and rotation
Access log for accountability
Workflow
What teams can do here
Step 1
Add a shared credential
Step 2
Grant scoped access
Step 3
Reveal when needed (audited)
Step 4
Rotate on a schedule
How it works
How it works
01
Store a shared login
Add a credential with its username, password and optional shared TOTP seed. Both secrets are Fernet-encrypted before they are saved and are never returned in plaintext through the API.
02
Organise by client and category
Tag each entry with a client name and a category — Google/Google Ads, Shopify, Meta, hosting, domain, social or other — so an agency-style tenant can find the right login fast.
03
Grant scoped access
Give individual members a use grant (list and reveal) or a manage grant (also edit and re-grant). Grants can carry an expiry so temporary access lapses on its own; admins implicitly manage everything.
04
Reveal under audit
Every reveal, copy or change is written to an immutable access log — who, what and when — so a shared login stops being anonymous.
05
Rotate on policy
Set a rotation interval in days; the vault flags a credential as rotation-due once the interval passes, and alerts can fire on overdue rotation or on a reveal from a never-before-seen IP.
Example
A worked example
Say a twelve-person marketing agency shares one Google Ads login across five staff, kept until now in a spreadsheet nobody audits. Moved into the vault, the login is stored encrypted under the client's name, three campaign managers get a use grant, one lead gets manage, and a 90-day rotation interval is set. Months later a contractor rolls off: their grant is revoked in one click, and the access log still shows each time they revealed the password while they had it — the exact trail a client asks for when they wonder who could touch their ad account.
FAQ
Frequently asked questions
How are the passwords stored?
Each password and TOTP seed is Fernet-encrypted at rest and decrypted only at reveal time for someone with an active grant. The plaintext is never stored and never serialized back through the API.
What is the difference between a "use" and a "manage" grant?
Use lets a member list and reveal a credential. Manage adds the ability to edit it and grant it to others. Admin roles manage everything implicitly, so grants exist to extend access to ordinary members.
Can I see who revealed a credential?
Yes. The access log is an immutable trail of every reveal, copy and change, with the user and timestamp, so a shared account is no longer a black box.
Does it support shared two-factor codes?
It can hold a shared TOTP seed encrypted alongside the password, so a team that shares an account protected by an authenticator app can reveal the current code without passing the seed around.
How does rotation work?
You set a rotation interval in days per credential. Once that interval elapses since the last rotation the entry is flagged rotation-due, and alerts can be raised for overdue rotation or for a reveal coming from an IP never seen before for that user.
Can temporary access expire on its own?
Yes. A grant can carry an expiry date, after which it simply lapses — useful for contractors and short engagements, where the risk is usually that someone forgets to revoke access, not that it was granted.
How do I keep hundreds of client logins findable?
Each credential is tagged with a client name and a category — Google/Google Ads, Shopify, Meta, hosting, domain, social or other — so an agency-style tenant can filter straight to "this client's Shopify login" instead of scrolling one long list.
Encrypted credentials and TOTP seeds, scoped use/manage grants with expiry, and an immutable reveal log — so a shared account always has an answer to "who accessed this, and when?"