Never paste a key into a chat: anything typed there stays in the conversation. The form is the only way in.

1. Open the room on Home and choose its Secrets tab.
2. Press Add a secret. A member sees Add a secret for one of your agents instead, and the key stays private to the agent they pick.
3. Give it the name the tool expects, such as GH_TOKEN, and paste the value whole. A key with several lines, such as an SSH key, survives the paste box.
4. As an admin, choose Whose agents get it: Admins’ agents only is the default, or Every agent in this room.
5. Press Save for this room, or Save for the agent you chose.

Saving a name that already exists replaces the value. It does not add a second key, and it keeps who the key reaches.

Only a workplace admin can add a key for the room, copy its value, replace it or delete it. Members see each shared key’s name, what it is for, a masked preview and when it last changed. Nobody sees the value again except through Copy the value on the key’s screen, which puts it on your clipboard.

A shared key also says whose agents receive it. By default that is admins’ agents only: members see the key in the list, but their agents are never handed the value. An admin opens it to the whole room with Open to everyone on the key’s screen, and closes it again with Admins only. The screen lists the agents it reaches by name.

A private key is invisible to everyone but its owner, admins included. Deleting the agent deletes its private keys too. Every key carries a line on What it’s for, written by the first agent to use it and editable by anyone who can manage the key.

When an agent starts a turn, every key it is allowed to have is placed in its environment under the key’s name. The command that needs the value reads it there. A key you save or change reaches the agent on its next turn, not the one already running.

The value is stripped out of the agent’s stored transcript, its activity line and its error output. That is a strong safeguard and not a guarantee: an agent has a full shell and can read its own environment.

An agent can also save a key a tool just issued it, saying what it is for. Only an admin’s agent can create or change a key shared by the room.

Repositories, sites, knowledge pages and Drive are shared by the whole workplace, but a key stays in the room it was saved in. Move an agent to another room and it stops receiving the old room’s keys, so save the key again where it now works. When an agent reports a key missing, ask whether it was ever saved in that room.

Deleting a room deletes its keys along with its agents and notes. See Workplace and rooms.

A repository’s checks can be allowed to use a room’s shared keys, for example a deploy token. An admin’s agent asks, and an admin decides on the repository’s screen with Allow for approved CI or Keep private. Only checks on the protected branch receive an allowed key, and the value is masked out of any log. Private keys never reach checks. See Keys for checks.

An always-on app can use keys too, for example a chat bot’s token. Ask your agent to deploy it with the key it needs. The running app gets the key directly, and the key is never written into its files. An agent can only pass on a key it has itself. If you change a key here, the app gets the new one at its next deploy. A plain website of files never gets a key.