DEV Community

Cover image for FullAgenticStack WhatsApp-first: RFC-WF-0004
suissAI
suissAI

Posted on

FullAgenticStack WhatsApp-first: RFC-WF-0004

#architecture #infosec #security #systemdesign

RFC-WF-0004

Administrative Command Security Model (ACSM)

Status: Draft Standard
Version: 1.0.0
Date: 20 Nov 2025
Category: Standards Track
Author: FullAgenticStack Initiative
Dependencies: RFC-WF-0001 (WFCS), RFC-WF-0002 (WWCS), RFC-WF-0003 (CCP)
License: Open Specification (Public, Royalty-Free)

Abstract

This document specifies the Administrative Command Security Model (ACSM) for WhatsApp-first systems. ACSM defines normative requirements to authenticate, authorize, and safely execute administrative and high-impact commands over WhatsApp—without relying on web dashboards—while ensuring least privilege, step-up verification, replay resistance, strong auditability, and controlled recovery flows. ACSM is designed to pair with the Conversational Command Protocol (CCP) command envelope and confirmation semantics.

Index Terms— authorization, administrative operations, least privilege, step-up authentication, capability scopes, replay resistance, audit trail, WhatsApp-first.

I. Introduction

WhatsApp-first systems require Administrative Sovereignty: configuration, feature flags, access control, recovery actions, and governance operations MUST be executable through WhatsApp. However, administrative operations are high-risk by nature. ACSM defines how to execute them safely within a conversational channel, especially under multimodal ambiguity (e.g., STT).

This model assumes CCP provides canonical execution via envelopes; ACSM constrains who may execute what, under which conditions, with which verification, and how these actions are audited and recovered.

II. Scope

ACSM specifies:

  • Actor identity and trust context requirements for admin actions
  • Capability-based authorization (scopes), including delegation
  • Step-up verification rules for high-impact operations
  • Session binding and replay resistance requirements
  • Safe handling of multimodal input for administrative commands
  • Auditing and evidence requirements for admin actions
  • Recovery and break-glass constraints (without violating WhatsApp-first)

ACSM does not mandate a single identity provider, cryptosystem, or vendor stack; it defines protocol obligations and security invariants.

III. Normative Language

MUST, MUST NOT, SHOULD, SHOULD NOT, MAY are normative.

IV. Definitions

Admin Command: A command that changes configuration, permissions, policies, system controls, billing-critical settings, integration credentials, or recovery actions.
Capability Scope (Scope): A named permission that grants the right to execute a command class (e.g., orders.cancel, admin.feature_flags.write).
Step-up Verification: Additional user verification required before executing a high-risk command (e.g., a second factor or stronger confirmation).
Trust Context: Runtime context representing authentication strength, device binding status, session freshness, and risk signals.
Break-glass: A constrained emergency path for restoring control while minimizing blast radius.

V. Threat Model (Minimum)

An ACSM-compliant system MUST address at least:

  • T1: Unauthorized admin actions (account takeover, impersonation)
  • T2: Accidental destructive execution (especially via audio/STT)
  • T3: Replay and duplicate delivery (message retries, malicious replay)
  • T4: Privilege escalation via ambiguous commands or weak scoping
  • T5: Audit gaps (actions performed without trace/evidence)
  • T6: Recovery abuse (reset/revoke operations used maliciously)

VI. Security Principles

A. Least Privilege by Default

Administrative abilities MUST be gated by explicit scopes. No “admin can do everything” without scope partitioning.

B. Explicitness Over Ambiguity

Admin commands MUST NOT execute from raw conversational text. They MUST execute only from a canonical envelope (CCP), and MUST enforce disambiguation when multiple targets exist.

C. Step-up for High-Impact

High-impact actions MUST require step-up verification, even if the session is authenticated.

D. Evidence-First Auditing

Admin operations MUST be recorded as immutable/append-only evidence artifacts sufficient for later inspection and rollback/compensation workflows.

E. WhatsApp-first Preservation

Security controls MUST NOT introduce mandatory web-only dependencies for critical administrative paths (WFCS compliance).

VII. Actor Identity and Authentication Requirements

A. Unique Actor Identity

Each actor MUST have a stable unique identifier (actor.user_id) included in the Command Envelope. Identity MUST be consistent across sessions and used for auditing.

B. Authentication Strength Levels

The system MUST classify authentication strength into at least three levels:

  • L1 (Standard): baseline login/session
  • L2 (Strong): phishing-resistant or 2FA-backed session
  • L3 (Privileged): strong + step-up satisfied for high-impact admin actions

The Trust Context MUST record current level.

C. Device/Session Binding (Normative Requirement)

For admin commands, the system MUST bind command execution to a fresh Trust Context (see Section IX) to reduce replay risk.

(Implementation notes MAY include passkeys, magic links, OTP, hardware-backed keys, etc., but the model stays vendor-agnostic.)

VIII. Authorization Model: Capability Scopes

A. Scope Registry

The system MUST define a Scope Registry that maps:

  • scope_name → allowed command intents (entity/action) + constraints
  • optional target constraints (tenant, org unit, resource patterns)
  • required trust level (L1/L2/L3)
  • required step-up method(s) for destructive/high-impact actions

B. Scope Assignment

Scopes MUST be assigned via an auditable admin pathway (itself subject to ACSM). Scope changes MUST be treated as high-impact.

C. Deny-by-Default

If a command’s intent does not match a granted scope, it MUST be rejected with a safe explanation and audit record.

