Skip to content

runtime: route side effects through a unified audited dispatcher #484

Description

@puremachinery

Problem

Side effects initiated by channel handlers, control APIs, agent tools, cron/tasks, and plugins need consistent validation, approval, redaction, audit logging, and error handling. If each caller mutates state or invokes tools directly, security policy becomes convention instead of a runtime invariant.

Goal

Introduce a unified dispatcher for side-effecting actions and make bypasses explicit, reviewable, and rare.

Acceptance criteria

  • Define the dispatcher contract: caller identity, caller class, target, action, parameters, approval mode, policy context, and result shape.
  • Split interactive callers from autonomous callers. Interactive callers may request live approval; autonomous callers must use preconfigured policy and replayable/simulated tests.
  • Define an audit event schema before implementation. At minimum: event id, timestamp, actor, caller class, session/task/channel ids where available, action, target, input fingerprint, redacted parameter summary, approval policy, decision, result, error kind, and correlation id.
  • Define audit retention and queryability: where events are stored, how operators inspect them, and what is intentionally not stored.
  • Define the redaction policy centrally. Default posture should store fingerprints and allowlisted summaries, honor tool-schema sensitive: true parameter metadata, and also apply a central sensitive-key denylist for credentials/tokens/passwords/URLs.
  • Enumerate allowed dispatcher exemptions in writing, with rationale. Examples may include read-only health/status checks, static file serving, and cross-user aggregation reads that do not mutate state.
  • New bypasses require an inline dispatch-exempt: <category> annotation using one of the documented categories.
  • Existing mutation paths are inventoried, with a migration plan for channel handlers, control APIs, agent tools, cron/tasks, and plugin invocations.
  • Tests cover both interactive approval and autonomous-policy execution, plus rejection of an unapproved direct mutation path.

Notes

The threat model should land before the dispatcher exemption and audit-retention lists are finalized.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    refactorInternal restructuring without intended behavior changesecuritySecurity controls, vulnerabilities, or hardening

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions