Share secrets externally only via 1Password Secure Share, with an expiration and a restricted recipient
Introduction
Developers and PMs regularly need to send credentials, API keys, connection strings, and other secrets to clients and other parties outside of Kalamuna. When these are sent over email, Slack, ticket comments, or shared documents, the secret persists indefinitely in systems we don't control, and is effectively impossible to revoke. We need a single, safe channel for sharing secrets externally.
Decision
When sharing a secret with anyone outside of Kalamuna, use 1Password's Secure Share (the "share item" / share-link feature), configured with both:
- An expiration date, defaulting to 7 days (or the shortest period that still gives the recipient time to retrieve it).
- The link restricted to the specific recipient(s), by entering their email address(es) so 1Password requires email verification before the secret can be viewed.
Never paste secrets directly into email, Slack, Teams, Jira/Confluence comments, READMEs, commit messages, or shared docs.
Context
This is done for several reasons:
- Secure Share encrypts the secret and serves it through a one-time-retrievable link that we can expire or revoke, rather than leaving the secret sitting permanently in a chat log or inbox.
- Setting an expiration bounds how long the secret is exposed, so a leaked or forwarded link stops working on its own.
- Restricting the link to a named recipient's verified email prevents an intercepted or forwarded link from being opened by anyone else.
- It gives us a consistent, auditable process for external secret sharing across all practices.
1Password Business supports expiration windows of 1 hour, 1 day, 7 days, 14 days, or 30 days, and lets the sharer require that recipients verify a specific email address (or restrict sharing to approved domains) before viewing the item.
Consequences
- Secrets shared externally have a bounded lifetime and a known, verified recipient.
- Leaked, forwarded, or intercepted links expire automatically and can be revoked early.
- We have a single, documented channel for external secret sharing, simplifying onboarding and review.
- The recipient must complete an email verification step, which adds minor friction and may require a brief explanation for clients unfamiliar with 1Password.
- Sharers must choose a sensible expiration rather than defaulting to "never," which requires a small habit change.
- Sharing still introduces risk: a recipient can copy or forward a secret once retrieved, so this practice limits but does not eliminate exposure. Trust in the recipient remains a precondition.
Exceptions
- Secrets shared internally between Kalamuna team members should live in a shared 1Password vault rather than a Secure Share link.
- When a client mandates a different, equivalently secure delivery mechanism (e.g. their own secrets manager or SFTP), follow the client's documented process instead.
- For very high-sensitivity secrets, use a shorter expiration (1 hour or 1 day) rather than the 7-day default.