D. Delegation (Optional but Standardizable)

The system MAY support delegation tokens (time-bounded, scope-bounded). If supported, delegation MUST be:

  • time-limited
  • scope-limited
  • revocable
  • auditable
  • non-transferrable across tenants

IX. Step-up Verification Policy

A. Step-up Triggers (Minimum Set)

The system MUST require step-up verification for at least:

  1. Permission changes (grant/revoke scopes, role escalation)
  2. Recovery actions (reset credentials, revoke devices, rotate keys)
  3. Integration secrets (create/update API keys, webhooks, connectors)
  4. Billing-critical settings (pricing, payment routing, payout changes)
  5. Global feature flags / policy toggles affecting multiple users
  6. Bulk operations (bulk delete, bulk cancel, mass export)

B. Step-up Methods

The system MUST support at least one step-up method that is resistant to casual mistakes and STT ambiguity. Acceptable methods include:

  • explicit confirmation token (CONFIRM <token>)
  • secondary confirmation phrase with target binding (YES, REVOKE DEVICE X)
  • out-of-band verification via a second registered factor (implementation-defined)

C. Freshness Requirement

A step-up MUST be considered valid only within a short freshness window (implementation-defined; SHOULD be minutes, not hours). Freshness metadata MUST be attached to the Trust Context.

X. Replay Resistance and Idempotency Constraints

A. Envelope-Linked Replay Safety

Admin commands MUST enforce CCP idempotency and MUST additionally bind execution to:

  • actor id
  • trust context id
  • confirmation token (when used)
  • a short validity window for the confirmed envelope

B. Confirmation Token Properties

If confirmation tokens are used, they MUST be:

  • short-lived
  • single-use
  • bound to a specific command envelope (command_id)
  • unguessable at practical scale

XI. Multimodal Safety Rules for Admin Commands

A. No Direct Execution from Audio

Audio-initiated admin commands MUST NOT execute without showing a canonical preview and collecting strengthened confirmation.

B. Ambiguity Rejection

If STT transcription yields ambiguous intent or target, the system MUST require disambiguation via numbered options or explicit identifiers.

C. “Dangerous Defaults” Prohibition

Admin commands MUST NOT infer destructive actions from vague language (“reset everything”, “delete all”) without explicit target and step-up.

XII. Audit and Evidence Requirements

A. Minimum Audit Fields

Every admin command MUST produce an immutable audit/evidence record containing at least:

  • command envelope (or a cryptographic reference to it)
  • actor identity and tenant context
  • authorization decision (scopes evaluated)
  • trust context snapshot (auth level, step-up status, freshness)
  • outcome (executed/rejected/failed/compensated)
  • timestamps for accepted/confirmed/executed
  • affected resources summary (resource IDs or counts)

B. Evidence Retrieval Over WhatsApp

In alignment with WhatsApp-first observability requirements, the system SHOULD allow privileged actors to query:

  • last admin actions
  • why a command was rejected
  • current active scopes and policies (redacted as needed)

XIII. Recovery and Break-glass Constraints

A. Break-glass Must Be Constrained

If break-glass exists, it MUST:

  • grant minimal temporary scopes
  • require strong verification (step-up)
  • be time-bounded
  • be prominently audited
  • be revocable via WhatsApp

B. No Web-Only Mandatory Recovery

Recovery flows MUST NOT require a web dashboard as the only path for restoring control. A WhatsApp-only recovery path MUST exist (WFCS), even if it is stricter and slower.

C. Two-Channel Recovery (Recommended)

The system SHOULD require at least two independent confirmations for the most sensitive recoveries (e.g., device revoke + credential reset), but both confirmations MUST remain achievable without a web UI.

XIV. Compliance Profiles

An implementation MAY declare one of the following:

  • ACSM-Basic: scope gating + audit + step-up for destructive actions
  • ACSM-Strong: basic + trust freshness + replay binding + multimodal safeguards
  • ACSM-Operational: strong + WhatsApp-based evidence retrieval + constrained break-glass

XV. Relationship to Other RFCs

  • WFCS (RFC-WF-0001): mandates admin sovereignty and WhatsApp-only parity.
  • WWCS (RFC-WF-0002): maps UI admin controls into conversational equivalents.
  • CCP (RFC-WF-0003): provides the envelope, confirmation, and idempotency substrate that ACSM secures.

XVI. Security Considerations

This RFC raises the bar for admin safety inside a conversational channel, but implementers MUST still consider:

  • secure storage of secrets and connectors
  • phishing and social engineering resistance
  • insider threats and delegated authority misuse
  • log integrity (append-only) and retention controls
  • risk-based throttling for repeated rejected admin attempts

XVII. Conclusion

ACSM enables WhatsApp-first administrative sovereignty without turning WhatsApp into a fragile “remote control.” By enforcing scope-based authorization, step-up verification, replay binding, multimodal safeguards, and evidence-first auditing, systems can remain fully operable via WhatsApp while preserving realistic security invariants.

References

[1] RFC-WF-0001, WhatsApp-First Compliance Core (WFCS).
[2] RFC-WF-0002, Web-to-WhatsApp Conversion Standard (WWCS).
[3] RFC-WF-0003, Conversational Command Protocol (CCP).

Concepts and Technologies

Capability scopes, least privilege, step-up verification, trust context, session freshness, replay resistance, envelope-bound confirmation tokens, append-only audit evidence, multimodal safety constraints.

Top comments (0)