Confidential Compute for Strategy IP: Protecting Your Alpha Inside an Enclave

The alpha is the asset. Everything else - the execution infrastructure, the data pipeline, the risk system - is commodity. A fund with a genuine edge will eventually rebuild on better infrastructure. A fund with better infrastructure but no edge is a technology consultancy masquerading as a fund.

Given this, it is remarkable how poorly most firms protect their alpha. I have audited infrastructure at firms that stored strategy parameters in plaintext environment variables on EC2 instances. I have seen backtesting code checked into GitHub repositories with private visibility that was shared with developers who later left the firm. I have seen production strategy code running on managed Kubernetes clusters where the provider’s support team has debugging access. In each case, the firms believed their code was protected because it was not publicly visible. Obscurity is not protection.

ZeroCopy is building the infrastructure where you can run your strategy inside a TEE and prove to institutional partners that it is running as described - without revealing the code. This post is the technical brief for how that works.

The Actual Threat Model

Let me be specific about what we are protecting against, because “protect the strategy” means different things at different threat levels.

Level 1: External attacker who compromises your AWS account. Your EC2 instances are accessible to anyone with account-level access. A phished credential, a leaked access key, a misconfigured IAM role - any of these gives an attacker the ability to describe and terminate your instances, access CloudWatch logs that contain strategy outputs, and potentially attach SSM Session Manager to a running instance for remote shell access. This level of attacker can read environment variables, memory-map running processes, and copy your code out of the container.

Level 2: Your cloud provider. AWS employees with the appropriate access level can access EC2 instance memory. This is documented behavior, not speculation - it is why AWS built Nitro Enclaves. The threat from the cloud provider is low-probability but high-consequence. A rogue employee with EC2 access at a major cloud provider could extract strategy code from hundreds of firms simultaneously. This threat received new attention after the 2024 Microsoft/Midnight Blizzard incident, where a cloud provider employee’s credentials were used to access customer data.

Level 3: Your own employees. The insider threat is statistically the highest probability threat for most firms. Former employees who built the strategy retain mental models of the approach. Current employees with production access can exfiltrate code before departing. The security posture of a trading firm where any developer with prod access can read strategy parameters is fundamentally different from one where the parameters are sealed inside hardware.

Level 4: Regulatory or counterparty verification. This is a different threat direction - not “how do I prevent my strategy from being stolen” but “how do I prove to an LP or regulator that my strategy is what I claimed, without giving them the code.” This is the use case where confidential compute provides a capability that no other technology offers.

Standard approaches address Level 1 (good IAM hygiene), partially address Level 3 (code signing, git audit logs), and do nothing for Levels 2 and 4. TEEs address all four.

What Confidential Compute Provides for Strategy

When your strategy runs inside a Nitro Enclave (or SGX or SEV-SNP), several properties hold simultaneously:

Memory isolation. The enclave’s RAM is encrypted by the CPU. An attacker with root access on the host EC2 instance can enumerate the enclave’s vsock connections and see bytes flowing in and out, but cannot read the strategy code, the parameters, or any intermediate state. Even attaching a JTAG debugger to the physical host does not help - the CPU’s AES engine encrypts memory with an ephemeral key that is destroyed on power-off.

Code measurement. Before the enclave unseals its keys or accepts any inputs, it has been measured. PCR0 in Nitro, MRENCLAVE in SGX, and the Guest Measurement in SEV-SNP are all deterministic functions of the code inside the enclave. If you build the same container image twice from the same source, you get the same measurement. If anyone modifies the enclave image - even adding a single byte to enable debugging - the measurement changes and the sealed keys do not decrypt.

Attestation documents. The enclave can produce a signed attestation document at any time. This document includes the PCR values (or MRENCLAVE), is signed by a certificate chain rooted in hardware (AWS Nitro CA, Intel, or AMD), and contains a nonce you provide. The nonce prevents replay: an attestation document produced with nonce N cannot be presented as evidence that the enclave is running today if it was generated last month. This is the primitive that enables third-party verification without code disclosure.

The Implementation Challenge: Data Flow Through vsock

