​
ADR-0029: Digital Worker acts on external chat without per-action approval — safe-executable vs consequential

​
Status

Accepted (pending Phase 1 implementation)

​
Tags

digital-worker, security, approval, capability-policy, chat, audit

​
Decision

The Digital Worker runs a defined allow-set of safe-executable actions with no human approval, and human-gates only consequential (system-affecting) actions. The posture is record-everything-for-after-the-fact-review, not approve-everything-up-front.
  • Safe-executable (no approval): answering a solicited mention directly in-channel (reply-on-mention), reading/summarizing allowed chat context, classifying/extracting, and creating internal_only inbox drafts.
  • Consequential (human approval required): creating or assigning Fieldforce tasks, posting proactive (unsolicited) chat messages, scheduling meetings, and any future external-ticket / workflow action.
  • New action types default to consequential until explicitly classified safe. The boundary is an explicit allow-set, not a per-call inference.
Every action — safe or consequential — is fully traceable (dw_chat_events, dw_ai_runs, and human business actions to the shared audit_log per ADR-0007).

​
Why

The original design routed every worker output through an approval inbox. That makes the headline use case useless — nobody wants a manager to approve “summarize this thread” before the asker sees it. The human gate exists to stop the worker acting on the organization’s behalf (creating tasks, posting unsolicited messages), not to police answering a direct question. The surprising part worth recording: the worker posts to an untrusted external channel with no human review for the safe-set. A future reader will suspect a security hole. It is deliberate and bounded by layered controls: replies go only to a verified mapped user in an allowlisted channel, output is schema-validated, reply-on-mention is a per-channel capability an admin must grant, everything is audited, and the two-tier digital_worker feature flag (ADR-0016) is an instant kill-switch that gates send. Approval would add nothing the audit trail + kill-switch don’t already provide for these low-risk actions. Rejected alternative:
  • Approve-everything-up-front (original spec). Safe and simple, but kills the product’s core UX (instant, solicited help). Rejected.

​
Consequences

  • The worker can post to untrusted external surfaces unreviewed for the safe-set; the mitigations above are the compensating controls, and the kill-switch is the backstop.
  • Expanding the safe-action allow-set is a deliberate act requiring a spec/ADR update — it does not grow by inference.
  • A direct reply that goes wrong is caught after the fact via audit + the manager’s review, by design, not prevented up front.

​
Rules for agents

  • Only actions in the documented safe-executable allow-set may run without approval; everything else routes to the inbox for a human gate.
  • A new action type defaults to consequential until explicitly classified safe in the spec.
  • Safe actions still validate output schema and write full audit/provenance; “no approval” is not “no record.”