Can You Keep a Secret?

Computers are very good at keeping secrets, provided no human ever has to move one.

That qualification is the whole problem.

A secret begins as a string. It may be an API key, a database password, a signing key, or a token that gives one machine permission to act inside another. The string itself is not complicated. What is complicated is the ceremony around it: generate it, transfer it, store it, retrieve it, use it, rotate it, and eventually destroy it without letting it appear anywhere it should not.

Most software is designed to show us what it is doing. Terminals print output. Interfaces display values. Clipboards remember what we copied. Shells preserve command history. Logs record inputs. Collaboration tools synchronize text. AI assistants consume context. These are useful properties until the text is a secret.

Then the normal affordances of a computer become liabilities.

Why Do We Need Secrets at All?

A public service can allow anyone to read from it. The moment someone must be allowed to do something that everyone else cannot do, the service needs a way to distinguish authorized requests.

That distinction may be established with a password, session token, API key, client certificate, hardware key, or a cryptographic signature. They differ in strength and operation, but all rely on something an unauthorized party does not possess.

For the Aishna steward integration, the public can contribute and review without an account. A steward can also hide or restore content. That power needs a boundary. The secret does not prove who the steward is in any deep sense. It proves only that the current request possesses the credential entrusted with steward permissions.

Secrets are therefore not identity. They are transferable authority.

That is why leaking one matters. A leaked secret does not merely reveal information. It can hand someone else the ability to act.

The First Strange Requirement: Generate It Without Seeing It

The familiar way to generate a secret is to ask a tool for random characters and print them in a terminal. This produces a strong secret and immediately exposes it on screen.

The terminal may retain scrollback. The command may remain in shell history. Screen recording, screenshots, remote support software, or a person nearby may capture it. If an AI agent can read the terminal, the value may also enter model context or session logs.

So the safer operation is not "generate and display." It is "generate and write directly to the next protected destination." A cryptographically secure random generator should create the value in memory, and the program should send it to a secret store without printing it, placing it in command-line arguments, or serializing it into an ordinary file.

This sounds simple until we ask how the program authenticates to that secret store. The first secret often needs an earlier secret. Cloud systems call this bootstrap trust. Humans experience it as being asked to lift themselves by their own shoelaces.

There are ways out. A logged-in operating-system session can grant access to its protected credential vault. A cloud workload can receive a short-lived identity from its environment. A hardware security key can authorize an operation without releasing its private key. A deployment platform can accept a value through a masked prompt. The common feature is that an existing trust boundary carries the new secret into storage.

The important property is not that nobody ever sees the value. It is that seeing it is unnecessary for the workflow.

The Second Strange Requirement: Move It Without Copying the Wrong Thing

Sometimes direct generation into the final store is impossible. One system creates the credential and another must receive it. Now a human becomes the transport layer.

This is where secret handling becomes psychologically awkward. We are asked to perform an exact operation on an unreadable string while also being told not to inspect it, save it, or leave evidence of it. We must trust that the copy succeeded, that we copied the entire value, that no whitespace came with it, and that the destination accepted the same bytes.

The obvious response is to look. Looking provides confidence. It is also an exposure.

The less obvious danger is copying something else on the way. Clipboard workflows have state, but that state is mostly invisible. Did the first copy succeed? Did another application overwrite it? Did a clipboard manager transform it? Was a newline included? Is the field showing bullets because it accepted the secret, or because it accepted an old password still in the clipboard?

Good secret interfaces compensate for this without revealing the value. They can report length, show a short non-secret fingerprint, reject surrounding whitespace, confirm that two independently entered values match, or let the source transmit directly to the destination. A fingerprint does not need to authenticate the secret publicly. It only needs to help the operator confirm that the same hidden object arrived at both ends.

Humans need feedback. "Never look at the secret" is not a complete security design. The system must provide another way to know that the operation worked.

Is the Clipboard Safe?

The clipboard is not inherently a public broadcast, but it is not a secret vault either.

On a basic desktop, clipboard contents usually remain available to applications running in the same user session. Depending on the operating system and permissions, an application may be able to read the current clipboard, especially while active or after a paste action. Clipboard history can retain multiple entries. Cloud clipboard features may synchronize them to other devices. Remote desktop software can redirect the clipboard between machines. Third-party clipboard managers may store values in local databases. Crash reports, telemetry, browser extensions, accessibility tools, or malware can widen the path further.

