workshop.institute
reference · secrets

secrets in a workshop

Some workshops connect to a cloud provider or a third-party service and need a credential to do it. Here's where those secrets go, why the agent won't take one in chat, and what to do if one leaks.

definition

what counts as a secret

A secret is anything a provider treats as a bearer credential: a cloud provider key such as an AWS credential, a third-party service key such as a Stripe key, or an OAuth token. Most workshops need none of these. The ones that do name them in their spec, and the handling below is the same across all of them.

the rule

why the agent never accepts a secret in chat

Chat goes into the transcript. Transcripts can be reviewed in support tooling, exported by you, replayed in future sessions, and pasted into screenshots. A key dropped into chat is a key on disk in a file you don't fully control.

The same applies to running !export SOME_API_KEY=… through the bash prefix — the whole command, including the value, lands in chat history. The agent will decline both and point you at one of the flows below.

how to store one

when you do need to hand a workshop a secret

A workshop that touches a cloud provider or a third-party service — a later AWS lesson, say — needs the real credential. There are three ways to store the value, and none of them is chat:

the default
lwc env set
Lives in ~/.lwc/env.json, chmod 600, picked up by every workshop automatically. Hidden prompt, no echo, one place to manage keys.
one-off
shell export
Lives in the current shell's environment and evaporates when the shell closes. For power-user / one-off sessions where persistence isn't wanted.
per-workshop
.env file
Lives in the workshop root, gitignored, loaded by tsx --env-file-if-exists. Scopes the credential to a single workshop instead of every one.

Run the default flow in your terminal, not in chat. It prompts for the value with the input hidden, so the key is never echoed to the screen:

terminal
$ lwc env set AWS_SECRET_ACCESS_KEY
# prompts for the value; the input is hidden and never echoed
recovery

if you accidentally leaked a key

01
Revoke it

At the provider's dashboard — find the leaked credential and revoke it, so the old value stops working immediately.

02
Rotate downstream

Rotate any downstream consumers that were using the old value.

03
Don't scrub the transcript

Once a value lands in chat, treat it as leaked and replace it. Deleting the message afterward does not undo the exposure.

threat model

filesystem permission is the boundary

Not encryption-at-rest. This is the same posture as ~/.aws/credentials or a .env file: anyone who can read the file as your user can use the key. We don't encrypt ~/.lwc/env.json because anyone with that level of filesystem access already has whatever the key would have protected.

The agent's job

The agent keeps secrets from landing somewhere weaker than the filesystem, such as chat history, screenshots, or exported transcripts. Everything on this page follows from that one rule.

sign in or get started

Enter your email — we'll send you a 6-digit code. New here? An account is created automatically.