Use case
Encrypted Notes for Developers: API Keys, Tokens and Config
Developers leak secrets in predictable places: chat threads, ticket comments, screenshots in pull requests, and commit history. Most of those leaks are not carelessness — they are the path of least resistance when someone needs a key in the next five minutes.
Last reviewed Reviewed by Inkrypt Security Team
Where developer secrets actually leak
Before reaching for a tool, it is worth being precise about the failure modes, because they are not the ones people expect. In practice the recurring ones are mundane.
- Chat history. A staging database URL pasted into a channel in 2024 is still searchable today, still valid, and visible to everyone who has since joined that channel.
- Ticket systems. Credentials pasted into a Jira comment inherit that project's permissions, which are usually broader than intended and rarely reviewed.
- Commit history. A key removed in a later commit is still in the history. Force-pushing over it does not remove it from anyone who already fetched, or from forks.
- Screenshots. A terminal screenshot attached to a bug report frequently includes an environment variable in scrollback.
- `.env` files over email. The file gets forwarded, saved to Downloads, and stays there.
What these share is persistence. The secret is not exposed at the moment of sharing; it becomes exposed later, when the container it lives in is breached or its access list quietly widens.
Where an encrypted note fits — and where it does not
An encrypted note is a transport mechanism, not a secrets store. That distinction determines whether you are using it correctly.
| Need | Right tool | Why |
|---|---|---|
| Give a teammate a staging key right now | Encrypted note | One-off, expires, leaves no permanent record |
| Application reads a secret at runtime | Secrets manager (Vault, AWS/GCP secret managers) | Rotation, audit trail, IAM-scoped access |
| CI pipeline needs a deploy token | CI provider's encrypted secrets | Injected at build time, never in the repo |
| Team shares a long-lived vendor login | Password manager with a shared vault | Rotation, revocation, membership tracking |
| Hand a client a credential once, cross-organisation | Encrypted note | No shared tooling required on either side |
Do not build a workflow on this
If a secret is needed repeatedly, by a machine, or by a rotating set of people, it belongs in a secrets manager with an audit trail. Encrypted notes are for the one-off human handoff that would otherwise happen in Slack.
A working pattern
Name the note without naming the secret
The note name becomes the URL.handoff-2026-07-31is fine;prod-postgres-rootannounces the contents to anyone who sees the link in a log or a browser history.Include context, not just the value
Say what the credential is for, which environment, and when it expires or will be rotated. A key with no context gets pasted into the wrong environment.Set a short expiry and a view limit of two
Two rather than one, because corporate link scanners routinely consume the first fetch. See self-destructing notes.Split the channels
Link in the ticket or chat; password over a call or a password manager share. Both in the same place defeats the purpose entirely.Rotate afterwards
Any credential that has been transported by a human should be on a rotation list. Secure transport reduces exposure; it does not eliminate the fact that the secret moved.
Other things developers use notes for
- Incident scratch space. Pasting log excerpts or stack traces containing internal hostnames somewhere that expires, rather than into a permanent doc.
- Handing a customer a debug token without opening an account for them or emailing it in plaintext.
- Cross-organisation handoffs where you and the recipient share no tooling — the common agency and contractor case.
- Recovery codes during a migration, held somewhere temporary and deliberately short-lived rather than in a chat thread forever.
A checklist worth adopting
- Never paste a live credential into chat, a ticket, or a commit — treat it as a reflex, not a judgement call.
- Machine-consumed secrets go in a secrets manager, always.
- Human handoffs go through an expiring encrypted note with split channels.
- Anything shared by a human gets rotated on a schedule.
- Run a secret scanner in pre-commit hooks and in CI, because the reflex will occasionally fail.
Frequently asked questions
Should I use encrypted notes instead of a secrets manager?
No — alongside one. A secrets manager handles machine access, rotation and audit logging. An encrypted note handles the one-off human handoff that would otherwise land in Slack. They solve different problems.
Is this suitable for sharing production credentials?
It is far better than chat, but the strongest answer for production is to avoid sharing at all — provision individual accounts with scoped IAM permissions. Where a handoff is genuinely unavoidable, use a short expiry, split channels, and rotate immediately afterwards.
Can I use Inkrypt from a script or CI job?
No. There is no public API, deliberately — encryption happens in the browser, and an API that accepted plaintext would break the zero-knowledge property. For automation, use your CI provider's encrypted secrets or a secrets manager.
What about sharing a whole .env file?
Notes hold text, so an .env file pastes in fine. Set a short expiry, and treat every value in it as needing rotation afterwards — a bundle of secrets shared at once is a bundle of secrets to rotate at once.
Related reading
For IT and DevOps
Onboarding, offboarding and infrastructure handovers.
Read moreSelf-destructing notes
Expiry and view limits, and how scanners interact with them.
Read moreHow to share passwords securely online
The general guide behind these developer-specific patterns.
Read moreSecurity architecture
What our servers hold, at field level.
Read moreWrite your first encrypted note
No account, no email address, no download. Type a note, set a password, share the link.
Open the notepad