Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.gp.scale.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

Agents typically need credentials to function: API keys for LLM providers, database connection strings, authentication tokens for external services. SGP provides a two-layer system for handling these securely.
  1. SGP Cloud Secrets are account-level key-value pairs stored in your cloud provider’s secret manager. You create them once, and any agent in your account can reference them.
  2. Manifest credentials are per-agent mappings defined in manifest.yaml that bind an SGP Cloud Secret to an environment variable injected into the agent’s container at runtime.
You create secrets through the SGP dashboard or the Secrets API, then reference them by name in your agent’s manifest.yaml. At deploy time, SGP syncs the secret value into a Kubernetes secret and mounts it as the specified environment variable in the agent’s pod. Your agent code reads the environment variable as it would any other.

​
How secrets flow

The following diagram traces a secret from creation through to your running agent code. The value you provide when creating a secret is written directly to the cloud provider’s secret store (such as Azure Key Vault). It is never stored in the SGP database and is never returned by any API call. At deploy time, the deploy service reads the value from the cloud secret store, creates or updates a Kubernetes secret in the target namespace, and mounts it as the environment variable specified in your manifest.yaml.

​
Managing secrets in the UI

Navigate to Assets > Secrets in the SGP dashboard. The secrets table lists all SGP Cloud Secrets for your account.
Secrets table showing account-level secrets with key, description, created by, and modified columns
Each row displays:
  • Key: the unique identifier for the secret (for example, anthropic-api-key or redis-url-secret)
  • Description: an optional note explaining what the secret is used for
  • Created by: the user who created the secret
  • Modified: when the secret was last updated
From this table you can edit a secret (to update its value or description) or delete it.

​
Creating a secret

Click Create Secret at the top of the secrets table. Fill in the required fields in the dialog.
Create Secret dialog with key, value, and description fields
FieldRequiredDescription
KeyYesA unique name for the secret. Must be lowercase alphanumeric characters, hyphens, or dots, with a maximum length of 253 characters (Kubernetes naming rules).
ValueYesThe credential value. This is encrypted and stored in the cloud secret manager. It is never displayed again after creation.
DescriptionNoA human-readable note. Recommended so that other team members understand the secret’s purpose.
Click Create Secret to save. The new secret appears in the table immediately and is available for agents to reference.
Secret values are write-only. After creation, you can update the value but you cannot retrieve it. If you lose the original value, you must generate a new credential from the source system and update the secret.

​
Deleting a secret

Click the delete action on a secret’s row. A confirmation dialog requires you to type the secret’s key to proceed.
Delete confirmation dialog requiring the secret name to be typed for confirmation
Deleting a secret is irreversible. Any agent whose manifest.yaml references the deleted secret will fail on its next deployment because the secret can no longer be resolved. Verify that no agents depend on a secret before deleting it.

​
Secrets API

You can manage secrets programmatically through the SGP Cloud Secrets API. The following examples cover the most common operations.

​
Create a secret

curl -X POST "$SGP_CLIENT_BASE_URL/v5/sgp/secrets" \
  -H "x-api-key: $SGP_API_KEY" \
  -H "x-selected-account-id: $SGP_ACCOUNT_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "key": "datadog-api-key",
    "value": "dd-api-xxxxxxxxxxxxxxxxxxxxxxxxxx",
    "description": "Datadog API key for agent telemetry"
  }'
The response includes the secret’s id, key, description, and audit metadata. The value field is never returned. 
{
  "id": "sec_abc123",
  "key": "datadog-api-key",
  "description": "Datadog API key for agent telemetry",
  "cloud_secret_path": "/sgp/secrets/datadog-api-key",
  "created_by": "usr_def456",
  "created_at": "2026-05-20T14:30:00Z",
  "updated_by": "usr_def456",
  "updated_at": "2026-05-20T14:30:00Z",
  "object": "sgp_cloud_secret"
}

​
Update a secret

Use PATCH /v5/sgp/secrets/{secret_id} to rotate a value or update the description. 
curl -X PATCH "$SGP_CLIENT_BASE_URL/v5/sgp/secrets/sec_abc123" \
  -H "x-api-key: $SGP_API_KEY" \
  -H "x-selected-account-id: $SGP_ACCOUNT_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "value": "dd-api-yyyyyyyyyyyyyyyyyyyyyyyyyy",
    "description": "Datadog API key for agent telemetry (rotated May 2026)"
  }'

​
List secrets

curl "$SGP_CLIENT_BASE_URL/v5/sgp/secrets" \
  -H "x-api-key: $SGP_API_KEY" \
  -H "x-selected-account-id: $SGP_ACCOUNT_ID"
For the full API schema including pagination, filtering, and delete operations, see the SGP Cloud Secrets API reference.

​
Referencing secrets in manifest.yaml

Once a secret exists in the SGP secrets store, you reference it from your agent’s manifest.yaml in the agent.credentials array. Each entry maps an SGP Cloud Secret to an environment variable that your agent code can read. 
agent:
  credentials:
    - env_var_name: ANTHROPIC_API_KEY
      secret_name: anthropic-api-key
      secret_key: api-key
    - env_var_name: OPENAI_API_KEY
      secret_name: openai-api-key
      secret_key: api-key
    - env_var_name: DATABASE_URL
      secret_name: redis-url-secret
      secret_key: url
FieldDescription
env_var_nameThe environment variable name injected into the agent’s container. Your code reads this with os.environ["ANTHROPIC_API_KEY"] or equivalent.
secret_nameThe key of the SGP Cloud Secret as it appears in the secrets table. Must match exactly.
secret_keyThe sub-key within the Kubernetes secret object. This is typically api-key, token, or url, depending on how the secret was provisioned.
At deploy time, SGP resolves each secret_name to its corresponding cloud secret, syncs the value into a Kubernetes secret in the agent’s namespace, and mounts the value at the specified secret_key as the environment variable env_var_name in the pod.
The secret_key field refers to the key within the Kubernetes secret data map, not a secondary lookup within the cloud secret store. Each SGP Cloud Secret maps to one Kubernetes secret, and secret_key selects which data entry within that Kubernetes secret to mount.

​
Rotating a secret

To rotate a credential:
  1. Generate a new credential value from the source system (for example, your LLM provider’s dashboard or your database admin panel).
  2. Update the SGP Cloud Secret with the new value using the API (PATCH /v5/sgp/secrets/{secret_id}) or the Edit action in the secrets table UI.
  3. Redeploy any agents that reference the rotated secret. The next deployment picks up the new value automatically.
Existing running pods continue to use the previous value until they are replaced by a new deployment. Updating a secret does not trigger automatic redeployment. You must explicitly redeploy each affected agent.
To minimize downtime during rotation, update the secret value first, then redeploy agents one at a time. If the new credential is invalid, only the redeployed agent is affected, and you can roll back by redeploying the previous build.

​
Security model

SGP Cloud Secrets are designed around a write-only, least-privilege model:
  • Write-only values: secret values are never returned by any API call or displayed in the UI after creation. The SGP database stores only metadata (key, description, audit fields). The actual value lives exclusively in the cloud provider’s secret manager.
  • Encrypted at rest: values are stored using the cloud provider’s native encryption (for example, Azure Key Vault with platform-managed keys).
  • Injected as Kubernetes secrets: at deploy time, values are synced into Kubernetes secrets and mounted as environment variables. They are not written to disk or config maps in the cluster.
  • Role-based access: only users with secret management permissions can create, update, or delete secrets. Read access to secret metadata (key and description) is available to users who can view the account’s assets.
  • Audit trail: every create, update, and delete operation is recorded with the acting user and timestamp.

​
Next steps