The goal is not to hide secrets better on the same machine. It is to ensure your application servers — including the worker that runs the language model and its tools — never possess exportable private key material or root API credentials.
That distinction matters for agent apps: the process is designed to read files, environment variables, and error output. Anything loaded into that process is one prompt-injection or debug step away from exposure.
This page compares architecture patterns that keep signing capability elsewhere: multi-party and threshold cryptography, cloud KMS and HSM-as-a-service, trusted execution environments, client- or device-bound keys, OAuth brokers that replace vendor API keys, and hosted agent vaults where keys have no read API. When you must custody a key yourself, see the companion custody guide linked below.
What "without server private keys" actually means
A private key on the server is any asymmetric secret or long-lived HMAC root that your Node, Python, or Go process can read as bytes — PEM in env, a file on disk, or a decrypted blob in memory after startup.
Architectures without server private keys still perform cryptography. They do it by calling a remote Sign operation, by holding only a share of a threshold key, by running code inside hardware that refuses export, or by using OAuth access tokens where no vendor root key exists on your side at all.
The agent runtime should hold capabilities: scoped tokens, session ids, or vault agent tokens — not the underlying signing material. Your API validates the agent, enforces policy, and asks the custody layer to sign or to attach a short-lived credential.
Architecture comparison at a glance
| Pattern | Key material location | Agent / app server holds | Best when |
|---|---|---|---|
| Cloud KMS / HSM-as-a-service | Provider HSM; IAM-gated Sign API | Key ARN + IAM role, not PEM | First-party JWT issuers on AWS/GCP/Azure; webhook HMAC in KMS |
| Hosted agent vault (sign-only API) | Vault operator HSM; no GET private key | vlt_live_… capability token | Agents need Ed25519/ECDSA/RSA/HMAC without running your own KMS |
| MPC / threshold signing | Shares across parties or devices | One share or API to co-sign | High-value chain keys; no single stolen file drains funds |
| TEE / enclave signing | Seal key inside enclave attestation | Attested session, not exportable blob | You control hardware or a confidential-compute SKU |
| Client- or device-bound key | Secure enclave on phone, TPM, passkey | Public key + challenge protocol | User-present actions; agent orchestrates, human approves |
| OAuth / Relay-only third-party APIs | Upstream issuer; refresh at broker | Short-lived access token | Gmail, GitHub, Slack — delegated user access, not your issuer key |
Multi-party computation and threshold signing
MPC splits a private key into shares so no single host ever reconstructs the full secret in RAM your app can dump:
t-of-n threshold
Signing requires t shares from n parties. Stealing one server file or one cloud VM does not produce a valid signature alone.
Agent as orchestrator, not custodian
The agent proposes a payload hash; co-signers or a MPC service return a partial signature. The agent never receives a PEM it can copy to `.env`.
Operational cost
Latency, key ceremony, and vendor choice dominate. Worth it when a leaked key is immediately monetary loss (on-chain treasury, high-value attestations).
Not a substitute for OAuth
MPC solves your signing key. It does not call Gmail; delegation still needs OAuth or a vendor-issued token.
Cloud KMS and HSM-as-a-service (app never sees key bytes)
Hyperscaler KMS and dedicated HSM clouds expose Sign, not ExportKey, when policy is set correctly:
AWS KMS, GCP Cloud KMS, Azure Key Vault (keys)
Create a key with usage SIGN_VERIFY only. The app server's role calls Sign with a digest; plaintext private key never enters application memory.
Dedicated HSMaaS (e.g. DigiCert, Thales cloud HSM offerings)
Same contract at higher assurance tiers — useful when auditors want FIPS boundaries you do not operate yourself.
Agent-specific wrinkle
Do not pass KMS credentials through the agent's tool context. A small signing microservice with a tight IAM role is the buffer; the agent calls your HTTP API.
Rotation
KMS supports aliases and scheduled rotation for symmetric keys; asymmetric keys rotate by creating a new key version and publishing JWKS — still without exporting the old private half to the app.
Trusted execution environments (TEE) and enclave signing
TEEs run code inside hardware-isolated memory with remote attestation:
What the app server gets
An attested quote and a session to request signatures inside the enclave — not a downloadable private key file.
Typical stacks
Intel SGX, AMD SEV-SNP, AWS Nitro Enclaves, Azure Confidential Computing, GCP Confidential VMs — pick based on where you already deploy.
Agent fit
Heavy to operate for a solo founder; makes sense when compliance or chain custody already mandates enclaves and you want the agent loop outside the enclave boundary.
Limit
If the enclave entrypoint accepts arbitrary payloads without policy, a compromised agent token can still abuse signing — policy stays in your API, not in "we used an enclave."
Client-held and device-bound keys
Some secrets should never enter your datacenter: passkeys, WebAuthn credentials, hardware wallets, and platform secure enclaves on phones keep private keys on the device.
The agent's role is to prepare a transaction or authorization request; the human approves with biometrics or a hardware button. The server verifies with the registered public key — it never possessed the private half.
This pattern does not scale to unattended midnight cron jobs unless you also introduce a delegated token or a threshold co-signer. It is the right boundary for high-impact actions (wire transfers, contract signatures) while still automating preparation.
OAuth-only and Relay: eliminate app-owned keys for third-party APIs
When the authority is Google, GitHub, Microsoft, or X, the correct architecture is often no private key on your server at all — only OAuth client credentials for your registered app plus short-lived access tokens after user or owner consent.
Empyre Relay at relay.empyre.dev (HTTP 200 on 2026-09-29) is OAuth for AI agents: hosted consent, mandatory S256 PKCE, one-time codes, refresh rotation, and fail-closed revoke. The npm package is @empyre/relay-sdk 1.0.0 on registry.npmjs.org as of the same date. Feature-frozen since 2026-07-10 for the public OAuth contract; security fixes only.
The agent receives scoped bearer tokens, not the user's password and not a vendor root API key pasted into chat. Your server stores refresh handling at the broker or exchanges codes server-side — still without giving the model a long-lived secret.
Relay does not replace a first-party JWT issuer or webhook HMAC secret — those are still your keys, which belong in KMS or a vault. For the build sequence, read let an AI agent authenticate with third-party APIs securely and agent OAuth token exchange.
Hosted agent vaults with no read path
A vault product optimized for agents exposes list-keys, sign, and verify — never export private key:
Payload in, signature out
Same contract as KMS Sign, but oriented to agent tokens and algorithms agents actually use (Ed25519, ECDSA P-256, RSA-2048, HMAC-SHA256).
Blast radius
A stolen agent token might sign until revocation, but the attacker cannot download a key that works offline on another machine forever.
Separation from the model loop
Run vault SDK calls from a hardened worker. The LLM proposes what to sign; code you control hashes and invokes the vault.
Empyre Vault
At vault.empyre.dev (HTTP 200 on 2026-09-29). Stored signing keys have no read path. SDK: @empyre/vault-sdk 1.0.0.
Choosing a pattern (decision cues)
| Your need | Prefer | Avoid |
|---|---|---|
| Call third-party SaaS as the user | OAuth broker (Relay or your IdP) | Storing the vendor's API key in env the agent reads |
| Mint first-party session JWTs | KMS or vault sign API | Generating RSA in the repo the CTO commits |
| Sign blockchain transactions | MPC / hardware wallet / custodian API | Hot wallet file on the app server |
| Verify inbound webhooks | HMAC secret in KMS or vault; constant-time compare in app | Same secret in agent memory for "convenience" |
| Founder approves high-risk action | Device-bound key + agent-prepared payload | Embedding the founder's PEM in the worker |
Vault SDK: server signs, agent never holds the key (1.0.0)
From `@empyre/vault-sdk` **1.0.0** (registry.npmjs.org on 2026-09-29). Keep this on a signing worker, not inside unconstrained agent tool code:
import { VaultAgent } from "@empyre/vault-sdk";
const vault = new VaultAgent({ token: process.env.VAULT_AGENT_TOKEN });
const { id: keyId } = (await vault.signingKeys.list())[0];
const digest = JSON.stringify({ agent: "cmo", action: "post-draft", ts: Date.now() });
const { signature, public_key, algorithm } = await vault.sign(keyId, digest, "utf8");
// Verify anywhere with public_key — private material never returnedHow this differs from custody on your servers
Post 26 — how to store private keys for an AI agent app — covers where keys must live when you do custody them: KMS namespaces, anti-patterns in repos and prompts, algorithms, and signing-without-export as a custody discipline. This page compares ways to avoid loading those bytes onto your app tier in the first place.
Exposure mechanics (prompts, logs, commits) are in how AI agents leak API keys. Broader hygiene: secret management for AI agents.
Empyre the company builder runs eight fixed agent roles that ship and operate a business after launch, with a thirty-minute first-deploy ceiling when code is the bottleneck. Generated products still need the same secret architecture for webhooks and auth the CTO adds — Vault and Relay are sibling products on the same account, not substitutes for operating the company.
Common questions
Is KMS enough, or do I need a dedicated agent vault?
KMS is enough if you already run on one cloud, IAM is tight, and your agents call a small signing API you own. A vault product helps when you want agent-scoped tokens, multiple algorithms, and no ExportKey path without operating KMS yourself.
Does MPC mean my server has zero secrets?
Your server may still hold one MPC share or API credentials to the MPC service — smaller blast radius than a full key, but not zero trust. Combine with policy on what payloads may be signed.
Can Relay replace Vault?
No. Relay issues and refreshes OAuth access to third-party APIs. Vault signs with keys you own (JWT, HMAC, attestations). Many stacks use both.
What if I still put keys in env for local dev?
Treat local dev like production for agent projects: the same tools that read env in dev will be suggested in prod fixes. Use separate dev keys and a sign API even locally.
What was verified on 2026-09-29?
`vault.empyre.dev` and `relay.empyre.dev` returned HTTP 200 via curl -sI. `@empyre/vault-sdk` and `@empyre/relay-sdk` were 1.0.0 on registry.npmjs.org.
How is this article different from post 26?
Post 26 is custody when you hold signing material. This page is architectural comparison for keeping that material off your application servers — MPC, KMS, TEE, device keys, OAuth-only, and sign-only vaults.
Try Empyre free for 3 days
Describe a business in plain words and watch eight AI agents build and deploy it. Starter is free for the first 3 days.
Related
Last updated 2026-09-29. Competitor descriptions reflect each product's publicly documented capabilities at that date; they change often, so check the source before relying on a detail.