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

1. On Home, tap the Chief of Staff’s face or name at the top to open Workplace, and find Secrets.
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 the workplace.
5. Press Save for the workplace, 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 workplace, 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 every agent 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 workplace.

A shared key belongs to the whole workplace, like its repositories, sites, knowledge pages and Drive. There are three ways to narrow who gets one. Leave it on Admins’ agents only, save it for one of your agents, or put the work that needs it in a workplace of its own.

A separate workplace is the way to keep a client’s or another company’s keys away from everything else, because no key reaches across workplaces. See One workplace, one place.

A repository’s checks can use the workplace’s shared keys, for example a deploy token. An admin’s agent hands one over and tells you in its chat; the repository’s screen lists it under Keys for checks, and any agent can take it back. Only checks on the protected branch receive the 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.