🔄 Topic

Making the one allowed non-reply WhatsApp action—a scheduled morning greeting—prove that it is exactly that and nothing broader.

🎯 Goal

Allow a narrowly defined scheduled greeting without creating a general bypass around the fresh-reply rule.

🛠 What I Did

The reply-grant control intentionally blocks unsolicited outgoing messages. But a configured morning greeting is a legitimate exception, so I gave it a separate final-boundary check rather than weakening the reply logic.

The exception is accepted only when all of these facts are true:

  • the caller declares the exact morning-greeting origin;
  • the text matches a greeting, not arbitrary content;
  • the delivery occurs within the Europe/Rome morning window;
  • the recipient appears in the dedicated greeting configuration;
  • that recipient has not already received the greeting that day.

The bridge still makes this decision at egress. A scheduler saying “this is a greeting” is not enough by itself.

🔗 Key Cybersecurity Connections

This is exception handling as an authorization problem. A safe default-deny system often needs a small exception, but that exception must be just as constrained as the normal rule or it becomes the route around every control.

🔍 Investigation Questions

  • Can the exception send arbitrary text?
  • Can it target an unconfigured recipient?
  • Can it run outside its intended time window?
  • Can it send twice on the same day?
  • Is the decision made where delivery actually happens?

🚨 Detection Opportunities

Useful events to retain:

  • greeting request outside the permitted window
  • greeting target not present in configuration
  • greeting text that does not match the allowed purpose
  • duplicate greeting attempt for the same date and chat

Example:

event=scheduled_message_blocked
origin=morning-greeting
reason=morning-greeting-target-not-configured
action=review_scheduler_input_and_configuration

🧭 MITRE ATT&CK Techniques

Relevant defensive themes include:

  • T1053 — Scheduled Task/Job, because scheduled work needs its own guardrails
  • T1078 — Valid Accounts, where a legitimate route can still be over-authorized

🗺 Visual Investigation Diagram

Scheduled greeting request
    ↓
Is origin exact?
    ↓
Is text a greeting?
    ↓
Correct Rome time + configured target + unused today?
    ↓
Send once or block

⚠ Challenges

The hard part was resisting a generic “scheduled messages are allowed” rule. That would solve today’s need while silently authorizing future mistakes.

📚 What I Learned

I learned that a legitimate exception should be modeled as a separate capability with its own constraints, not as a boolean that disables the main protection.

➡ Next Steps

  • Test daylight-saving and boundary-time cases
  • Keep the configuration small and reviewable
  • Require a new explicit gate for any additional unattended message type

🧠 Reflection

“Allowed sometimes” is not a security design. The useful question is: allowed by whom, to whom, when, for what text, and how many times?

🧩 Lessons Learned

What worked

Combining purpose, recipient, time, text, and daily state.

What broke

The idea that a trusted scheduler could carry broad authority safely.

Why it broke

An origin label without final validation is only metadata.

Fix / takeaway

Put every exception behind a purpose-built gate at the delivery boundary.

📈 Skill Progression Context

This is practical least privilege for automation: the system can do one defined job, not anything that happens to look scheduled.

😄 TL;DR

The only allowed unsolicited message now has to prove it is the right greeting, for the right person, at the right time, once.