Even without an attacker, the secret persists until something replaces it, the history entry is cleared, or the session ends. Copying harmless text afterward may replace the current clipboard value, but it does not guarantee removal from clipboard history, synchronized devices, manager databases, or application-specific caches.

Some password managers mark copied values as sensitive and clear them after a timer. Some operating systems and mobile platforms restrict background clipboard access or notify the user when an application reads it. These controls reduce exposure. They do not turn the clipboard into protected storage.

The practical rule is proportional: avoid the clipboard when direct injection is available; when copying is unavoidable, disable or clear history where possible, avoid synchronized clipboards, paste only into the intended field, minimize the time held, and rotate the secret if the transfer path becomes uncertain.

There is no universal "clear clipboard everywhere" button because there is no single clipboard everywhere.

Why Notes Are Not Secret Managers

A note application solves almost the opposite problem. Its purpose is to preserve, index, preview, synchronize, search, back up, and make text easy to retrieve. Each feature creates another place where a secret may survive.

A note can appear in recent-document lists, search indexes, notifications, previews, revision history, exports, device backups, and cloud synchronization. Deleting the visible note may not remove previous versions or backups. Even an encrypted notes service generally decrypts the content for search and display after login. Encryption at rest is valuable, but it does not provide the access controls, audit trail, rotation workflow, scoped retrieval, or leak detection expected from secret infrastructure.

The issue is not that notes are badly built. They are built for remembering. Secret handling is partly the discipline of controlled forgetting.

Why Password Managers Only Partly Solve It

Password managers are much better than notes. They encrypt records, reduce reuse, generate strong credentials, and often clear copied values. For human login credentials, they are usually the right tool.

Machine secrets create a different problem. An application needs the value when no human is present. A deployment pipeline needs controlled access. A team may need to revoke one service without affecting another. Operators need to know which workload read which version. Secrets need rotation, expiration, environment separation, and least-privilege policies.

Many password managers now offer command-line tools, service accounts, developer vaults, and secret injection. At that point they can serve as secret managers. But the ordinary consumer workflow of opening a vault, revealing a password, and copying it into a configuration file does not solve machine-to-machine delivery. It merely creates a well-protected starting point followed by an exposed manual transfer.

A dedicated secret manager stores encrypted values and releases them only to authorized identities or processes. Ideally, the application receives a secret at runtime without writing it into source code, configuration committed to Git, build logs, or a developer's clipboard. Access can be logged and revoked. Different environments can receive different credentials. Rotation can occur without rewriting the application.

The complexity is real because the problem is real. But complexity can also become ceremonial theater. A secret manager does not help if everyone exports its values into permanent environment files, pastes them into tickets, or grants every workload access to the entire vault.

Can JSON Keep a Secret?

No. JSON is a way to structure text. It has no secrecy, encryption, access control, or memory of its own. If an API key is written literally into a JSON file, anyone or anything that can read the file can read the key.

Architecture can still use JSON safely by storing a reference instead of the secret. The Aishna MCP configuration contains this:

"Authorization": "Bearer ${input:aishna-steward}"

The text ${input:aishna-steward} is not the credential. It is an instruction to VS Code: resolve the input with this identifier when the connection needs it. The real value is collected through a password-style prompt and stored separately in OS-backed secret storage. The JSON remains useful because it describes where the credential belongs without containing the credential itself.

This is indirection, and it is one of the basic patterns of secret architecture. Configuration names what is needed. A protected store holds it. An authorized process joins the two at runtime.

Masking is a different mechanism. When an interface shows bullets, asterisks, or the word REDACTED, it is censoring the display. That prevents shoulder surfing and accidental screenshots, but it does not tell us where the underlying value lives or how it is protected. The application may hold it in memory, persist it in an encrypted vault, save it as plain text, or not retain it at all. A censored screen proves only that the screen did not render the value.

Persistence can provide a clue. If the same credential is available after the application and computer restart, it was probably stored somewhere. That still does not identify whether the storage was secure. In this integration, the documented design says VS Code uses OS-backed secret storage. The operating system protects access to the stored value under the current user session. The JSON file does not.

When the MCP client reuses the secret, the approximate path is:

