The Audit Log

Every action that changes a workspace or an app, and every method a signed-in person invokes, is recorded as an audit event: who did what, when, from where, and to what. Almost no platform can produce this record of activity inside a running app. Remy can, because every method call already passes through one execution point that the platform owns, so a developer instruments nothing. Events are written to storage nobody can alter or delete for a year, and are read back or exported in the schema a SIEM ingests. This chapter covers the difference between an access log and an audit log, the single point where capture happens, the event model, the delivery pipeline, and the read path.

#Access Log Versus Audit Log

A conventional access log records that a route was hit and a status came back. It cannot name the person, explain what the action meant, or say whether it should have been allowed. A Remy audit event carries all three, and two properties of the platform make that possible, neither of them the developer's work.

• Methods are contracts. A method has a human name and a description, so the record reads as the meaning of the action ("Approve Vendor Request"), not a route and a status.
• Identity is the platform's. Authentication resolves before a method runs, so every event names a real person, and the true principal is preserved even when one person acts on another's behalf.

#One Point of Capture

Every backend method call passes through a single execution point, the same one Request Lifecycles draws as the execute frame. That point sits on the platform side of the trust boundary, before the call crosses into the sandbox. It is where capture happens.

Because there is one point and the platform owns it, coverage is structural: every app, every method, with no way to opt out and no code to write. Capture is fire-and-forget, so it never blocks or breaks the request the method goes on to serve. The event it writes is identity-only: it records that a person invoked a named method, never the payload, and it fires only for authenticated humans, so the log stays signal rather than noise.

#One Event Model, Three Scopes

An audit event names an actor, an action, a target, and a context: time, source address, workspace, and where relevant the app. Actions are a closed catalog in code, reconciled against the sites that emit them in CI, so an action cannot exist without a place that emits it, or the reverse. Most systems audit the control plane or the application. Remy records both, in one schema, so a single trail runs from an administrator changing a role down to a person running a method.

#The Pipeline

1. Emit. The platform writes an event from wherever the action happens. High-frequency events can accumulate and roll up before delivery.
2. Deliver. Events go to a Kinesis Firehose delivery stream, which batches them and writes to S3. Dynamic partitioning lays objects out by workspace and date, so a per-workspace read scans a narrow prefix, and batches are sized so a read pays for few large objects rather than many small ones.
3. Store. The destination bucket has S3 Object Lock enabled at creation, in COMPLIANCE mode, with a default retention of one year. This is write-once-read-many (WORM) storage: a locked object cannot be deleted, or have its retention shortened, by anyone, including the root account, until the lock expires. The bucket blocks public access and accepts HTTPS only.
4. Tail. In parallel, the most recent events per workspace are pushed to a short Redis buffer, so the dashboard's activity view is instant while S3 remains the record.

A delivery alarm watches the stream and raises an alert if events stop landing.

#Reading and Export

The workspace dashboard browses and filters the log by time window, actor, action or a set of actions, and app. Every app-scoped event is enriched at read time with the app's current name and icon, and cursors are stable across pages. Viewing the log takes an explicit permission, tenant isolation is enforced on every read, and a read is itself an audited action.

A workspace can export any range as the canonical events or as OCSF, the Open Cybersecurity Schema Framework, in NDJSON. The OCSF projection maps every action to a real OCSF class and activity, carries standard fields where OCSF has a home for them, and places platform-specific detail in the standard unmapped object. It never invents a class or a field, and its conformance to the OCSF 1.8 JSON Schema is proven by a validator in CI. The result is the shape Splunk, Microsoft Sentinel, AWS Security Lake, Google SecOps, Datadog, and Snowflake ingest without translation.