off-host audit-log shadow: needs, not implementation #56

Closed
opened 2026-05-23 20:54:03 +00:00 by coilysiren · 1 comment
Owner

Originally filed by @coilysiren on 2026-05-05T10:21:39Z - https://github.com/coilysiren/coily/issues/55

Background

Per #49 and #51, the audit log is local-only after the Sentry drop. SECURITY.md's "off-host shadow" framing was retired in #51 because Sentry shipped a summary stream, not a shadow. The boundary now relies on the local JSONL alone, which is adequate for current single-host usage modes but leaves four properties unmet.

What a real shadow needs to provide

The implementation question is genuinely open and depends on which of these are load-bearing when this issue is picked up. Listing the needs first so the shape gets chosen against them, not the reverse.

  1. Tamper evidence. The host cannot be the only authority on what coily did. A second copy whose tampering is itself detectable means an agent that compromises the host cannot silently rewrite the audit log.

  2. Survivability. The trail outlives the host. Disk failure, laptop reset, OS reinstall, the rows are still findable somewhere.

  3. Cross-host correlation. When coily runs on the laptop, on kai-server, on a Windows host, one query answers "what did coily do across all hosts in window T." Today each host owns its own JSONL.

  4. Off-host access. Forensic questions do not require physical or ssh access to the originating host. A laptop offline does not mean the trail is unreachable.

What is deliberately not specified here

The shape of the shadow. rsync to kai-server, S3 with object-lock, a syslog forwarder, an append-only HTTP endpoint, a coily-side replication daemon, something else entirely. Each maps to a different subset of the four properties above and a different cost profile. The right call gets made when this issue is picked up, against the threat model at that time.

Triggering signals

This issue stays open as the placeholder until one of these makes the gap real:

  • A second host begins producing audit rows worth correlating (Windows laptop active, kai-server-side coily verbs land).
  • An external orchestrator per #23 drives coily and the local JSONL becomes a single point of forensic failure.
  • An incident or near-miss makes the gap visible.

Until then, the placeholder is the meta-improvement: the need is captured so future-Kai or future-agent reaches for it instead of re-deriving from scratch.

Originating thread: #49.

_Originally filed by @coilysiren on 2026-05-05T10:21:39Z - [https://github.com/coilysiren/coily/issues/55](https://github.com/coilysiren/coily/issues/55)_ ## Background Per #49 and #51, the audit log is local-only after the Sentry drop. SECURITY.md's "off-host shadow" framing was retired in #51 because Sentry shipped a summary stream, not a shadow. The boundary now relies on the local JSONL alone, which is adequate for current single-host usage modes but leaves four properties unmet. ## What a real shadow needs to provide The implementation question is genuinely open and depends on which of these are load-bearing when this issue is picked up. Listing the needs first so the shape gets chosen against them, not the reverse. 1. **Tamper evidence.** The host cannot be the only authority on what coily did. A second copy whose tampering is itself detectable means an agent that compromises the host cannot silently rewrite the audit log. 2. **Survivability.** The trail outlives the host. Disk failure, laptop reset, OS reinstall, the rows are still findable somewhere. 3. **Cross-host correlation.** When coily runs on the laptop, on kai-server, on a Windows host, one query answers "what did coily do across all hosts in window T." Today each host owns its own JSONL. 4. **Off-host access.** Forensic questions do not require physical or ssh access to the originating host. A laptop offline does not mean the trail is unreachable. ## What is deliberately not specified here The shape of the shadow. rsync to kai-server, S3 with object-lock, a syslog forwarder, an append-only HTTP endpoint, a coily-side replication daemon, something else entirely. Each maps to a different subset of the four properties above and a different cost profile. The right call gets made when this issue is picked up, against the threat model at that time. ## Triggering signals This issue stays open as the placeholder until one of these makes the gap real: - A second host begins producing audit rows worth correlating (Windows laptop active, kai-server-side coily verbs land). - An external orchestrator per #23 drives coily and the local JSONL becomes a single point of forensic failure. - An incident or near-miss makes the gap visible. Until then, the placeholder is the meta-improvement: the need is captured so future-Kai or future-agent reaches for it instead of re-deriving from scratch. Originating thread: #49.
Author
Owner

Iceboxed in the 2026-05-29 backlog burn-down: Off-host audit shadow; needs-doc, adequate-as-is per body. Reopen anytime if it becomes real.

Iceboxed in the 2026-05-29 backlog burn-down: Off-host audit shadow; needs-doc, adequate-as-is per body. Reopen anytime if it becomes real.
Sign in to join this conversation.
No labels
P0
P1
P2
P3
P4
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
coilyco-bridge/coily#56
No description provided.