Skip to content

FWS-8 — Hardened audit emission (sequence numbers, payload stripping, optional signing) #91

@initializ-mk

Description

@initializ-mk

Part of the Forge backlog. Backend pairing: initializ WS-7 (workflow UI consumes hardened audit). Effort: S (3–5 engineer-days) without signing; M (1–2 weeks) with signing. Risk: low–medium. Depends on: #95 (FWS-7 — audit export capability). The hardening below targets the audit stream FWS-7 builds; ship FWS-7 first so sequence numbers and payload-stripping have a real export path to consume them.

Scope

Audit events are accurate, complete, and tamper-evident at emission time (signing, sequence numbers).

Why this matters

Audit is foundational to the whole initializ value prop (observability, cost tracking, security review). The meeting deck emphasized "no payload bytes in audit" — that posture needs to be enforced in code, not just claimed.

This isn't a meeting-driven ask, but it's a Forge-side hardening that elevates the platform's security claims from "trust us" to "verifiable."

Deliverables

  • Audit events carry a monotonically increasing sequence number per agent invocation (gap-detection at the consumer side).
  • Audit events do not include LLM prompt content or LLM completion content by default — configurable per agent if customer wants it (off by default).
  • Audit events for tool calls capture the tool name and structured args metadata (types, sizes) but not the raw arg values by default — same configurability.
  • Optional: audit events signed with agent's private key (per-agent or per-deployment); orchestrator can verify integrity.
  • Document the audit event schema as a stable contract; treat it as a versioned interface.

Architectural decisions

  • Signing — v1 or backlog? Signing adds complexity (key management, key rotation, customer-side verification). Recommend: spec the signing model in v1, ship in v1.5 unless a customer specifically asks. Sequence numbers and payload-stripping are v1.
  • Audit event schema versioning — once the platform UI depends on field names, breaking them is expensive. Recommend: version the schema explicitly, use additive changes only.

Risks

  • Low-Medium. Mostly bounded work, but the "what to emit / what not to emit" decisions need security review.

Open questions

  • Audit signing — is any customer actively asking for this, or is it future-proofing? If no current ask, defer signing to v2 entirely and just ship sequence numbers + payload-stripping in v1.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions