Short answer: credential sharing for AI agents is two separate jobs. Delivery gets one credential to one recipient once, and a one-time encrypted link does that well. Custody stores, rotates, and audits credentials for workloads that run for months, and that takes a vault or secrets manager. Evergist does delivery and is not a vault.
What is the difference between a handoff and custody?
A handoff ends. Custody doesn't.
In a handoff, one party has a credential and another needs it for a task. Once the recipient has read it, the delivery channel should hold nothing. In custody, a system keeps the credential, decides who may fetch it, records each fetch, and replaces it on a schedule.
Password Pusher drew the same line in its August 2026 post on this topic, calling the two models "persistent vault access" and "ephemeral handoff" and saying they solve different problems. We agree with that split. Most bad setups come from using one tool for both jobs: a vault token handed to a one-off agent because it was nearby, or a production service that boots from a link someone pasted in a ticket.
When does a one-time link fit?
When the recipient needs the value once and has no shared identity system with the sender.
- Agents in different sandboxes. A setup agent and a deploy agent with no shared filesystem and no common login. How AI agents can share secrets has the steps.
- Agent to person. The agent generated a database password and a person needs it. The person opens a link in a browser and needs no account.
- Person to agent, for one task. Giving Claude Code an API key safely covers that case.
- Across an organization boundary. A contractor's agent has no seat in your vault, and giving it one for a single key is more access than the job needs.
- Bootstrapping. A new agent needs its first token before it can log in to the vault at all. Something has to carry that token, and a link that burns on read is a reasonable carrier.
In each case an Evergist link works the same way. The sending machine encrypts, the server holds ciphertext it can't read, the note allows a set number of views, and it expires between 1 minute and 30 days after creation.
When do you need a vault or secrets manager?
When any of these is true.
- The workload reads the credential on every run. A note with one view serves one read. Raising the view limit to cover a cron job turns a handoff tool into a bad vault.
- The credential rotates. A note is a frozen copy. Rotate the key and the note still holds the old one.
- Someone will ask who read it. Evergist keeps no creator field, no IP addresses, and no read timestamps, so there is no access log to produce. A vault keeps one.
- You need to revoke access fast. HashiCorp's Vault docs on leases say every dynamic secret has a lease, revoking the lease invalidates the secret immediately, and an operator can revoke a whole tree of secrets by prefix after an intrusion. A link can't do any of that to the credential inside it.
- The recipient must prove who it is. A link is a bearer token. Whoever holds it is the recipient. A vault authenticates the caller first.
- The payload is a file or is large. Evergist holds text only, up to 512 KiB.
Decision table
| Question | One-time link | Vault or secrets manager |
|---|---|---|
| How many reads? | One, or a few | Many, over time |
| How long is the credential needed? | One task or session | Months, across restarts |
| Who is the recipient? | Anyone holding the link | An authenticated identity |
| Does the recipient need an account? | No | Yes |
| Rotation | None. The note is a copy | Built in or scripted |
| Audit trail | None with Evergist | Per-read log |
| Revocation | Delete the note before it's read | Revoke the credential itself |
| Setup | One command | A service to run and a policy to write |
| If the delivery record leaks later | A dead link | Depends on the token's scope and life |
What does a one-time link not protect?
The credential itself. A link protects the delivery and nothing after it.
The agent that reads the note sees the value. It lands in that agent's context, and the agent may write it to disk or print it. What limits the damage is the credential's own scope and lifetime, so issue a narrow, short-lived credential first and deliver it second.
A one-view note doubles as a tamper signal. If the intended recipient gets "Gist not found", the note expired, was deleted, or someone else read it first. The note can't say which, or who. Treat it as exposed and rotate. The sender can check beforehand with status, which reads expiry and views left without using a view.
npx -y evergist status "https://evergist.com/g/<id>#<key>"
Services make different trades on the record of the handoff. Password Pusher's post says its audit log records when a push was viewed and from which IP address. The same post says it "is also not a zero-knowledge system", because the server decrypts the payload for retrieval. Evergist makes the opposite trade. Our server can't read the note and keeps no record of who read it. If your compliance team needs the handoff logged, pick on that. Our list of what the server stores has every field.
Should an agent get vault access or a one-time credential?
Ask how often it runs.
An agent that does a single migration or deploy should get one credential scoped to that task, delivered once, and revoked when the task ends. Giving it a vault token means it holds standing access to everything the token's policy allows, for as long as the token lives, in a process that reads untrusted input.
An agent that runs every night should get its own identity in the vault with a narrow policy. Feeding it a fresh link each night is custody done by hand, and someone will eventually paste the key into a config file to stop doing it.
How do the two work together?
The vault issues, the link carries. This covers the recipient the vault can't reach.
An orchestrator with vault access requests a short-lived credential, pipes it into a one-view note, and passes only the link on. $SHORT_LIVED_TOKEN stands for whatever your vault returned.
printf '%s' "$SHORT_LIVED_TOKEN" | npx -y evergist create --views 1 --expires 10m --json
The receiving agent reads it once. burned in the output confirms the note is gone.
npx -y evergist read "https://evergist.com/g/<id>#<key>" --json
The vault still owns the credential's life, so revoke it there when the task ends. The agent guide has the MCP tools that do the same two steps.
Questions
How do two agents pass a credential without a shared vault?
The sending agent encrypts the credential into a one-view note and gives the other agent the link over whatever channel they already share. The second agent reads it once and the note is deleted. If the channel itself is sensitive, add a password and deliver it separately.
Do subagents on the same machine need a link?
No. Subagents that share a filesystem can read the same file or inherit an environment variable from the parent process, and a link adds a network round trip for nothing. Links are for crossing a boundary: another sandbox, another machine, another organization, or a person.
Is Evergist a secrets manager?
No. It stores ciphertext for up to 30 days and deletes it on expiry or after the last allowed view. It doesn't rotate credentials, inject them at runtime, authenticate readers, or keep an access log.
Does the agent that opens the link see the credential?
Yes. Reading the note decrypts it on the agent's machine and returns the text to the agent. Redirecting the output to a file keeps it out of the transcript, and the agent can still read that file later.