RFC-WF-0009
Threat Model & Security Invariants (TMSI)
Status: Draft Standard
Version: 1.0.0
Date: 22 Set 2025
Category: Standards Track
Author: FullAgenticStack Initiative
Dependencies: RFC-WF-0001 (WFCS), RFC-WF-0002 (WWCS), RFC-WF-0003 (CCP), RFC-WF-0004 (ACSM), RFC-WF-0006 (EAS), RFC-WF-0007 (OoC), RFC-WF-0008 (RCP)
License: Open Specification (Public, Royalty-Free)
Abstract
This document specifies the Threat Model & Security Invariants (TMSI) for WhatsApp-first systems. TMSI defines a minimum, auditable threat model and a set of non-negotiable security invariants that MUST hold for systems claiming WhatsApp-first compliance. The goal is to prevent “secure-by-intuition” implementations by binding risks to explicit mitigations across command execution (CCP), administrative security (ACSM), evidence (EAS), observability (OoC), and recovery/compensation (RCP).
Index Terms— threat modeling, STRIDE, security invariants, replay attacks, privilege escalation, audit integrity, conversational systems, WhatsApp-first.
I. Introduction
WhatsApp-first systems are operationally powerful: they execute domain, administrative, observability, and recovery functions via a conversational channel. This increases exposure to threats such as replay, spoofing, privilege escalation, STT ambiguity exploitation, and evidence tampering. TMSI provides a minimum model to systematically reason about security and to validate that the specification’s controls actually mitigate defined threats.
TMSI is compatible with structured threat modeling frameworks (e.g., STRIDE) but focuses on WhatsApp-first-specific surfaces.
II. Scope
This standard specifies:
- A minimum threat model (assets, actors, trust boundaries, attack surfaces)
- A baseline threat taxonomy tailored to WhatsApp-first systems
- A set of mandatory security invariants (MUST-level rules)
- A mapping from threats → required mitigations → RFC controls
- Evidence requirements to audit security decisions and enforcement
This standard does not prescribe a specific cryptosystem or identity provider; it defines auditable obligations.
III. Normative Language
MUST, MUST NOT, SHOULD, SHOULD NOT, MAY are normative.
IV. System Model
A. Actors
An implementation MUST model at least these actor types:
- Human User: end-user operating via WhatsApp
- Human Operator/Admin: privileged operator executing admin and recovery actions
- Agent Actor: automated decision/execution agent proposing or issuing commands
- Service Actor: backend service executing effects (payments, inventory, CRM updates)
- External Integrations: payment gateways, shipping, ERP connectors, webhooks
B. Trust Boundaries
Implementations MUST identify at least these boundaries:
- B1: WhatsApp transport boundary (message delivery behavior, duplicates, ordering)
- B2: Ingress boundary (webhook receiver / message handler)
- B3: Command canonicalization boundary (raw input → envelope)
- B4: Authorization boundary (scope evaluation, step-up decisions)
- B5: Execution boundary (effects applied to external/internal systems)
- B6: Evidence boundary (append-only storage, integrity, access controls)
- B7: Observability boundary (telemetry queries, redaction, operator visibility)
C. Critical Assets
The threat model MUST include at least:
- A1: Authorization state (roles/scopes/delegations)
- A2: High-impact config (feature flags, policies, billing settings)
- A3: Financial effects (charges, refunds, payouts)
- A4: Operational state (orders, inventory, customer records)
- A5: Evidence artifacts and audit trails (EAS)
- A6: Recovery controls (retry/cancel/compensate/reset)
- A7: Integration secrets (API keys, webhooks, tokens)
- A8: PII and sensitive message content (documents, transcripts)
V. Threat Taxonomy (Minimum)
Implementations MUST consider at least the following threats, aligned with STRIDE-style categories.
T1 — Spoofing / Impersonation
- Attacker acts as a user/admin/agent to issue commands.
T2 — Replay / Duplicate Delivery Abuse
- Replaying messages or exploiting webhook duplicates to trigger repeated effects.
T3 — Tampering (Input / Envelope / Evidence)
- Altering input interpretation, command envelope fields, or evidence records.
T4 — Privilege Escalation
- Executing admin-only actions using insufficient scopes, ambiguous prompts, or agent loopholes.
T5 — Repudiation / Audit Gaps
- Lack of sufficient proof tying an action to actor, policy, and confirmation.
T6 — Information Disclosure
- Observability outputs leaking PII/secrets/internal topology across tenants or to low-privilege actors.
T7 — Denial of Service / Abuse
- Flooding commands, OoC queries, recovery attempts, or confirmation token guessing.
T8 — STT Ambiguity Exploitation
- Using audio ambiguity to coerce incorrect intent/target selection (“cancel it”, “delete that”).
T9 — Recovery Abuse
- Misusing retry/reprocess/compensate/reset to create fraud, erase traces, or force inconsistent state.
T10 — Agent Misbehavior (Operational Hallucination)
- Agents proposing/executing actions beyond policy, inventing targets, or bypassing confirmation.
VI. Mandatory Security Invariants
A WhatsApp-first-compliant implementation MUST satisfy all invariants below.
INV-1 — No State Mutation Without Canonical Envelope
State-mutating operations MUST execute only from a canonical Command Envelope, never directly from raw conversational text/audio.
INV-2 — No Mutation Without Explicit Confirmation
Every state mutation MUST require explicit confirmation (per CCP), with strengthened confirmation for destructive actions.
INV-3 — Admin Actions Require Scope + Step-up
Administrative/high-impact actions MUST require explicit scopes and step-up verification (per ACSM), and MUST be bounded by freshness.
INV-4 — Idempotent Effects Under At-Least-Once Delivery
The system MUST ensure idempotent outcomes for state mutations under duplicate delivery and retries.
INV-5 — Evidence Completeness for Mutations
For every mutating command, the system MUST emit evidence artifacts sufficient to reconstruct: who/what/when/why/outcome/affected resources.
INV-6 — Evidence Immutability
Evidence artifacts MUST be immutable once written. Corrections MUST be new artifacts (append-only semantics).
INV-7 — Least-Privilege Observability
Observability over conversation MUST enforce scope-gated access and redaction. Cross-tenant visibility MUST be prevented.
INV-8 — Safe Ambiguity Handling
Ambiguous intents/targets MUST NOT execute. The system MUST require disambiguation through explicit identifiers or enumerated selection.
INV-9 — Recovery Is Governed
Recovery/compensation operations MUST be scope-gated, confirmed according to risk class, evidence-backed, and replay-safe.
INV-10 — Agents Cannot Bypass Human Control for High-Risk Actions
Agents MUST NOT unilaterally execute destructive/admin actions without human confirmation and proper authorization gates.
VII. Threat → Mitigation Mapping (Normative)
Implementations MUST provide controls that map threats to mitigations as follows:
- T1 Spoofing → INV-3 (scope+step-up), INV-5 (audit), INV-7 (least privilege), strong identity binding (ACSM)
- T2 Replay/Duplicates → INV-4 (idempotency), INV-1 (envelope), INV-5 (evidence)
- T3 Tampering → INV-1 (canonical envelope), INV-6 (append-only evidence), integrity fields (EAS)
- T4 Privilege escalation → INV-3 (scopes), INV-8 (disambiguation), INV-10 (agent limits)
- T5 Repudiation → INV-5 + INV-6 (evidence completeness + immutability)
- T6 Info disclosure → INV-7 (scope + redaction)
- T7 DoS/abuse → rate limiting + token hardening + OoC throttling (OoC), recovery throttling (RCP)
- T8 STT ambiguity → INV-2 + INV-8 (strengthened confirmations + disambiguation)
- T9 Recovery abuse → INV-9 (governed recovery), INV-5 (evidence)
- T10 Agent misbehavior → INV-10 + INV-1/2/3 (agent proposes, human confirms, scopes enforce)
VIII. Evidence Requirements for Security Decisions
Security decisions MUST be evidence-backed. For any mutating command, evidence MUST include:
- authorization decision (
allow/deny) + evaluated/required scopes - step-up requirement and satisfaction metadata (when applicable)
- confirmation requirement and satisfaction metadata (when applicable)
- lifecycle stage and terminal outcome
- trace bindings to conversation identifiers
These requirements are satisfied by EAS-compliant artifacts, and MUST be retained according to system policy.
IX. Abuse Controls (Minimum)
Implementations SHOULD implement:
- rate limiting for command ingress and OoC queries
- confirmation token constraints (single-use, short-lived, envelope-bound)
- progressive backoff for repeated denied attempts
- anomaly flags surfaced via OoC to privileged operators
X. Relationship to Other RFCs
- WFCS (RFC-WF-0001): defines compliance requirements that these invariants secure.
- WWCS (RFC-WF-0002): defines conversion patterns; TMSI constrains safe equivalents.
- CCP (RFC-WF-0003): provides envelope + confirmation + idempotency substrate.
- ACSM (RFC-WF-0004): scopes + step-up for admin operations.
- EAS (RFC-WF-0006): evidence format for audit integrity and tamper-evidence.
- OoC (RFC-WF-0007): observability access control and redaction constraints.
- RCP (RFC-WF-0008): governed recovery and compensation controls.
XI. Conclusion
TMSI defines a minimum threat model and a set of mandatory security invariants for WhatsApp-first systems. These invariants establish that conversational operations remain safe under real distributed-system behavior (duplicates, retries, ambiguity), while preserving auditability, least privilege, and governed recovery—without depending on external dashboards.
References
[1] RFC-WF-0001, WhatsApp-First Compliance Standard (WFCS).
[2] RFC-WF-0002, Web-to-WhatsApp Conversion Standard (WWCS).
[3] RFC-WF-0003, Conversational Command Protocol (CCP).
[4] RFC-WF-0004, Administrative Command Security Model (ACSM).
[5] RFC-WF-0006, Evidence Artifact Schema (EAS).
[6] RFC-WF-0007, Observability over Conversation (OoC).
[7] RFC-WF-0008, Recovery & Compensation Protocol (RCP).
Concepts and Technologies
STRIDE-aligned threat taxonomy, trust boundaries, command envelopes, step-up verification, idempotency under at-least-once delivery, append-only evidence artifacts, conversational observability with redaction, governed recovery/compensation, agent authority constraints.
Top comments (0)