Credentials

Credentials store secret keys, tokens, and authentication data for your services. Credentials explains where 2501 keeps the values and what uses them.

​

Managing Credentials

Go to Command Center → Credentials and click Create Credential to create an entry.

​

Name

A descriptive identifier for the credential. Use naming conventions that show its purpose and target system. Example: prod_db_ssh_root or aws_prod_api_key

​

Description

Additional context about what this credential is for. Example: Root SSH credentials for production Ubuntu database server

​

Scope

By default, credentials are scoped to the current organization, so only that org’s agents can use them. Pick Scoped to Tenant in the Scope selector to make a credential available to all organizations. Selecting the tenant scope requires tenant-level access; without it the selector stays on Scoped to Organization. A credential’s scope is fixed when it is created. The detail page shows it read-only; to change it, delete the credential and create it again.

​

Type

• Value: Store the credential directly in 2501’s encrypted storage
• Vault Path: Reference a secret stored in an external vault like HashiCorp Vault
• PAM account: Read the value from CyberArk or WALLIX. See Privileged access.

When using vault paths, make sure the vault is accessible from where your agents run.

​

Value

The actual credential data or vault path reference. All values are encrypted and only decrypted when needed. For a PAM account, you select its PAM system and enter its path. ⚠️ Important: Escape special characters properly to prevent authentication errors.

​

Agent Accessible

Controls whether agents can use this credential during tasks. Enable for:

• SSH configurations for remote execution
• API keys for CLI tools
• Database credentials for queries
• Any credential the agent needs to pass to commands

Disable for:

• Service credentials used only by 2501 infrastructure
• MCP server authentication tokens
• Backend service bearer tokens

​

Assigning Credentials to Agents

Open an agent and select its credentials directly in Host authentication. For a Host that uses a PAM session proxy, the form shows Session proxy instead of the authentication picker. See Privileged access. Save the changes, then choose Test connection to check access to the Host. Use the separate Agent Credentials section for credentials that the agent may reference by name during tasks. Choose Add available credential to extend this list.

​

Target Account and Permissions

2501 does not require a root user to operate on the target machine. Ensure the account used to connect has only the minimum permissions required for the agent’s tasks, regardless of the authentication method. Assign that account’s credentials when creating or editing the agent. When the host uses a PAM session proxy, assign only an SSH Username. The PAM system keeps the password or key of the account.

​

Credential Roles

Roles define how agents use credentials during execution. They cover remote access over SSH:

• SSH Username: Remote system login name
• SSH Password: Password-based SSH authentication
• SSH Private Key: Private key for key-based authentication
• SSH Public Key: Public key (rarely needed)

​

Common Use Cases

For SSH with a private key, select the login name under SSH user credential. Choose Private key under SSH authentication and select the key credential. For SSH with a password, select the login name under SSH user credential. Choose Password under SSH authentication and select the password credential.

​

Deleting a Credential

A credential that something still uses cannot be deleted — the error names what is using it, so you know what to detach first. That covers agents, jump hosts, gMSA configurations, satellite clusters, and the LLM providers that read their API key from it.

​

Windows Authentication with gMSA

Windows (WinRM) hosts can authenticate using a gMSA (group Managed Service Account) over Kerberos instead of a static Windows username and password. This avoids storing a long-lived Windows admin password. Manage these under Command Center → Credentials → gMSA Configurations. Administrators can create, edit, and delete configurations. Before adding a gMSA configuration, create a credential holding the password of the Active Directory service account that 2501 binds as. The configuration references that credential and captures the AD connection details:

• The gMSA account (its sAMAccountName, ending in $) and the AD realm
• The Domain Controller host and LDAPS port (default 636)
• The LDAP search base and the bind DN of the service account
• Optional KDC endpoints, and for domain controllers that use a private certificate authority, a PEM CA certificate for the LDAPS connection

One configuration can serve multiple Windows hosts that share the same gMSA, and a configuration that is still attached to hosts cannot be deleted. When a host uses gMSA authentication, 2501 reads the managed password from Active Directory over LDAPS and obtains a Kerberos ticket to authenticate to WinRM, bypassing the static password path.

​

Security Best Practices

Only mark credentials as “Agent Accessible” when necessary. Use organization-level scoping to limit exposure. Rotate credentials regularly and after any suspected compromise. For production systems, prefer PAM accounts or vault paths over direct values. Review which agents have access to sensitive credentials, and always document the credential’s purpose clearly.