Secrets Manager overview

Crusoe AI Platform Secrets Manager provides secure, encrypted storage for sensitive credentials like API keys, database connection strings, and certificates. It prevents hardcoded secrets from entering source code, repositories, container images, or shell logs.

Security architecture

Secrets Manager stores credentials in a dedicated, hardened Secret Store:

• Encryption at Rest: All secret values are encrypted at rest using AES-256 encryption.
• Immutable Versioning: Every update appends a new numbered version (e.g., version 1, version 2). Existing versions are retained unless explicitly deleted.
• Write-Only API Design: Standard metadata calls (list, show, versions) report version counts, names, and binding references—never secret values.
• Audited Break-Glass Reveals: The explicit :reveal API is restricted to project administrators and logs identity, timestamp, and justification directly to the project audit trail.

Delivery mechanisms

Workloads access secret values through two primary patterns:

1. Environment Variable Bindings (Recommended): Bind a secret to an environment variable name (e.g., openai-api-key → OPENAI_API_KEY). Applying the binding delivers the value directly into the workload environment upon revision roll or deployment.
2. Runtime SDK Reads: Fetch credentials dynamically at application execution using the platform SDK (secret("openai-api-key")). Short-lived, read-only tokens access the secret directly without storing values in environment variables.

What this store is not

Not every credential on the platform lives here. An object-store trigger reads its S3 credentials from a credentials Secret held in your project, carrying the exact keys aws.accessKey and aws.secretKey — the two field names the upstream S3 source reads. A Secrets Manager name typed into a trigger's credentials secret field resolves to nothing; a trigger resolves that name only inside its own project by design, so there is no field that could point at a Secret belonging to anything else.

A project connected to Crusoe Cloud already has that Secret, named crusoe-object-store, minted for it. That is the name to put in the trigger.

It has to be minted because a Crusoe Cloud API key is not an S3 key: object storage answers one with 403 The AWS access key Id you provided does not exist in our records. The platform mints a real S3 key from the project's Crusoe Cloud connection and stores it under that name. See Object store triggers.

Delivery path comparison

Pattern	Best Used For	Security & Audit Behavior
Project Secret + Environment Binding	Standard workload environment variables, shared platform keys.	Value injected during deployment/revision creation. Value reads audited during apply.
Runtime SDK Read (secret())	Dynamic secret fetching, high-frequency rotation, short-lived workloads.	Short-lived token generated per request. Direct store retrieval with immediate expiration.
Direct Agent Variable (secrets set)	Single-agent testing or temporary local overrides.	Direct variable assignment without versioning history.

Feature comparison

Capability	Crusoe AI Platform	AWS Secrets Manager	GCP Secret Manager	Azure Key Vault
Encryption	Dedicated AES-256 Vault	AWS KMS	Cloud KMS	Azure Key Vault
Versioning	Immutable sequential versions	Version IDs & Staging Labels	Sequential Versions	Version IDs
Audit Trail	Integrated Project Audit Log	AWS CloudTrail	GCP Cloud Audit Logs	Azure Monitor
Binding Injections	Native Workload Bindings	IAM + App Config	IAM + Secret Mounts	Managed Identity + Mounts

Next steps

• Manage secrets — Create, inspect, rotate, reveal, and delete secrets.
• Use secrets in workloads — Configure bindings, apply updates, and run call-time reads.
• Data protection — Deep dive into platform encryption and compliance.