The security model comes with an architectural constraint that is non-trivial to work around: a Nitro Enclave has no network interface. It cannot call external APIs, subscribe to market data feeds, or make database queries. Every byte of external data must flow through the vsock channel connecting the enclave to the parent instance.

For a signing application where the enclave receives a payload, signs it, and returns the signature, vsock is fine. The interface is narrow and the round-trip overhead is small.

For a live trading strategy, the interface requirements are completely different. The strategy needs:

• Real-time market data (order book updates, trades)
• Historical OHLCV data for feature computation
• Position state from the portfolio management system
• Risk limit state from the risk engine
• Current time for scheduling

And it produces:

• Order decisions with quantities and prices
• Risk signals for the risk engine
• Audit log entries for compliance

All of this must flow through vsock. Every vsock read is a syscall from the enclave’s perspective, and each syscall has overhead. In our benchmarks, a simple request-response over vsock takes 80-120µs. A strategy that needs to react to order book updates arriving at 50,000 events/second with 20µs of latency budget cannot pay 80µs per vsock call.

The practical solution is to batch and buffer. Market data is streamed into the enclave at a configurable rate and buffered in-enclave. The strategy processes the buffered data and produces decisions, which are batched and sent back over vsock. The tradeoff is that the strategy’s access to market data has bounded freshness - it cannot see a tick that arrived 5µs ago; it can only see ticks up to the last batch boundary.

For strategies with sub-millisecond latency requirements, this model does not work. Confidential compute for HFT execution is an unsolved engineering problem. For strategies with latency requirements in the millisecond-to-minute range - most systematic funds, including the strategies ZeroCopy was built to serve - buffered vsock data is entirely workable.

The Attestation-as-Proof-of-Strategy Model

This is the capability that changes the institutional LP relationship in ways that are not possible with any other technology.

The standard LP due diligence process for a systematic trading strategy involves some combination of: reviewing the strategy pseudocode (revealing the approach), reviewing historical backtest results (gameable), live observation during a trial period (survivorship bias), and trusting the manager’s track record (circular).

The question the LP actually wants to answer is: “Is the strategy I was shown in the pitch deck the strategy that is running in production?” There is currently no good answer to this question. The manager could be running the pitched strategy in production or could be running something completely different and presenting cherry-picked results. Third-party audit of live systems exists but is expensive, lagged, and relies on access to the production environment.

Confidential compute makes this question answerable cryptographically.

The workflow:

Step 1: Deterministic build. The strategy is compiled from source into an enclave image using a reproducible build process. Given the same source code, the build produces the exact same binary with the same hash. This is standard in security-critical software but requires explicit attention to timestamps, compiler flags, and dependency pinning.

Step 2: Measurement commitment. The enclave image’s PCR0 (or MRENCLAVE) is computed from the built binary and published to the LP as the strategy’s cryptographic identifier. “The strategy you were shown has identifier PCR0 = 0xABCD…” The LP does not get the code; they get a commitment to the code’s exact binary representation.

Step 3: Live attestation. At any point, the LP can request a live attestation document from the enclave, providing a fresh nonce. The enclave produces an attestation document signed by AWS Nitro CA, containing the current PCR0 value and the nonce. The LP can verify: the document was produced by real AWS Nitro hardware (cert chain), the document was produced recently (nonce is the one they provided), and the enclave running is the one they committed to (PCR0 matches).

Step 4: Input/output log. The enclave’s vsock proxy logs all data flowing in and out of the enclave: market data inputs and order decisions. These logs are append-only and signed by the enclave’s ephemeral key (verifiable via the attestation document’s ephemeral key field). An auditor can verify that specific orders were produced by the specific enclave given specific inputs, without access to the strategy code.

The LP never sees the strategy. They can verify cryptographically that the strategy running today is the same as the one they evaluated. The audit trail is complete without being revealing.

Regulatory Context

The SEC’s electronic recordkeeping rules (Rule 17a-4 for broker-dealers) require that records be stored in a non-rewriteable, non-erasable format. The enclave input/output log, signed by the enclave’s ephemeral key and anchored to an attestation document, is a strong candidate for satisfying this requirement in a cryptographically verifiable way. I am not a lawyer and this is not legal advice, but the technical properties are aligned with what regulators are asking for.

