Turnkey Launches Managed Secrets for AI Agent Credential Access

Turnkey has launched Managed Secrets, extending its enclave-based wallet infrastructure to the API keys, passwords, payment details and recovery material that applications and AI agents need to operate. The October 29 announcement moves the company beyond private-key management into a broader problem: giving software authority to act without scattering reusable credentials across its infrastructure.

The product lets teams decide which service can retrieve a credential and whether that request needs human or multi-party approval. For financial applications, that could mean releasing an exchange API key to an authorized trading backend while keeping it out of an AI assistant’s conversation and execution environment.

Moving Credential Access Behind an Enclave Boundary

Credentials stored in environment variables or configuration files are convenient for software to use, but a compromise of the process that reads them can expose their contents. A vault can centralize storage and access controls; the remaining question is where a credential becomes readable and which systems must be trusted at that point.

Managed Secrets places its authorization checks inside Turnkey’s secure enclaves. A client encrypts a secret before importing it, and the enclave re-encrypts it for storage. When a request arrives, the enclave evaluates the relevant policies and approvals before encrypting the result to the intended recipient’s key. The requester and recipient can be different services.

That separation matters. An application can initiate work and collect approvals without acquiring the ability to decrypt the credential used to complete it. An approver’s signature authorizes release; it does not automatically grant access to the released secret.

The Cryptography Behind Import and Export

Turnkey’s secure-channel documentation describes a protocol based on Hybrid Public Key Encryption, or HPKE. It combines public-key key agreement with authenticated encryption so sensitive material can travel through intermediary systems as ciphertext. The client verifies enclave-signed key material during import, while export encrypts to a public key supplied in the signed request.

Recipient keys are intended for single use. Turnkey notes that clients must follow that rule themselves: the protocol cannot prevent a faulty client from reusing its target key. This makes client implementation part of the security model, alongside the enclave.

The Managed Secrets product page specifies per-secret AES-256-GCM encryption at rest. Its API supports both individual credentials and requests for multiple secrets. Batch exports fail as a unit if any requested secret lacks authorization, preventing a partially approved bundle from being released.

Why the Recipient Still Matters

The phrase “agents can use credentials without seeing them” describes an integration pattern, rather than a guarantee that every receiving process remains unable to read plaintext. Turnkey’s developer documentation explicitly states that plaintext can exist inside the enclave and on the client importing or exporting a secret.

If a separate execution service holds the recipient key, it can decrypt and use a credential while keeping it away from the model. If the agent’s own runtime holds that key, that runtime can decrypt it. Protecting the recipient, its memory and its logs therefore remains necessary.

There is a second boundary: policies can inspect request context, such as a claimed checkout domain, but Turnkey does not independently verify that the claim is true. A signed claim establishes who asserted it. Applications still need trustworthy checks connecting that assertion to the actual operation.

Approvals That Can Evolve With a Workflow

Teams can allow direct retrieval, require a person to approve a request, or require agreement between multiple agent roles. Policies can change without re-importing the underlying secret, allowing a workflow to begin with close supervision and later automate selected requests.

Turnkey’s programmable access guide illustrates a browser agent and a payment agent co-signing a request. Only the payment agent receives decryptable card details. Before approving, the browser component checks that the proposed domain matches the page it is using. The example shows why independent roles and validation matter more than merely counting two approvals.

Agent roles can use scoped, expiring session credentials, giving operators a way to revoke one running instance. Revoking future access, however, cannot erase a secret already decrypted by a recipient; downstream credential rotation remains a separate operational control.

From Wallet Infrastructure to Financial Automation

Turnkey’s existing security architecture uses AWS Nitro Enclaves and combines hardware isolation with reproducible builds and remote attestation. Reproducibility lets software builds be compared, while attestation provides evidence about the enclave code running. Managed Secrets brings that foundation to credentials beyond blockchain signing keys.

The company identifies trading firms, fintech backends, AI-agent developers and MPC custodians as intended users. Exchange credentials and OAuth tokens support ongoing service access; keyshare backups and recovery keys address resilience. These are distinct uses with different approval and recipient requirements, even when they share storage infrastructure.

For financial technology teams, the significance is a more explicit division between requesting an action, authorizing access and receiving a usable credential. Managed Secrets provides infrastructure for that division. The resulting protection depends on narrow policies, reliable approvers and a well-protected service that ultimately uses the secret.