Agents
Yanki helps agent teams move fast without leaking credentials. Encrypt locally with AES-256-GCM, pass burn-on-read links across agent workflows, and enforce read behavior with burn-after-read defaults or controlled read windows.
Workflow patterns
A coding agent generates release artifacts, then hands off deploy credentials as a burn-on-read note to the release step.
yanki create "release_token=$DEPLOY_TOKEN"
A planning agent can pass temporary database credentials to an execution agent without persisting plaintext in shared memory.
yanki read "https://useyanki.dev/n/<id>#<key>"
A parent agent delegates to a short-lived subprocess and passes credentials through a burn-on-read link instead of process args.
yanki create "tool_step_key=$API_TOKEN"
Long-running coding tasks can checkpoint sensitive runtime data as notes and consume them only when the workflow restarts.
yanki create "resume_secret=$SERVICE_KEY"
Queue payloads hold burn-on-read links, so delayed jobs do not carry reusable plaintext secrets.
enqueue task metadata with a Yanki link, not raw credentials
For sensitive merges or production fixes, agents can request approval with burn-on-read secrets and continue after verified consumption.
share full link including hash fragment
Operational practices
- Treat the full link as sensitive material and keep it out of public channels.
- Prefer short-lived credentials before creating a burn-on-read note.
- Never strip the URL hash fragment; it contains the decryption key.
- Use separate notes per environment and per workflow stage.
- Use explicit expiration windows for queued or delayed execution paths.
- Store links in task state, not plaintext secrets in logs or memory snapshots.