DEV Community

Manav
Manav Subscriber

Posted on

Session Keys Aren’t Enough — Here’s How to Store Keys Without Holding Them

Decentralized key Management

If you’re building autonomous agents in Web3, DeFi bots, treasury managers, cross-chain yield optimizers, or AI-based market actors, you’ve probably hit the same problem:

Who actually holds the key?

Because here’s the thing: if your system depends on someone, somewhere, having root access to the private key, your “agent” isn’t autonomous. It’s just a puppet.

🔑 The Fragile State of Key Management in DeFi Agents

Most agent projects today - yes, even the popular ones either:

  • Don't explain how keys are generated/stored.
  • Rely on session keys or smart contract wallets with approvals.
  • Assume you’re running off-chain logic on centralized infra.

Let’s take that last one. Say your agent runs on a cloud box with sign() access. That’s not trustless. That’s just self-custody with a UI. Anyone with access to the box or the dev who set it up can nuke or hijack the wallet.

Session keys are slightly better. They let you scope permissions:

  • Only let the agent swap on Uniswap, up to a cap.
  • Only sign during a session window.

But even session keys:

  • Live in memory (vulnerable to malware).
  • Can be exfiltrated.
  • Need client-side approval flows to rotate securely.

🧠 What We Actually Want

We want:

  • Keys that live onchain.
  • Encrypted, shielded from all parties.
  • Usable by agents for signing and interaction.
  • Not directly accessible by anyone not devs, not node operators.

Oh, and we want agents to be upgradable, observable, and auditable without exposing internal logic or keys.

Hard ask? Not if you use a confidential execution layer.

🧱 The Stack: Sapphire + ROFL on Oasis

Here’s how you build a fully private, autonomous, key-secure agent using Oasis:

1. Use Sapphire a confidential EVM paratime, not a new L1

  • Supports Solidity, precompiles, and standard tooling.
  • Runs in Intel SGX TEEs.
  • All contract state can be private.
  • You can store secrets (like keys) inside encrypted memory using ConfidentialCell.

2. Use confidential_store() in your smart contract

This is how you store a private key inside the smart contract—but no one, including the developer or node operator, can ever extract it.

ConfidentialCell privateKeyCell;

function storeKey(bytes memory key) external {
    privateKeyCell.confidential_store(key);
}

function signMessage(bytes memory msg) external returns (bytes memory sig) {
    bytes memory key = privateKeyCell.confidential_load();
    sig = internalSign(key, msg);
}
Enter fullscreen mode Exit fullscreen mode

The key is never visible outside the enclave. It’s sealed at the hardware level and only usable within that secure boundary.

🔁 Now Let’s Talk About Agents

That covers the onchain logic. But what about agents that run off-chain logic?

Enter ROFL (Runtime Offchain Logic).

ROFL is:

  • A framework for offchain AI logic running in TEEs.
  • Integrated with Oasis.
  • Enclaves support key gen, key storage, encrypted memory.
  • Remote attestation ensures logic hasn't been tampered with.
  • All agent calls are logged onchain for transparency.
  • Agents can sign transactions via enclave-held keys, never exposed to the host OS.

That means you can:

  • Spin up an agent container that loads its key from secure enclave memory.
  • Make decisions using encrypted data (e.g. price feeds, strategy params).
  • Sign txs programmatically no human in the loop.

🕵️‍♂️ Why This Matters

Today’s so-called “autonomous agents” are usually:

  • Running on someone’s server.
  • Controlled by a dev team or multisig.
  • Using session keys with unclear expiry/rotation logic.

That’s not autonomy. That’s an API with extra steps.

With decentralized key management, you can:

  • Deploy agent code + keys into verified enclaves
  • Prove to users that no one controls the keys (via attestation)
  • Rotate keys on-chain without key exposure
  • Remove yourself from the trust boundary

🔧 What You Can Build

  • 🤖 Agent DAOs where agents hold and move funds based on encrypted rules.
  • 🧠 AI model runners where the LLM prompt and response logic is sealed, but the outputs are auditable.
  • 🎯 Auto-trading bots that rebalance or DCA across chains, holding and using their own keys.
  • 💼 Enterprise custody apps that give clients control without server-side access to keys.

📚 Tools to Get Started

🎬 Final Thought: Autonomy Requires Isolation

If your key is accessible, your agent isn’t autonomous. It’s a facade.

What Sapphire and ROFL give you is true cryptographic isolation:

  • No shell access to key material
  • No dev backdoors
  • No handwaving around “decentralized” agents

This doesn’t just solve for trust. It unlocks entirely new architectures for DeFi, agent coordination, and secure AI operations.

The primitives are here. The question now is:

Will we keep building agents with puppet strings, or ones that can actually think and sign for themselves?

Top comments (1)

Collapse
 
dc600 profile image
DC

The "key" to key management - decentralization with a dose of privacy. So simple and pragmatic. Step 1. Move to decentralized AI from a centralized system to build AI agents. Step 2. Use Sapphire + ROFL to get the best of on-chain confidentiality and off-chain verifiability. Result: The autonomy of the AI agent is secured and complete, making it truly trustless. This is why they say privacy is not by default but by design.