In MiFID II’s algorithmic trading requirements (RTS 6, Article 17), firms are required to maintain “algorithms and mechanisms used to assess the risk of trading positions.” The attestation model provides an immutable record of exactly which algorithm was running, in a form that can be verified without granting the regulator access to the strategy code.

Structuring a Confidential Strategy Execution Framework

Here is the architecture we use at ZeroCopy for strategies that require the highest level of IP protection.

The enclave boundary is drawn at the alpha generation layer - the code that takes market data inputs and produces trading signals. The execution layer (order routing, risk checks, position management) runs outside the enclave, not because it is unimportant, but because it does not contain the proprietary signal generation logic.

┌─────────────────────────────────────────────────────┐
│                   EC2 Host Instance                  │
│                                                      │
│  ┌──────────────────┐    vsock    ┌───────────────┐  │
│  │  Market Data     │───────────→│               │  │
│  │  Proxy           │←───────────│  Signal       │  │
│  └──────────────────┘  Signals   │  Generation   │  │
│                                  │  Enclave      │  │
│  ┌──────────────────┐            │  (PCR0-sealed)│  │
│  │  Input/Output    │←── log ────│               │  │
│  │  Audit Logger    │            └───────────────┘  │
│  └──────────────────┘                               │
│           │                                          │
│  ┌────────▼─────────┐                               │
│  │  Execution Layer │                               │
│  │  (risk, routing, │                               │
│  │   position mgmt) │                               │
│  └──────────────────┘                               │
└─────────────────────────────────────────────────────┘

The signal generation enclave receives market data batches from the market data proxy, computes signals using the sealed strategy code, and returns trading signals. It also produces a running signature over all inputs and outputs using an ephemeral ECDSA key whose public key is included in the attestation document.

The input/output audit logger appends every input batch and output signal to an append-only log, with the enclave’s signature over each entry. This log is the audit artifact.

The execution layer translates signals to orders, applies position-level risk limits, and routes to exchanges. It does not know the strategy’s logic - it only knows that signal X means “buy Y quantity with Z risk parameters.” The strategy logic remains sealed.

The market data proxy serializes incoming data into a defined wire format, strips anything not needed by the strategy (reducing the risk of inadvertent information leakage through batch timing), and forwards to the enclave.

What This Looks Like for an Institutional LP

From the LP’s perspective, the interaction is:

1. During due diligence, they receive the strategy’s PCR0 commitment along with a technical document describing the enclave architecture.
2. Monthly (or on-demand), they can request an attestation verification report: they provide a nonce, receive the attestation document, verify it against AWS Nitro’s certificate authority (public, available from AWS), and confirm the PCR0 matches.
3. If they want to verify a specific set of trades, they receive the signed input/output log segments covering those trades, with the enclave signature verifiable against the ephemeral public key in the attestation document.

No proprietary code is disclosed. No access to the production environment is granted. The LP has cryptographic proof that the strategy running today is the same strategy they evaluated, and that the trade log is an authentic output of that strategy.

This is the model that makes raising from institutional LPs tractable for smaller funds that cannot afford the traditional route of hiring an independent administrator with full access to production systems. The confidential compute approach produces verifiable evidence at lower cost to both parties.

The Forward View

We are early. The tooling for confidential strategy execution is not mature. Building a reproducible enclave image pipeline requires engineering discipline that most trading firms are not applying today. The vsock data flow architecture requires careful design. The attestation document verification workflow is not yet automated in most LP due diligence processes.

But the pressures are building. Institutional capital increasingly requires programmatic verifiability of operational claims. Regulators are moving toward electronic audit requirements that push in the direction of cryptographic proofs. The Bybit hack, the Ronin bridge, the FTX collapse - each incident adds to the institutional case that “trust the operator” is insufficient and cryptographic verification is the floor.

The funds that will capture institutional capital in the next five years are those that can answer “how do I know your strategy is what you said” with a cryptographic proof rather than a word of honor.

In the next post: how ZeroCopy’s AI agents operate within this infrastructure - what Letta-based trading workflow agents actually look like in production, what guardrails keep them from doing anything catastrophic, and where AI adds value versus where deterministic code is still the right tool.