Credentials

Credentials is where almyty keeps the keys, passwords and sign-ins it uses on your behalf: the key for your order system, your Slack app’s details, your AI provider’s key, and so on. You add each one once, and every assistant, tool and channel that needs it can use it. For example, you save your helpdesk’s API key once, and both your support assistant and your internal help desk assistant use it without anyone copying it around.

Keys are stored encrypted. Once saved, a key is never shown again, not even to you.

The Credentials page

Open Credentials in the sidebar. One table lists every credential:

Model provider keys appear in this same table, labelled as used by their provider connection. Connect and manage providers on Models; opening their key takes you to the connection under Models. See Connect a provider.

Click any row to open the credential’s own page.

Add a credential

1. Click Add credential.
2. Give it a Name, then choose Service from one searchable list. Pick API key or token, Username and password, OAuth 2.0 sign-in, or Custom when the list does not name your service. Custom asks whether it is an OpenAI-compatible endpoint, MCP server, memory service or storage bucket.
3. Give it the one thing it needs: a key, or a sign-in at the service. A link next to the field takes you to the page where the service makes keys.
4. Who can use it starts at everyone in your organization; Change lets you pick One team or Only you (only you when your organization allows personal keys).
5. Click Save (or Sign in). almyty checks the key with the service before keeping it. If the service refuses it, you are told in plain words and the form stays filled in.

Picking a model provider saves its key and connects its models through the same form. Manage that connection on Models.

Ways a service can be added

Each service offers one or more ways, the easiest first; the others wait under Advanced on its form:

On a computer without a browser, a sign-in can finish with a code the service shows you: paste it under Advanced.

Add one right where you need it

You rarely need to open Credentials first. Wherever almyty needs a key, you can pick one of your credentials from the list, or click Create one here to add it right there, without losing what you already typed. It lands on the Credentials page like any other, comes back already picked, and an Open link next to the field goes to its page.

You’ll find this when:

• Connecting an API (Finish connecting, and the API’s Key card): the key its tools send. How it is sent comes from the API’s description and is a Change away. A username and password is a credential too (the Username and password service), and so is a sign-in with OAuth (a standard way for one service to let another act for you): for an API that uses it, Create one here runs the sign-in itself, and the credential it makes renews itself.
• Connect an API → Ready-made provider APIs (OpenAI, Mistral, Hugging Face Hub): the provider’s own API, called with the key you already keep for that provider, picked for you.
• Creating a tool: the key or password an HTTP tool sends. The tool only remembers which credential to use; the key is read when the tool runs.
• Adding a code package (SDK / npm): the token of a private package registry.
• Adding an MCP server: the server’s token.
• Memory: the account an outside memory service signs in with.
• Chat channels and AI providers, with their own forms.

A credential’s page

A credential’s page shows its name, service and account, whether it works, and Check again. Its tabs:

• Overview: the account, the key (stored encrypted and never shown again; Replace key swaps it in place, so everything that uses it keeps working), who can use it, and Delete credential. Deleting also cancels the key at the service where the service allows it; otherwise cancel it there yourself.
• Used by: everything that uses it.

A key that one MCP server, channel or app keeps for itself is listed too, with a link to where it is changed.

Organization keys and personal keys

A credential belongs either to the organization or to one person.

• Organization credentials are what shared assistants use. Adding one needs an admin or owner.
• Personal credentials are your own keys, when the organization allows them: on by default for free and personal organizations and off for production organizations. An admin turns this on or off under Settings → Organization → Personal keys.

Everyone sees the organization’s credentials; a personal one is visible to its owner and to admins. Who else may use a credential is set under who can use it.

Organization rules

Change Who can use it on a credential’s own page. Organization admins manage personal keys and credential rules under Settings. There is no separate Credentials tab for these controls.

The services

Keys to your own assistants are different

Keys that let someone call your gateway or assistant are not credentials: they live on the gateway or assistant they open. See Gateway authentication.

Where keys are kept

Every key is stored in one place, your organization’s credential store, encrypted with the platform’s key or, if your organization brings its own encryption key, with that. A key only ever leaves almyty inside the request to the service it belongs to. Every add, check, replacement, delete, share, removal and use is written to the audit log.

Related

• Who can use a credential
• Providers: AI provider keys
• Credentials API

For developers

How keys are checked. GET /models for most model providers, a whoami for Hugging Face and DigitalOcean, STS for AWS, a token grant for Google Cloud and Azure, a HeadBucket for a bucket, an initialize for an MCP server. Every URL a check probes passes the SSRF guard; private address ranges are allowed only for services with an explicit opt-in (OLLAMA_ALLOW_PRIVATE_URLS, MCP_ALLOW_PRIVATE_URLS). Audit entries record the service, the way it was added, the owner and the outcome.

What each way keeps. Key: the key and any plain fields, such as a base URL. Sign-in: the key or token the service issues; a sign-in to an MCP server also keeps the issuer, the server and the client it was made with, and is renewed before it expires (see MCP tools). App client: tenant, client id and secret (secret encrypted). Cloud role: the role ARN (an AWS CloudFormation quick-create link makes a cross-account role with an external id). Service account: the JSON, encrypted. App install: the installation token. An S3-compatible bucket takes endpoint, region, bucket, prefix and access keys.

Permissions and entitlements. Adding an organization credential needs the connections:manage permission (admins and owners). Governance needs the credentials_governance entitlement. A custom service has the same shape as a built-in one: a key, a kind, the form with secret fields marked, and how it is checked. A budget rule refuses a use before the secret is decrypted.

Routes. The Credentials page is /credentials, a credential’s page /credentials/:id, adding one /credentials/new, a provider connection /models/providers/:id, connecting one /models/providers/new; credential rules live under /settings/credential-rules.

From the terminal. almyty credentials (the @almyty/credentials package) does the same from a shell, with the same services and checks:

npx @almyty/auth login
npx @almyty/credentials services --kind inference   # what a credential can be added for
npx @almyty/credentials add openrouter --open       # sign in; nothing to paste
npx @almyty/credentials add huggingface --owner user # prompts for the key, not echoed
npx @almyty/credentials list
npx @almyty/credentials validate <id>               # check it again
npx @almyty/credentials rotate <id>                 # replace the key in place
npx @almyty/credentials grant <id> --principal agent --to <agentId>

A secret is never taken as a command-line flag: it comes from a sign-in, the prompt, --input-file or --input-stdin. On a machine without a browser, add --headless prints a URL and complete finishes it with the code the service shows. npx @almyty/credentials --help lists every command.