Credentials (saved logins and keys)

Credentials (saved logins and keys)

Credentials is the workspace's vault: one place for every login, password, API key and token you give Plank. Open it from Sources: the Credentials row there shows how many logins are saved and opens the list (on the phone: More → Sources → Credentials). Until 11 October 2026 it was a tab of the Integrations page, and until 12 October 2026 a sidebar row of its own; an old link to it still opens it.

Everything there is encrypted. Nothing in it is ever shown back to the assistant: Plank uses a saved login for the assistant — it types it into a website, or hands it to one script run — so the value never has to pass through the chat again.

Giving the assistant a password

Just paste it into the chat, the way you'd tell a colleague:

zapis.kz Логин: anna Пароль: S3cret-pass

Before your message reaches the assistant, Plank takes the password out and puts a marker in its place. The assistant (and anyone else in a shared chat) sees the marker, not the password. The assistant then saves it under a name and tells you so, for example:

Saved the login for zapis.kz in Credentials — only you can see it. The password is hidden in the chat. To change or delete it: Credentials.

If saving fails, the password is still removed from the message — Plank never lets it through as a fallback. The assistant will ask you to add it yourself in Credentials → Add.

You can also add one directly: Credentials → Add, choose the kind (login and password, API key, token, …), give it a name and, for a website, the site it belongs to.

An API key you enter in an integration's setup form or in Settings (a name like GITHUB_TOKEN) is saved in the vault at the same moment, so it appears in Credentials right away; changing or deleting it in that form updates the vault too.

In your own chats such a key is in the assistant's command environment ($GITHUB_TOKEN) only in the workspace it was saved for. A key saved for you across all your workspaces is there in every one of them.

An integration you connected by signing in (for example Notion) keeps its access token in the vault as well, named «MCP: <integration>». Plank renews it on its own and only Plank uses it: it is sent to that integration and never handed to the assistant or to a script. To change it, reconnect the integration in Integrations; to remove it, Disconnect the integration — the token goes with it. While the integration is connected, Credentials will not let you delete or replace it.

Personal or shared

• Personal — only you can see and use it. Your assistant uses it in your own chats.
• Shared — every member of the workspace can use it, and the assistant in a shared team chat can use it too.

There is no default: when you add a login under Add you choose Only me or The whole space, and when you give one to the assistant in your own chat it first asks which you want. A login for a system the whole team works in — 1C, the bank, a CRM, a marketplace — should usually be shared: a personal one stays invisible to everyone who joins the workspace later, and only you can share it. A login typed in a shared team chat is shared.

A personal item can also be connected in all your workspaces: then it follows you, and your own chats in any workspace where you are the only member can use it — for example, your Google calendar from a Telegram bot that lives in another workspace. In a workspace with other people (not counting the one you connected it from) it works only after you say yes for that workspace, because a bot or automation you created there acts as you for everyone who writes to it; the assistant asks the first time it needs it there, and you can take the yes back the same way. If someone joins a workspace where you were alone, it stops there until you say yes. A workspace's own item of the same kind still comes first there. Such an item cannot be shared; ask the assistant to bring it back into one workspace first. Your assistant asks which you want when it saves a personal account. To change it later, open the item in Access and choose Make available in all my spaces, or Only in this space to bring it back (the yeses you gave in other workspaces are forgotten); or ask the assistant.

My connections

At the top of Access, My connections lists everything that follows you into all your workspaces: your items connected in all your spaces, and the connectors (MCP servers) you connected for your whole account. Each item says whether it works In all your spaces or in how many of them (Works in 2 of 3), and when and where it was last used. Open one to see it By space, workspace by workspace: Works — only you are here, Works — you allowed it (with Revoke), Not allowed — other people are here (with Allow), or Not used — you are a viewer here. A connector can only be Disconnected here: an OAuth connector loses its login in every workspace and can be connected again; any other is removed from all of them at once. Only you see this list — a shared team chat never sees your account items.

A personal login is never used in a shared team chat, even by the workspace owner's assistant. To make one available to the team, open it and choose Make shared; Make personal takes it back. Viewers can see the list but cannot add, change or use a saved login.

Deleting

Delete removes the secret immediately — it is wiped, not hidden, and cannot be recovered. The name stays in the history for 90 days so you can still see that it existed and who used it. If you leave a workspace, your personal saved logins in it are wiped the same way.

Saved browser logins

When you sign in to a site in the assistant's cloud browser, the login is kept here as a Browser session item named after the session, for example «Браузер: Kaspi». Nobody types it and nobody can read it: it is used only by the cloud browser, to open that site already signed in, and it never reaches the assistant, a script or the workspace's files.

• Yours stays yours. A login you made in your own browser session opens signed in in every workspace you work in, and never in a shared chat's browser. A login made in a shared chat's browser belongs to the workspace and is used only there.
• You can rename it or delete it — not edit it, share it or hand it to a script. Deleting it signs the assistant out of that site for good: the next session starts at the sign-in page. Close any open browser tab for that site first, or it will save the login again when it closes.

Who used it, and when

Open an entry and choose Usage history: every time it was saved, changed, shared, typed into a website or handed to a script — who did it, when, and on which site. The history never contains the secret itself.

What the assistant does with it

