A connector uses secrets for the passwords, tokens and keys its connection needs. For most connectors each value lives in its own field on the connection form; a Connect Anything connector keeps named secrets in a vault. This page explains both, how a stored value behaves from then on, and what to do when the connector reports a missing secret.
Stored values in connection forms
Once a value is saved, the field reads Stored password, Stored client secret, Stored private key or Stored certificate, with Replace beside it. The form shows only that a value is stored; the value itself is never shown again.
Replace clears the box and focuses it so you can type a new value. If you change your mind, Keep the stored password (the wording follows the kind of value, for example Keep the stored key) falls back to the stored one.
Show password and Hide password reveal and hide what you are typing, so you can check a new value before saving. Fields that take key material, such as a private key block, accept several lines.
Generate appears on some fields and fills the box with a new value for you to copy and use.
The copy control appears only while the box holds a new value that is not stored yet; a saved value cannot be copied, because it cannot be read.
Leave the stored value as it is and save: the connection keeps using it. You enter a value again only when the form asks you to.
The same rules cover every kind of credential: a database password or certificate, a Snowflake private key and its passphrase, a Microsoft Entra client secret, a secret access key on an S3 or remote file source, a webhook token or signing secret, and a service account key.
When the form asks for a value again
Settings that identify the connection can invalidate a stored value: the host, the database URL, the account, the username, or a file source's endpoint, region, bucket or access key ID. If Require re-entering connector secrets after a host change is on in System settings, changing any of these fields clears the stored value and the form asks for it again, naming the field.
The warning follows one shape, "The {field} changed. Enter the {noun} again.", for example "The host changed. Enter the password again." On save, the message can also read "Enter the secret access key again: the endpoint, region, bucket or access key ID changed", "Enter the password (or key) again: the server changed" or "Enter the signing secret again: this connection has no stored signing secret to keep."
The setting covers every identity field, not only the host. It is off by default; with it off, the form keeps the stored value when an identity field changes. Connect a SQL database walks through this flow on a database form.
Changing only the port is not treated as a host change, and a value you type yourself simply replaces the stored one.
File sources check the server identity on every save, so a changed endpoint, region, bucket or access key ID asks for the secret access key again even with the setting off.
Switching the sign-in method, for example Snowflake between key pair and password, clears the value that method does not use.
If the check runs when you save or test instead of while you edit, the result is the same: the form clears the masked field and shows the warning, and you enter the value once more.
Service account keys (Google connectors)
Several Google sources, such as Google BigQuery, Firestore, Realtime Database and Google Analytics, sign in with a service account key instead of a password or a private key.
Add the key with Choose File, drop it on Drop the service account JSON key here ("or browse to pick the file"), or click Paste the JSON instead, paste the contents and click Use this key. Cancel closes the paste box without using it.
A key must contain private_key, client_email, project_id and token_uri. A file that is not JSON is refused with "The key is not valid JSON", and JSON that is not a service account key is refused with a message that reads This is not a service account key ("type" must be "service_account"). A key that misses one of the fields is refused too, and the message names what is missing.
A saved key shows as a card: the header reads Stored key, and the rows read Client email, Project and Key ID. Replace takes a new file or pasted JSON, and Keep the stored key falls back to the stored one.
A stored key returns to the field as formatted JSON with its private key hidden, so the non-secret parts stay readable. A stored password or certificate has no readable content at all.
In review rows the key summarises as Not set, Stored key or New key with a short prefix of its id, rather than as JSON.
Protect a file that holds credentials
On a custom connector, right-click a file in the connector code editor and choose Protect. A protected file becomes read-only, its credential values are hidden, and it is left out of connector downloads; uploads never overwrite it.
Protection is permanent: there is no way to unprotect a file, so protect only files that hold credentials.
Store a secret in the vault
Open the connector and go to its Secrets section. On a custom connector's Connection step, click Manage Secrets to open the Secrets Vault.
Click Add secret and enter a name and a value.
Click Save in the vault. The name and the value are stored together; nothing is stored before you save.
Click Copy reference next to the secret and paste the reference in place of the value in the configuration. The reference has the form {{secret:NAME}}. For a custom connector's configuration, see Configure a custom connector.
The connector then uses the stored value when it tests the connection and when it loads data.
Name a secret after the setting it fills: in a custom connector, the setting's full dotted path, such as auth_token or oauth_credentials.client_secret. Names run up to 200 characters and use letters, digits, underscores and dots, starting with a letter, a digit or an underscore. A value runs up to 8192 characters.
Vault actions
Action
What it does
Add secret
Adds a name and a value. The secret is stored when you click Save.
Replace
Types a new value for a stored secret.
Clear
Removes a secret after you confirm; the confirmation reads "Clear this secret?" and "This cannot be undone.". It is disabled while the configuration still refers to the secret.
Copy reference
Copies the reference ({{secret:NAME}}) that the configuration uses to point at the secret.
Move to Secrets
Appears when the configuration holds a value inline: "{path} holds an inline value. Move it to the Secrets panel and reference it as {{secret:name}}?". It stores the value and replaces it with a reference. The configuration change stays unsaved until you save it.
A value that also appears literally in the configuration must be removed there before it can be stored as a secret, and a secret set that is too large is refused before saving.
What a saved value shows
The vault lists secrets by name. A stored value reads back as a mask (------------), never as the value itself.
No screen shows a value again, not even to the person who stored it. Keep your own copy; to change it, use Replace.
The vault exists from the moment the connector is created, before it is installed.
The Secrets section summarises the vault: it reads Vault is empty, or reports how many secrets are stored; an empty connector reads "Nothing is stored in this connector's Secrets vault yet.".
Change or remove a secret
To change a value, click Replace beside the secret, type the new value and save. The connector uses the new value from then on. If the service refuses the old value, for example after a failed sign-in, replacing it is the fix.
Some connections keep the previous value during a changeover window: the old value stays accepted until you stop it, and an ordinary save keeps it rather than dropping it. For a webhook, follow Rotate a webhook secret.
To remove a value, click Clear and confirm. While the configuration still refers to the name, Clear stays disabled; stop referring to it and save first.
When a secret is missing or refused
If the configuration refers to a name with no stored value, the save or the sync is refused before anything runs, and the message names the secret: references secret(s) that are not set: followed by the names. Store each value in the Secrets section, then save or sync again. A reference without a value is also shown there as "{path} references secret {secret}, which is not stored.", with Add "…" and Edit config beside it.
A delete for a name with no stored value answers is not set; there is nothing to remove.
Secrets in a connector chat
The connector agent can read the stored secret names and the wiring report, which shows the setting each stored name binds and what is still missing, but never a value.
When the agent needs a value, it asks you to store it in the connector's Secrets section and waits. The chat shows Waiting for user to store secret(s) in the Secrets panel. Requested: followed by the names. Store the values, then send the next message.
On a Connect Any API connector, the agent points you to the connection form instead of taking a value in the chat. See Connect any API.
If you paste a credential into the chat, it is moved into the vault, erased from the stored conversation and replaced with a <redacted:NAME> marker. Markers and placeholders are not values, so store credentials in the vault rather than pasting them.
A secret stored under the wrong name is fixed by renaming it, never by storing it again; the value is kept. The chat confirms: Renamed vault secret "from" to "to"; the value was kept.
When the service refuses a stored value, the agent asks for that name again so you can replace it in the panel.
Who can manage secrets
Entering or replacing a stored value in a connection form, and storing or clearing a connector's vault secrets, needs Create/Edit Lake Objects. See Who can do what in the Lake.
With the view permission alone, you can open the vault and read secret names, but not set or delete them; the vault tells you that you have view-only access.
The agent never asks for a secret value in the chat; it asks you to store the value in the Secrets section.
Duplicates
Duplicating a connector keeps the connection's stored password but copies none of its vault secrets.
The copy starts with an empty vault, so store the secret values again on the copy.
Questions, answered
Why does the field show Stored password instead of my value?
Because a value is saved for it. Stored values are write-only: a form field shows only Stored password (or the matching kind), the vault shows a mask (------------), and no screen or chat result shows the value itself, to anyone, including you. Keep your own copy when you store it; to change it, use Replace.
If I save without re-typing the password, is it kept?
Yes. Leave the stored value as it is and save; the connection keeps using it. You retype a value only when the form asks you to re-enter it, for example after an identity field changed.
I clicked Replace by mistake. Can I keep the stored value?
Usually yes. Click Keep the stored password, or the matching wording such as Keep the stored key, and the stored value stays. If an identity field changed and the re-entry setting is on, that option is replaced by the re-entry warning, and you must enter the value again.
Which changes make the form ask for a secret again?
Changes to the fields that identify the connection: the host, the database URL, the account, the username, or a file source's endpoint, region, bucket or access key ID. The form clears the stored value only when Require re-entering connector secrets after a host change is on in System settings; the setting is off by default. Changing only the port does not trigger this. File sources check the server identity on every save, whatever the setting.
How do I replace a stored vault secret?
Open the connector's Secrets section, click Replace beside the secret, type the new value and save. The connector uses the new value from then on. If the connection keeps a changeover window, the old value stays accepted until you stop it; see Webhook and RabbitMQ.
Why is Clear disabled on a secret?
Because the configuration still refers to the secret. Update the configuration to stop using the name, save, then click Clear.
Can I copy a stored secret into another tool?
Not the value, because a stored value cannot be read. The copy control appears only while a new, unsaved value is in the box. In the vault, Copy reference copies the {{secret:NAME}} text that points at the secret, not the secret itself.
What does Generate do next to a secret field?
It creates a value for you. Click it and the field fills with a new value, ready to copy to the service that must present it, for example a webhook sender, and you save the connection afterwards. Once saved, the value is never shown again.
What happens to secrets when I duplicate a connector?
The copy keeps the connection's stored password but none of the vault secrets, and its vault starts empty. Store the values again on the copy.
The connector agent asks me to store a secret. Where do I put it?
In the connector's Secrets section. On a custom connector, Manage Secrets opens the Secrets Vault; for the connector end to end, see Connect Anything (custom connector). Store the value there and send the next message; the chat waits until you do. The chat does not take the value itself.
I pasted a credential into the chat. Can anyone still read it there?
No. The value is moved into the vault, erased from the stored conversation, and replaced with a <redacted:NAME> marker. The marker is not the value and cannot be used as one.
I can open the vault but cannot add or remove secrets. Why?
You have view-only access. Reading secret names needs a view permission; setting and deleting them needs Create/Edit Lake Objects. Ask your administrator to add it to your role. See Who can do what in the Lake.