| tip | 5 |
|---|---|
| title | ROFL‑based Decentralized TEE Execution of the Talos Agent |
| author | Jernej Kos <jernej@oasisprotocol.org> |
| status | Draft |
| type | Standards Track |
| created | 2025-08-01 |
Enable the Talos agent to execute its logic inside ROFL, the Oasis Runtime OFf‑chain Logic framework, so the agent gains secure and decentralized key management, auditable execution logs, on‑chain upgrade governance and a compute marketplace out of the box.
ROFL wraps container workloads in Intel TDX‑based trusted execution environments (TEEs) and uses Oasis Confidential EVM Sapphire to enforce policies and securely manage keys.
Talos aims to be the engine with humans as the steering wheel. For this, Talos’ execution needs to be verifiable and trustless. Agent’s private keys should not be in developer control. Currently the most practical solution is to derive key pairs from within a TEE. All agent actions like transaction execution for rebalancing, vault deployment, emissions and bond offerings should be signed autonomously from the TEE hosted agent. Otherwise you can not have any guarantees that it’s the agent logic and not some devs generating outputs.
ROFL offers unique features:
| Feature | Current flow | ROFL flow (after this TIP) |
|---|---|---|
| Key provisioning | Self-hosted keys, readable by the operator | On-chain KMS (keys escrowed & rotated on Oasis) with keys only released inside the TEE |
| Upgrade governance | Manual | On-chain policies with transparent change history |
| Invocation audit | App-level logs | On-chain log of every enclave run |
| Infra marketplace | N/A | On-chain ROFL marketplace to provision machines for executing the agent components |
These capabilities reduce operational overhead, harden the security model, and open new partnership opportunities for compute providers e.g. H100 clusters to run own models. Most importantly they align with Talos’ goal of verifiable AI inference.
The high-level proposal is to:
- Run the containerized Talos agent inside ROFL, with a locally persistent (and encrypted) SQL database.
- Replace the Talos key management service (e.g. the
talos.services.key_managementmodule) with the ROFL KMS. - Develop contracts to enable easy multisig/DAO governance of the ROFL app configuration.
- Develop GitHub actions workflows to build the ROFL app and submit it for approval by the multisig/DAO governance.
The existing Talos agent implementation already includes a Dockerfile which should be reused. To run the containerized Talos agent inside a TEE provided by ROFL an app manifest needs to be created that defines all artifacts that are part of the app and will have access to any secret key material. The Oasis CLI provides an easy way to perform this step given a previously containerized agent. To start, a suitable set of defaults (e.g. for resource requirements) will be used which can later be changed by governance as the agent evolves.
The agent requires the use of a persistent SQL database for accounting purposes. The initial version would have a single replica SQLite database which we can later scale to include replication between multiple ROFL replicas.
NOTE: Oasis Protocol Foundation will subsidize the ROSE costs for deploying the ROFL app and for maintaining ROFL infrastructure for the first 6 months.
We propose the existing talos.services.key_management module be refactored such that it supports
multiple implementations. The existing one seems suitable for a local development environment, but
not suitable for production as it exposes private keys in the local filesystem.
In addition to the existing local key management module a new ROFL KMS-based module would be added. Instead of directly generating keys, it would ask the ROFL KMS to derive the keys via an existing REST API which is available inside ROFL to attested apps. A simple Python client for this REST API is already available so it should require minimal effort to integrate into the Talos agent.
Each app running in ROFL is governed by an on-chain policy, with a specific account (the "admin account") having access to update the policy. The policy includes things like the cryptographic identity of the binary code that is allowed to access secrets and where the code must run (e.g. on which providers/nodes).
We propose developing simple contracts to make it easy to govern the Talos agent, e.g. via a Safe multisig or a DAO-like governance contract.
The proposed design requires minimal and incremental modifications to the existing Talos codebase and should be easy to implement and audit. ROFL provides all the necessary components out of the box and additional functionality can be added iteratively. Implementing this proposal would however already bring a lot of security benefits, namely access to cryptographic private keys would be possible only from code approved by governance running in an attested TEE.
Implementing this proposal should bring security benefits to the current design which relies on locally managed keys.
Consideration should be given to the governance mechanism which will allow updating the policy of the app as the policy defines which code has access to keys. Once in production, audits should be made before approving any release.
The implementation will be done in the existing Talos agent repository based on the proposed specification. A set of GitHub actions will be created which will facilitate automated builds of the Talos agent ROFL artifacts and handling the governance proposal workflow.
After governance approval, the new version will be pushed and deployed.