What the platform keeps of the answer file
Every answer file you deploy is stored, whole and permanently, and every value you change between two deploys is written to the setup run's log. So never type a secret into a field that takes free text, such as a display name. The platform cannot tell that the text is a secret, and will keep it and print it.
The answer file is the file that states a deployment's decisions: its name and
domain, the anchor organization, the root account, the machine clients. On a
local stack it is infra/environments/local/answers.yaml.
Secrets go in as references
A field that needs a secret takes a reference to it, written
secret://<path>, and the secret itself stays in the secret store. The setup
run checks this before it writes anything: a credential typed where a reference
belongs is refused, the run stops, and the message names the field and never the
value.
That check covers the fields the platform knows hold secrets. It cannot cover the rest.
A free-text field is accepted as written
Display names, and any other field that takes text you choose, are checked for shape only: length and permitted characters. A password, an API key or a token pasted into one of them by mistake passes that check. The platform then treats it as what the field says it is, a value somebody reviewed and meant to deploy:
| What happens to the value | Where |
|---|---|
| It is stored. Each run stores the answer file as a new version when it differs from the last one. A stored version is never changed or deleted; the database refuses both | The configuration store, in the platform's database |
It is logged. Before the run changes anything, it logs each value that differs from the last applied version, with the old value and the new one (the event bootstrap.configuration.drift). A secret:// reference is logged as a reference and marked as one; free text is logged as it is | The setup run's output, and wherever your deployment sends logs |
| It may be published. The anchor's display name is published as the organization's name in its entity configuration, which anyone can fetch. The anchor's contacts and dispute route are published too | The anchor's public address |
The log entry appears twice for one mistake: once on the deploy that introduces the value, and again on the deploy that removes it, as the old value.
What the log scan catches, and what it misses
The stack can scan its own logs for secrets:
node infra/scripts/stack.ts scan-logs
It searches every service's log, the setup run's output, the exported traces and the caught mail for the values held in the stack's secrets directory, and reports which secret appeared and where, never the value. It is the net for this mistake when the pasted secret is one of the stack's own.
It finds nothing else. A secret from outside the stack, such as a key for another system, is not in the secrets directory, so the scan cannot know to look for it. A value shorter than 16 characters is not searched for either. A clean scan is therefore not proof that a file held no secret.
If a secret was deployed in a free-text field
- Treat the secret as disclosed and replace it where it is used. This is the step that matters; the others only stop it spreading.
- Correct the answer file and deploy again.
- Expect the old value once more in that deploy's log, and handle that log as you would the secret.
The stored version that holds the value stays in the configuration store. No command removes it, by design: the store exists so that what a deployment was configured as, and since when, can always be answered. The file's own history in version control holds the value too.
The way to avoid all of this is review. An answer file is a reviewed file, and a reviewer who reads a display name that looks like a key should stop the change.