• A website login — the assistant asks Plank to log in for it. Plank types the username and password into the page itself, and only on the site the login is saved for. If a page on another site asks for it, Plank refuses.
• A script or a scheduled job — the script asks for the value when it runs. It is handed to that one run and not written anywhere in your files.

A website password is, by default, only used by Plank to log in — it is never handed to a script. An API key or token is handed to the scripts that need it.

---

For the assistant

Logins, passwords, API keys and tokens live in the workspace vault. Never write a secret to a file, AGENTS.md, memory, an app-data table or a source row — not token.json, not .env, not credentials.json. Never print one, and never ask for one to be pasted twice.

Tools

A marker [plank:credential not-saved field=…] means capture failed: the value is gone from the message, nothing was saved. Ask the person to add it in Credentials → Add; do not ask them to paste it again.

plank_credential_save and a new plank_credential_request need owner — there is no default. Unless the person already said, ask one question first: «Сделать этот доступ общим для всего пространства или только для вас?», recommending shared for a system the space works in (1C, a bank, a CRM, a marketplace or ad account) and personal for their own mailbox, messenger or card. In a shared team chat pass owner: "workspace" without asking. A captured pending_id waits 24 hours, so asking first loses nothing.

After saving, tell the person in one line what you saved, whether it is personal or shared, and that they can change or delete it under Credentials.

Using a key from a script

A script reads a saved key when it runs — nothing is copied into a file and nothing is printed. Name the item by its label from Credentials.

In Python (standard library only; plank_vault.py is in the sandbox and vendored into every kit that needs it):

from plank_vault import get

key = get("amoCRM key")              # the item's main value (key / token / OAuth JSON)
conn = get("1C base")                # a login or connection: {"username": ..., "password": ...}
pwd = get("1C base", "password")     # one field

From the shell, give a value to exactly one command:

plank-secret run --env API_KEY="amoCRM key" -- python3 sync.py
plank-secret run --env PASS="1C base:password" -- ./login.sh
plank-secret file "Google token" --as token.json --writeback -- python3 scripts/google/read-sheet.py {}

run puts the value in that command's environment only (item:field — or item.field — picks one field, and either form reaches any field the item holds: "Support API.base_url" as well as "Support API.key"). file writes it to a private temporary file, passes the path in place of {}, and deletes it when the command ends; with --writeback, a file the command rewrote (a refreshed OAuth token) is saved back. plank-secret get <item> --field <f> PRINTS the value — it is for a person debugging in a terminal; an assistant never runs it, and its output never goes into a chat. In a chat, use plank-secret run --env or import plank_vault instead — get prints the value into the transcript, and although the redactor masks a value it recognises, don't rely on it.

There is no Node helper yet: from Node, start the program under plank-secret run --env … and read process.env.

Items Plank keeps for itself. A Telegram bot token given to a trigger is moved into a shared item named «Бот: <trigger name>»; the trigger list says only that a token is configured and which item holds it (botTokenStatus.vaultItem), never its value. The support lane's ChatApp connection is kept as «ChatApp (линия поддержки)»: Plank refreshes it itself, so in Credentials it can only be renamed — it cannot be shared to scripts, replaced or deleted there.

Where it works. The same calls work in a chat, a @plank-button run, a schedule and a webhook trigger. Which items a run may use:

• a shared item — every automation of that workspace;
• a personal item — only runs its owner owns: a trigger they created, a button they clicked, or their own chat. Those runs execute in the owner's own container. No other member's personal item is ever handed to a script.

An item with an environment variable name (env_name) is also put straight into a button or trigger run's environment, under the same rule; if a personal item and a shared one have the same name, the personal one wins. Letting an automation use another member's personal item comes later.

When it refuses. The error says why in one sentence and never contains the value:

• «доступ <name> не найден — сохраните его в «Доступы» (список: plank_credentials_list)» — nothing by that name: save it in Credentials, or check the label.
• «нет прав на использование в автоматизации: «<name>» — личный доступ участника; …» — the item exists, but as a member's personal item, and this run is not theirs (a shared container or its automations). The owner can make it shared in Credentials.
• «этот доступ используется только платформой …» — a website login is platform_only by default and a script cannot read it; use browser_login_with_credential, or the person can change it in Credentials if a script genuinely needs it.
• «Доступ выдаётся только скрипту в вашем контейнере» — the request did not come from a script in this workspace's container.
• «Наблюдатель не может пользоваться сохранёнными доступами» — a viewer's chat releases nothing.
• «доступ удалён» — the item was deleted.

In Python these arrive as VaultNotFound, VaultRefused, VaultAmbiguous (several items match — name one by its label) and VaultUnavailable (no vault here), so a script can fall back to an older file. Kits read the vault first, then an environment variable, then their old file — so a workspace with a token.json keeps working. When you set up something new, save the credential in the vault rather than writing that file.

A script that obtains a credential itself (an OAuth grant, a refreshed token) saves it with plank_vault.save(label, kind, fields, provider=…) — it is stored as saved by a script, and the value never passes through the chat. Two kits move their old files for you, when you run them: scripts/google/oauth/authorize.py saves the Google grant in the vault and deletes token.json, and scripts/1c/odata/move-login-to-vault.py (dry run first, then --apply) moves the 1C login out of credentials.json. Do not move other token files by hand.

The 1C login the platform uses to write documents for you is a shared item that stays «platform only»: it cannot be switched to scripts or made personal. The 1C scripts use their own item, which move-login-to-vault.py creates.