scuttle puts a write-only encryption boundary in front of AI application logs

scuttle moves encryption ahead of storage instead of under it

scuttle targets one narrow hole in AI infrastructure logging: request and response payloads that are legitimately observable for a while but then persist for years inside databases, replicas, snapshots and backups. The README lists what a single request can carry, from prompts and model responses to source code, retrieved documents, PII and credentials that slipped into context. A normal pipeline pushes application logs into a primary database, and that database forks into a replica, a snapshot and a backup. Deleting a row after thirty days does not remove yesterday's snapshot, a lagging replica or an oplog entry. scuttle's answer is positional rather than clever: encrypt before the payload reaches storage, and treat the storage tier as untrusted. A fleet holding only a public capture key can encrypt new records and cannot open records written earlier. That is the whole promise, and it is narrow enough to state precisely.

A hybrid KEM wraps a leaf key the writing fleet never sees

The long-lived secret is a leaf key that the writing side generates per record and does not keep in the clear. That leaf key is what the payload encryption uses, and it is protected by a hybrid KEM combining ML-KEM-768 with X25519. The hybrid form matters for two different reasons. ML-KEM-768 gives post-quantum resistance against a future adversary who recorded ciphertexts today, while X25519 keeps a classical component that existing implementations and reviewers already understand. The capture key is public, so its public half can live in the data plane next to the gateway, the workers and the logging infrastructure. The wrapped leaf key travels alongside the ciphertext into untrusted storage, and only a privileged reader holding the capture private key can unwrap it. The stated outcome is blunt: a database credential is not intended to be a historical prompt-decryption credential. Anyone who copies the database gets the encrypted payload, the wrapped key and some metadata, and nothing else.

HKDF derives per-record and per-field keys instead of one shared secret

Payload encryption is AES-256-GCM, but the key material behind it is not a single shared secret. The architecture routes an ephemeral leaf key through HKDF to derive per-record and per-field keys, so two fields inside the same log entry can carry different keys and can be opened independently. The repository depends on github.com/klauspost/compress v1.20.0 for zstd compression, and the architecture places compression as its own independent step ahead of the AES stage, which keeps plaintext from sitting in memory longer than the operation requires. The chain is therefore: compress, encrypt under a derived key, wrap the leaf key with the hybrid KEM, then write ciphertext and wrapped key to storage. A privileged reader reverses it by holding the capture private key. The split between the key-encryption step and the payload-encryption step is exactly what makes a write-only fleet possible, since the fleet needs only the public capture key to produce wrapped keys it is unable to open.

There is no install command, so the module path is the whole onboarding story

No installation command appears in the README, and the project has no GitHub releases, so there is no binary to download and no versioned artifact to pin. The project presents itself as a Go library, and go.mod names the module and the toolchain it expects:

module github.com/Continuum-AI-Corp/scuttle

go 1.26.1

require github.com/klauspost/compress v1.20.0

The only concrete first step the sources support is depending on that module path from a program built with Go 1.26.1 or newer, which pulls in the single compression dependency. A first real use follows the flow above: the application compresses a payload, encrypts it with a key derived through HKDF, wraps the leaf key to the public capture key, and stores the ciphertext and the wrapped key together. The README does not document a CLI, a configuration file or environment variables, and while a cmd/ directory exists at the root, no install command or one-line invocation is documented anywhere in the sources.

The repository root reads like the documentation for a v0 project

At the top level sit ATTACK.md, SECURITY.md, SPEC.md and CHANGELOG.md, alongside the Go sources envelope.go, keyring.go and keys.go, a cmd/ directory, go.sum and a LICENSE file. The README says ATTACK.md lists the security properties the authors believe the system provides, ordered by how expensive it would be for them to be wrong, together with fuzz targets aimed at those assumptions. That ordering is the useful part, since it tells a reviewer which claim to attack first instead of presenting a flat inventory of claims. The test tree carries the same intent in code form: envelope_test.go, keyring_test.go and keys_test.go sit next to fuzz_test.go, hardening_test.go, rotation_test.go, spec_test.go, vectors_test.go and a testdata/ directory. Maintenance activity is recent, with the last push on 2026-10-15 and the repository not archived. The status badge still reads v0, and the status section states plainly that the project is not independently audited.

Three stated limits, and one structural limit you create yourself

Several limits are stated rather than implied, and all of them come from the project's own status notes. The construction is v0 and not independently audited, so the security argument rests on the authors' own reading of ML-KEM-768, X25519, HKDF and AES-256-GCM rather than on an outside review. The wire format is not stable, and the README advises against using scuttle yet for data you cannot afford to lose or make permanently unreadable, which rules out a migration path to a later format and makes the archive hard to unwrap later. There are no GitHub releases either, so there is no published version to pin and no release history to consult beyond the CHANGELOG.md file at the root. A fourth limit is structural: the scheme protects payloads sitting in storage, while a privileged reader still holds one capture private key that opens everything it touches. That key is where confidentiality eventually fails, and the architecture deliberately places it across a trust boundary with access controls and an audit boundary. You also inherit the integration cost, because the sources available here do not document how the keyring is laid out or how a log pipeline is wired to it.

How scuttle differs from storage-layer encryption

The nearest alternative is storage-layer encryption, where the database encrypts its own files and the application hands it plaintext. The weakness of that approach is named directly: encryption only at the storage layer means that whoever obtains the database's normal decryption path may obtain the plaintext. Storage encryption protects against theft of raw files and disk snapshots, but it does not protect against a stolen database credential or a compromised application host, because the running system needs the decryption key in order to write. scuttle inverts that requirement. The writing side receives a public capture key, keeps no secret capable of opening history, and an attacker reaching the database, a replica, a backup or a snapshot sees ciphertext and wrapped keys. The cost is that every read path now depends on the privileged reader and the capture private key, and key rotation and field-level granularity become the application's concern instead of the storage engine's.

Editorial conclusion

Adopt scuttle only if your AI log pipeline writes into a storage tier you genuinely do not trust and you are able to staff a privileged reader. Skip it if you need a stable wire format, an independently audited construction, or documented integration steps, because scuttle is v0, unaudited and publishes no releases. Before anything else, read ATTACK.md and SPEC.md at the repository root and confirm that the last push on 2026-10-15 reflects a construction you would be willing to depend on.

Frequently asked questions

Official sources

1. Continuum-AI-Corp/scuttle on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README