1. VS Code reads the JSON configuration and encounters the input reference.
2. It asks the protected store for the value associated with aishna-steward.
3. The value exists briefly in the client's process memory because a computer must possess a credential in some form to use it.
4. The client inserts it into the authorization header and sends the request over an encrypted TLS connection.
5. The server reads the header, compares it with its own protected copy, authorizes or rejects the action, and avoids logging or returning the value.

This is safer because the credential is not duplicated into source files, JSON, chat, terminal history, or tool arguments. It is not perfectly safe. Malware running as the user, a compromised client, an exposed server, careless request logging, or a weakness in the operating-system account can still reach the credential or its authority. Secret storage narrows the exposure surface; it does not make the secret cease to exist.

Computers reuse secrets through controlled retrieval, temporary access, and restricted transport. The strongest designs go further and use short-lived tokens, hardware-backed keys, or signatures so the most sensitive key does not have to travel at all.

How Secrets Actually Leak

Secrets rarely escape because encryption itself fails. They escape at transitions.

• A key is printed during generation.
• A command-line argument becomes visible in process listings or shell history.
• An environment variable is included in a diagnostic dump.
• A configuration file is committed to Git, then "deleted" while remaining in history.
• A CI job echoes a command or exposes a value through an imperfect masking rule.
• A secret is pasted into chat, an issue, an AI prompt, or a support transcript.
• Application logs record request headers or complete error objects.
• A screenshot captures a dashboard at the wrong moment.
• A clipboard manager preserves the transfer.
• A test credential quietly becomes a production credential and is never rotated.

The recurring pattern is boundary crossing. The secret moves from generator to operator, operator to clipboard, clipboard to interface, interface to configuration, configuration to process, and process to network request. Every crossing introduces another system with its own memory.

Security advice often says, "Do not expose secrets." Operationally, that is too vague. The useful question is: through exactly which systems must this value pass, and which of them can remember it?

The Human Is Not the Weakest Link

Calling humans the weakest link is convenient because it turns design failure into personal failure.

Secret workflows often demand incompatible behaviors. Be exact, but do not inspect. Verify, but do not reveal. Preserve access, but do not make a recoverable copy. Use a unique random string, but type it correctly. Ask for help, but never show the thing causing the problem.

The human operator is placed inside a ceremony with poor visibility and severe consequences. When the system gives no safe confirmation, people create their own: reveal the value, paste it into a temporary note, send it to themselves, keep a backup file, or reuse a familiar credential. These actions are not mysterious lapses in character. They are adaptations to missing feedback and fragile recovery.

Security improves when the safe path also provides confidence. Generate directly into storage. Use masked input. Confirm with metadata or fingerprints. Test authorization without echoing the credential. Return diagnostics such as "credential received through header and rejected" rather than returning any part of it. Make rotation easy enough that exposure is an inconvenience, not a catastrophe.

And distinguish secrecy from silence. A system that refuses to show anything may feel secure while leaving the operator unable to tell whether a secret arrived, whether the wrong one is cached, or whether no credential was sent at all. Useful diagnostics can describe the path without describing the payload.

A Better Secret Ceremony

A defensible workflow has a few clear properties:

1. Generate with a cryptographically secure random source.
2. Write directly into protected storage whenever possible.
3. Keep secrets out of terminal output, command arguments, source code, logs, chat, and ordinary files.
4. Transfer authority through authenticated tools rather than human-visible text.
5. If manual transfer is unavoidable, provide hidden verification and minimize clipboard persistence.
6. Give each service only the permissions and secret scope it needs.
7. Prefer short-lived credentials when the platform supports them.
8. Log access and actions, but never log secret values.
9. Rotate after suspected exposure and rehearse rotation before an emergency.
10. Remove old credentials and verify that removal, rather than assuming replacement was enough.

None of this makes a secret immortal. The goal is narrower: reduce the number of places where it can exist, reduce the time it remains useful, and make misuse visible.

The Real Secret

It can take hours to move a few dozen random characters from one machine to another without displaying them. That sounds absurd until we notice what the task really contains. It is not moving text. It is transferring authority across several systems while trying to leave no accidental memory behind.

The cryptography may be the easiest part. Random bytes are cheap. Human certainty is expensive.

The best secret system is therefore not the one that lectures people most severely. It is the one that needs them to handle the secret least, tells them enough to act confidently, and makes recovery ordinary when something goes wrong.

A computer can keep a secret. The harder design question is whether it can let a human use one without forcing them to become its most fragile storage device.