Immutable Audit Trails: Logging Every Developer Prompt on the E31 Forge

Yes. On the E31 Forge, every developer prompt, model response, and file-touching action gets written to a local, append-only log the moment it happens, before the session output ever reaches the developer's screen. Because the appliance is sealed and air-gapped, that log has no cloud counterpart a vendor could edit, delete, or reconcile on your behalf. The audit trail lives entirely inside your perimeter, under your retention policy, subject only to your access controls.

How the log is actually written

Forge runs as a sealed appliance: no outbound network path, no telemetry call home, no hosted control plane. The logging layer sits at the inference gateway, the single choke point every prompt and completion must pass through to reach the model runtime. As a request comes in, the gateway hashes the previous log entry and appends the new entry, chaining the two together before the response reaches the client. That chaining is what makes the log append-only in a meaningful sense. Altering or deleting a past entry breaks the hash chain for every entry after it, so tampering is detectable even by someone with root access to the box — not just prevented in theory.

Each entry captures the developer identity from the local directory service, a timestamp, the full prompt text, the model version that served it, the response, and references to any repository files the session read or wrote. Entries land in an append-only store, commonly a write-once log segment or a database with row-level immutability enforced at the storage layer rather than the application layer, so a compromised or careless admin process can't rewrite history through a back door in the ORM.

This is deliberately unglamorous engineering. Hash-chained logs are the same construction behind Certificate Transparency logs and most blockchain ledgers, minus the distributed consensus. You don't need a network of validators when the log never leaves a single sealed enclosure and physical access is already controlled. NIST's guidance on audit logging (SP 800-92) calls for exactly this property: logs that support forensic reconstruction and can demonstrate they haven't been altered after the fact. A local hash chain on tamper-evident storage satisfies that requirement directly, rather than through a vendor's promise.

What gets logged versus what gets exposed

Not every field in the log is meant for daily viewing. Full prompt and response bodies are retained for forensic and compliance purposes, but day-to-day review typically works off a metadata layer: who, when, which repository, which files, which model version. Full-content review sits behind a separate access control tier, often requiring two-person authorization, so routine oversight doesn't turn into routine surveillance of every line an engineer writes. The immutability guarantee covers both layers equally. You can restrict who reads the content without ever giving anyone the ability to quietly edit it.

Why local append-only beats vendor-controlled cloud logging

A cloud-hosted coding assistant's audit log is, structurally, the vendor's data. It sits on the vendor's infrastructure, under the vendor's retention schedule, accessible to the vendor's own engineers and support staff, and subject to the vendor's terms of service on export, deletion, and subpoena response. Even a well-run vendor with strong internal controls is still a third party with the technical capability to alter or purge that log, and your only real assurance against that is contractual, not architectural. In defense, aerospace, or any environment where prompt-level records may need to hold up as evidence in an incident review or a security clearance investigation, a contractual promise is a materially weaker property than a technical guarantee.

There's a jurisdictional problem too. A vendor's cloud log can become unavailable because of a billing dispute, a service deprecation, a change in the vendor's business, or a shift in which country's courts can compel access to it. None of that touches an on-appliance log. It sits on hardware you own, in a facility you control, and it keeps working regardless of what happens to the vendor's SaaS backend. For programs building to standards like NIST SP 800-53's audit and accountability control family (the AU controls), the expectation is that the organization being audited controls the audit record end to end. A cloud assistant log where the vendor is the custodian doesn't satisfy that expectation, no matter how strong the vendor's SOC 2 report looks — custody and control are the property actually being assessed.

Air-gapping also removes a quieter risk: exfiltration through the logging pipeline itself. A cloud-connected assistant has to transmit prompts off-premises to reach its hosted model, which means the prompt content — proprietary source code, unreleased designs, classified context pasted in by mistake — leaves your network before an audit log is even the concern. Forge's sealed design means the prompt never leaves the room. The log documents activity. It doesn't create a second copy of your source code sitting on someone else's servers.

What this means operationally

For a security or compliance team, Forge's audit trail works as source-of-truth evidence rather than a courtesy export. Pull the full session history for a given developer, a given repository, or a given date range, and what you're looking at is what happened, because the hash chain would show any gap or edit. That matters for insider-threat investigations, for reconstructing how a specific line of code entered a codebase, and for showing an auditor or a program office that AI-assisted development on a sensitive project left a complete, unforgeable record instead of a log the tool vendor could have touched.

None of this substitutes for your organization's own certification posture. Forge's architecture is built to fit environments with strict audit and accountability requirements, not to hand you a compliance certificate by itself. What it provides is the one property those regimes actually ask for: a record of developer-AI interaction that your organization, not a vendor, fully owns and controls, sealed inside the same perimeter as the code it documents.