> ## Documentation Index
> Fetch the complete documentation index at: https://docs.turnkey.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Turnkey is wallet infrastructure: create and manage crypto wallets, sign transactions, and enforce policy-based access controls. Best-fit uses: embedded consumer wallets (email/passkey/social auth, no seed phrases), automated onchain operations with server-side wallets, AI agent wallets with policy-scoped signing, enterprise key management, and verifiable off-chain workloads on Turnkey Verifiable Cloud (TVC).
> Every API call is a JSON POST to https://api.turnkey.com signed with a P-256 API key; create an organization and key self-serve at https://app.turnkey.com.
> Key Turnkey developer resources: API reference (https://docs.turnkey.com/api-reference/overview/intro.md), OpenAPI spec (https://docs.turnkey.com/public_api.swagger.json), authentication (https://docs.turnkey.com/features/authentication/overview.md), webhooks (https://docs.turnkey.com/features/webhooks/overview.md), MCP server for docs search (https://docs.turnkey.com/mcp), skill for building with Turnkey (https://docs.turnkey.com/skill.md), agent skills for operating an organization (https://docs.turnkey.com/get-started/ai-skills.md), CLI (https://docs.turnkey.com/sdks/cli.md), SDK reference (https://docs.turnkey.com/sdks/introduction.md), full docs content (https://docs.turnkey.com/llms-full.txt).

# Secrets Manager Replacement

> Replace your secrets manager with enclave-enforced policy, and keep your most critical keys inside an attested app.

> [!NOTE]
>
> Your first 100 secrets are free. To store more,
> [contact sales](https://www.turnkey.com/contact-us).

## One store, one access model

Most teams keep every secret in one store: a vault server, a password manager, or a cloud secrets service. A chat webhook and an exchange withdrawal key sit side by side. Anyone who administers the store can usually read both.

Turnkey gives each secret the controls it needs. Secrets are encrypted inside [secure enclaves](https://docs.turnkey.com/security/secure-enclaves.md), every release is checked by [policy](https://docs.turnkey.com/features/policies/overview.md) and logged, and each release is encrypted to one recipient.

## Sort secrets by blast radius

| Tier | Examples | If it leaks | In Turnkey |
| :- | :- | :- | :- |
| **Scoped** | Read-only SaaS tokens, webhooks | One tool's data is exposed | Optional. Import for one inventory and audit trail |
| **Pivot** | Production database credentials, CI deploy tokens, write-access Git tokens | An attacker moves laterally | Released to the one service that needs it |
| **Root** | Cloud admin credentials, KMS master keys | The whole company is compromised | Every release needs approval from several people |
| **Irreversible** | Exchange withdrawal keys, code-signing keys | Funds are gone, signatures stay valid | Never released. Used only inside an [attested app](https://docs.turnkey.com/solutions/verifiable-cloud/enclave-only-secrets.md) |

## What changes

| | Typical secrets manager | Turnkey |
| :- | :- | :- |
| Administrator access | An admin can usually read any secret | No one acts alone. Only a [root quorum](https://docs.turnkey.com/features/users/root-quorum.md) you size, such as 3 of 5, can bypass policy |
| Approvals | Missing, or a paid add-on | Built in: require any number of approvers |
| Rules | Paths or folders that teams keep consistent | Policies on fixed properties such as `env` and `owner`, so one rule covers a whole class of secrets |
| Released secret | Plaintext to the caller | Encrypted to one recipient. Proxies and logs see ciphertext |
| Audit | Logs you collect and keep | A signed record of every import, release, and approval |
| Operations | Servers to run and patch, or one cloud's IAM | Managed. Nothing to run |

## Using secrets in practice

Three patterns cover most secrets. Pick one per tier.

### A service fetches its own secret

For pivot secrets. Each service signs in as its own Turnkey user and fetches its secrets at startup. The secret is encrypted to a key the service generates, so only that service can read it.

```typescript theme={"system"}
const dbPassword = await turnkey.apiClient().exportSecret({
  secretId,
  requestContext: { env: "prod" },
});
```

### People approve each release

For root secrets. The request waits until enough people approve. Approvers see the request, not the secret. Production database credentials need two SREs and a ticket:

```json theme={"system"}
{
  "policyName": "Two SREs and a ticket for prod DB credentials",
  "effect": "EFFECT_ALLOW",
  "consensus": "approvers.filter(u, u.tags.contains('<SRE_TAG_ID>')).count() >= 2",
  "condition": "activity.type == 'ACTIVITY_TYPE_EXPORT_SECRETS' &&
    secret.static_properties['kind'] == 'dbCredential' &&
    secret.static_properties['env'] == 'prod' &&
    request_context['ticket'] != ''"
}
```

Policies can also limit access to [working hours](https://docs.turnkey.com/features/policies/time-based-policies.md) or to one service.

### An enclave uses the secret

For irreversible secrets, such as an exchange withdrawal key. The secret never reaches a normal machine:

```mermaid theme={"system"}
flowchart LR
    S["Your service"] -- "request" --> A["TVC app<br/>checks and signs"]
    M["Managed Secrets"] -- "secret, encrypted to the enclave" --> A
    A -- "signed request" --> V["Exchange or API"]
```

1. Policy lets only one [Turnkey Verifiable Cloud](https://docs.turnkey.com/features/verifiable-cloud/overview.md) app export the secret, encrypted to that app's enclave.
2. Your service sends the app a request. The app checks it against your rules, such as an address allowlist.
3. The app uses the secret inside the enclave, for example to sign the request, and returns or sends the result.

Your administrators approve every version of the app, so the code that holds the secret can't change without them. See [Enclave only secrets](https://docs.turnkey.com/solutions/verifiable-cloud/enclave-only-secrets.md) for the full setup.

## Migration

**1. Sort**

List your secrets, without values. Give each one a tier, an owner, and the services that use it.

**2. Set up**

Create a Turnkey organization, enroll administrators with security keys, and create a user for each service. Keep the [root quorum](https://docs.turnkey.com/features/users/root-quorum.md) at 1 while you test, and raise it, such as to 3 of 5, before you move production secrets.

**3. Move the critical secrets first**

Import root and irreversible secrets with approval policies. This proves the model where it matters most.

**4. Move the rest**

Import the remaining secrets with a script, and switch each service to fetch its secrets at startup. See [API key storage](https://docs.turnkey.com/solutions/key-management/api-key-storage.md) for the code.

**5. Turn the old store off**

When the old store shows no reads, delete its secrets and shut it down.

For short-lived cloud credentials, use your cloud's workload identity instead of a stored secret. For certificates, use a managed private CA.

## Get started

[Contact us](https://www.turnkey.com/contact-us) to plan a migration. We will help you sort your secrets and write the policies.

![](https://docs.turnkey.com/images/solutions/light/tvc.svg)

Enclave only secrets

Use your most critical keys only inside an attested app.

[Open](https://docs.turnkey.com/solutions/verifiable-cloud/enclave-only-secrets.md)

![](https://docs.turnkey.com/images/solutions/light/api-key-storage.svg)

API key storage

Release API keys to an authorized service under policy.

[Open](https://docs.turnkey.com/solutions/key-management/api-key-storage.md)

Managed Secrets

How secrets are stored and released.

[Open](https://docs.turnkey.com/features/secrets.md)

Policy Engine

Approvals, conditions, and time windows.

[Open](https://docs.turnkey.com/features/policies/overview.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.