Skip to main content
The Komodor Agentic Operation Platform (KAOP) stores credentials separately from agent code and configuration. A credential is encrypted at rest, its value is write-only in management surfaces, and a binding determines which agent may receive it. Manage them from Credentials.

​
Credential model

A credential has a stable name and one of two shapes: Credential reads return metadata such as the name, description, owner, status, labels, key names, and usage information. They do not return the stored value. Replacing the value creates the next active version while preserving the name and bindings.

​
Create a credential

1

Choose New credential

Select a single value or multiple keys. For multiple keys, enter rows directly, paste JSON, or upload a .json or .env file.
2

Use a stable name

Credential names cannot be changed after creation. Choose the name your agent code and integrations should continue using through future rotations.
3

Add ownership metadata

Add a description, owner, and labels so administrators can identify the credential and apply scoped access controls.
4

Bind agents

Select the agents allowed to receive the credential, or create it unbound and grant access later.
If the account already stores the same value, KAOP reuses the existing credential instead of creating another copy. The create flow identifies the credential that was reused.

​
Bind only the agents that need it

A credential is not delivered to an agent until a binding authorizes it. You can manage bindings from the credential’s access view or from an agent’s permissions and secrets view.
For a multi-key credential, restrict a binding to selected keys when the agent does not need the whole set. A binding without key restrictions delivers every key.
Removing a binding prevents future authorized delivery. It does not erase a value already held by a running process, so revoke the value at its provider when exposure is possible.

​
Read a run-scoped credential in Python

Use the SDK accessors inside the run handler:
For multi-key credentials, environment-variable names use CREDENTIAL_NAME__KEY. Names are normalized to uppercase with unsupported characters replaced by underscores; for example, google-workspace-oauth and client_id become GOOGLE_WORKSPACE_OAUTH__CLIENT_ID. Read run-scoped values inside the handler rather than at module import time.

​
Masking and its limits

The SDK masks exact occurrences of delivered credential values from run output, events, diagnostics, and saved state before reporting them. A value that has been encoded, split, hashed, truncated, or otherwise transformed may no longer match and may not be masked.
Do not deliberately send credentials to models, tools, logs, knowledge bases, instructions, or skills. Treat automatic masking as protection against accidental echoes, not as a substitute for least privilege and safe agent code.
See Data handling & redaction for the boundary between credential masking, configurable guardrails, and custom network traffic.

​
Replace, disable, and delete

Before deletion, KAOP checks consumers such as agents, integrations, and MCP servers. Static header references must be removed before deletion. For dependent MCP servers, the deletion flow lets you choose whether to remove them or leave them configured without the credential. Platform-managed credentials may also appear in the list. They support managed KAOP services and cannot be replaced or deleted from the customer credential workflow.

​
Next steps

Built-in integrations

Connect services that use stored credentials.

MCP Gateway

Inject a credential into calls to an MCP server.

Secrets & credential handling

Review the credential security architecture.