Averon Private/Technical brief
Technical brief
How the system is built, what the guarantee actually covers, and which parts of it you can check today.
This document describes a system that is being built. It is not a report on a system that has been audited. Where a claim depends on something we have not yet published, the text says so and section 07 lists the current status. If you find a statement here that is stronger than the evidence behind it, that is a defect and we want to hear about it.
private.averon.systems is a static marketing site on an ordinary server, with ordinary TLS terminated by nginx. It is not the product, it runs no enclave, and it makes no attestation claims about itself. Everything below concerns the inference service.
01 Scope
What this defends against.
A guarantee is only meaningful against a stated adversary. Here is the one we designed for, and the ones we did not.
In the threat model
- Averon staff. Engineers with production access, including anyone with root on the host. There is no operator path to plaintext, and no internal process that can be granted one without changing the measured image.
- The hypervisor and host OS. Memory belonging to the enclave is encrypted with a key the host does not hold. A compromised host can stop the service. It cannot read it.
- The infrastructure provider. Same position as the host. Physical access to the machine does not confer read access to enclave memory.
- Legal compulsion directed at us. We cannot produce plaintext we have no key for. A compelled change to the software is addressed in section 06.
- An attacker who reaches our network. The same boundary that excludes us excludes them.
Not in the threat model
- Your own endpoint. If the device you type on is compromised, nothing on our side helps.
- Your account credentials. If someone else can authenticate as you, they can read your sealed history.
- What you do with the output. We have no view into it and no control over it.
- Traffic analysis by a network observer who can see that you connected, and when.
- A flaw in the silicon vendor's attestation chain. See section 06.
02 Request path
Where your text exists, and in what form.
The design goal is that ciphertext crosses every boundary we control, and plaintext exists only inside a boundary we cannot enter.
- 01 Client establishes the enclave's identity Before any request data leaves your machine, the client obtains and validates a hardware attestation report. Details in section 03. If validation fails, the client closes the connection rather than warning you.
- 02 TLS terminates inside the enclave, not at the edge The server certificate's private key is generated inside the enclave and never leaves it. There is no load balancer, reverse proxy, WAF, or TLS offload device holding your plaintext on the way in. The network path in front of the enclave carries ciphertext only, and can be operated by people with no ability to read it.
- 03 Plaintext exists in enclave memory during inference This is the part that cannot be designed away. The model processes your text, so your text is in memory in the clear. Enclave memory is encrypted against the host, so "in the clear" means readable by the measured code and by nothing else.
- 04 The accelerator is inside the boundary too Frontier inference runs on GPUs, so a CPU-only enclave would move the problem rather than solve it. The GPUs run in confidential computing mode, attested alongside the CPU enclave, with the CPU to GPU transfers encrypted. A design that attests the CPU and quietly hands plaintext to an unattested accelerator is not a private system, and it is worth asking any vendor in this space exactly that question.
- 05 The response returns over the same channel Encrypted inside the enclave, decrypted on your device. Nothing in between holds a key.
- 06 Working memory is discarded Prompt, intermediate state and response are released when the request completes. Nothing is written outside the enclave unless you enabled sealed history, in which case what is written is ciphertext. See section 05.
03 Attestation
What gets measured, and what your client does with it.
Attestation is the whole product. Everything else is a claim; this is the part that makes the claim checkable from your side.
What the report covers
- The launch measurement. A hash over the initial memory image of the enclave: firmware, kernel, initrd, root filesystem and the inference server itself. Change any byte and the measurement changes.
- The launch policy. Debug disabled, migration disabled, and the other flags that would otherwise permit inspection of a running enclave. A permissive policy makes the measurement meaningless, so the client checks the policy too.
- The signing chain. The report is signed by a key rooted in the silicon vendor's certificate authority, so a software-only impersonation cannot produce a valid one.
- The accelerator. A separate attestation covering the GPUs in confidential computing mode, bound to the same session.
What the client does
- A Validate the chain Walk the signature chain to the vendor root, check revocation, and confirm the firmware version is not one with known attestation defects.
- B Compare against a published reference The measurement must equal the value published for a specific release, which is reproducible from public source. Independent rebuilds are listed next to it so you are not taking our word for the mapping between source and hash.
- C Bind the key to the measurement Covered in section 04.
- D Fail closed Any failure at any step is a closed connection. There is no override, no "continue anyway", and no soft warning, because a warning users can click through is not a security control.
Verification performed by software we control and you cannot inspect is not verification. The attestation client is intended to be open source under a permissive licence, buildable by you, and usable against a build compiled by someone with no relationship to Averon. If you only ever run our binary, you have moved your trust rather than reduced it.
04 Key handling
Keys that only exist in one place.
The measurement is only useful if the keys are tied to it. Otherwise a different image could pick up where the attested one left off.
- The TLS key is generated inside the enclave. It is created at startup, exists only in enclave memory, and is never exported, escrowed or backed up. There is no copy for us to hand over.
- The session key is bound to the measurement. Key agreement is tied to the attestation report, so the key your client derives is usable only by the exact image that was measured. A different image cannot derive it. That includes a later image signed by us.
- Sealing keys are derived from the measurement. Data sealed by one image cannot be unsealed by another. This is what makes sealed history unreadable to us: producing a build that could open it would produce a different measurement, which your client would refuse before you ever spoke to it.
- There is no recovery path. Losing your credential means losing access to sealed history permanently. We are aware this is worse for usability. A recovery mechanism we operate would be an access mechanism we operate, and the whole point is that we do not have one.
05 Storage
What is written down, and who can read it.
Some data has to exist outside the enclave for the business to function. Naming it precisely is more useful than implying that everything is sealed.
| Data | Location | Readable by Averon | Notes |
|---|---|---|---|
| Prompts and responses | enclave memory | no | Discarded when the request completes. |
| Conversation history | sealed at rest | no | Opt in, off by default. We hold ciphertext we can replicate, back up and delete, but not open. |
| Incognito sessions | not written | n/a | No history record, title, summary or cache entry outlives the session. |
| Email address | outside | yes | Account identity. Ordinary business data under ordinary protection. |
| Payment reference | processor | partial | Held by the payment processor. We see a token and a status, not card details. |
| Usage counters | outside | yes | Request counts and token totals for billing. Never content. |
| IP addresses | not retained | n/a | Connections terminate. Addresses are not written to a log or a record. |
| Model training data | none | n/a | Nothing from your conversations, on any tier, aggregated or otherwise. |
We cannot read your conversations, and we do know that an account connected, roughly when, and how much compute it used, because billing requires it. Those are different sentences and we are not going to blur them together.
06 Limits
Where the guarantee stops.
Every item here weakens our pitch. They are here because a brief that omits them is an advertisement.
- 01 Plaintext exists during processing Inference requires it. The guarantee is not that plaintext never exists. It is that no operator, hypervisor or host process holds a path to it, and that you can check for the absence of that path before you start.
- 02 This inherits the silicon vendor's threat model A confidential computing root of trust means trusting the hardware vendor, their firmware and their attestation chain. That is a narrower and far more scrutinised trust base than trusting an operator's internal controls. It is not zero, and a vendor-level break would affect us the way it affects everyone else in this category.
- 03 Side-channel research is active Attacks against enclave technologies get published and mitigated, and new ones keep appearing. We intend to track them in the open and state which mitigations each build carries, including when the answer is that a mitigation is not yet available.
- 04 Compulsion produces detection, not immunity If we were compelled to ship an image with different properties, that image would carry a different measurement and your client would refuse the session. You would find out. That is a real property and it is worth having. It is a detection guarantee, not a prevention one, and anyone who tells you otherwise is describing a system that does not exist.
- 05 Availability is not confidentiality Anyone who can reach the hardware can stop the service. Nothing here prevents an outage, a seizure of machines, or a provider terminating us. Confidentiality survives all of those. Access does not.
- 06 Metadata is still metadata An observer positioned on the network can see that you connected to this service and when. We do not retain that, and we cannot stop them from collecting it.
07 Artifacts
The checkable things, and whether they exist yet.
This is the section that matters. Everything above is prose. These are the objects that would let you confirm or refute it, with their honest status today.
| Artifact | What it would let you do | Status |
|---|---|---|
| Enclave source | Read what runs, and build it yourself. | not yet published |
| Reproducible build instructions | Derive the measurement from source and compare it to what your client saw. | not yet published |
| Reference measurements per release | Know which hash is supposed to be running. | not yet published |
| Independent rebuild attestations | Confirm the source to hash mapping without trusting us. | not yet published |
| Attestation client source | Verify with code you control instead of code we shipped. | not yet published |
| Third-party audit reports | Read an outside assessment in full, open findings included. | not yet commissioned |
| Security bounty scope | Know what is in scope and disclose on your own schedule. | not yet published |
| This brief | Hold us to a written description that predates the product. | draft 0.1 |
Nothing in this brief is independently verifiable today. That is the accurate statement, and publishing it is the point. The measure of whether this product is real is how many rows above turn into links, and how quickly. Until they do, this is a description of intent by a company you have no particular reason to trust yet.
Told when this changes.
We will email once when the private beta opens, and once more if this brief changes in a way that affects the guarantee.