DEV Community

Cover image for Chapter 52 — Secure AI Notifications, Email, SMS, Push Messaging & Communication Infrastructure
Black Shadow Team ©
Black Shadow Team ©

Posted on

Chapter 52 — Secure AI Notifications, Email, SMS, Push Messaging & Communication Infrastructure

#ai

52.1 Introduction

Communication infrastructure is an essential part of a modern AI platform.

An application may need to send:

  • email verification messages;
  • password-reset notifications;
  • MFA and security alerts;
  • AI generation completion notifications;
  • storage warnings;
  • subscription notifications;
  • invoices;
  • organization invitations;
  • administrative alerts;
  • mobile push notifications;
  • SMS verification messages;
  • system announcements.

Because communication channels can influence authentication and account security, they must be treated as security-sensitive infrastructure.

A poorly designed notification system can create:

  • account-enumeration problems;
  • OTP abuse;
  • spam;
  • phishing opportunities;
  • notification flooding;
  • sensitive-data leakage;
  • unauthorized message delivery;
  • webhook abuse;
  • credential exposure.

The central principle is:

Communication systems should be treated as controlled security boundaries, not merely message-sending utilities.

52.2 Communication Architecture

A scalable architecture separates application logic from delivery providers.

                    AI Platform
                         |
                Notification Service
                         |
               Template / Policy Layer
                         |
                Delivery Queue
                         |
          +--------------+--------------+
          |              |              |
        Email           SMS            Push
          |              |              |
       Provider        Provider       Provider
Enter fullscreen mode Exit fullscreen mode

This allows providers to be changed without rewriting the entire application.

52.3 Communication Channels

The platform may support multiple channels:

Email
SMS
Push Notification
In-App Notification
Webhook
Enter fullscreen mode Exit fullscreen mode

Each channel has different characteristics.

Channel Typical Use Main Risk
Email Verification, recovery phishing/privacy
SMS OTP/security abuse/interception
Push alerts notification leakage
In-app product events authorization
Webhook integrations replay/fake events

The security policy should therefore be channel-specific.

52.4 Notification Service

Application components should not directly call external providers everywhere.

Instead:

```typescript id="zj6h8p"
interface NotificationService {
sendEmail(input: EmailNotification): Promise;
sendSms(input: SmsNotification): Promise;
sendPush(input: PushNotification): Promise;
createInAppNotification(
input: InAppNotification
): Promise;
}




This creates a central policy boundary.

The service can enforce:

* authorization;
* rate limits;
* templates;
* localization;
* privacy rules;
* delivery preferences;
* abuse controls;
* audit logging.

---

# 52.5 Notification Types

Notifications should be classified.

For example:



```typescript id="4q5c8a"
type NotificationCategory =
  | "security"
  | "authentication"
  | "billing"
  | "generation"
  | "storage"
  | "organization"
  | "marketing"
  | "system";
Enter fullscreen mode Exit fullscreen mode

This classification allows the application to apply different policies.

For example:

  • security notifications may be mandatory;
  • marketing notifications may be opt-in;
  • generation notifications may be configurable.

52.6 Security-Critical Notifications

Security notifications should receive priority.

Examples:

New Login
Password Changed
MFA Enabled
MFA Disabled
Passkey Added
API Key Created
API Key Revoked
Email Changed
Account Recovery
Administrative Role Changed
Enter fullscreen mode Exit fullscreen mode

These events should not depend entirely on ordinary marketing preferences.

52.7 Notification Preferences

Users should be able to control non-essential communication.

Example:

```typescript id="5j4t2w"
type NotificationPreferences = {
productUpdates: boolean;
marketing: boolean;
generationCompleted: boolean;
securityAlerts: boolean;
billingAlerts: boolean;
};




Security-critical notifications should normally remain enabled.

---

# 52.8 Email Architecture

A secure email pipeline can be:



```text
Application Event
      |
Notification Service
      |
Template Engine
      |
Policy Validation
      |
Email Queue
      |
Email Provider
      |
Recipient
Enter fullscreen mode Exit fullscreen mode

This asynchronous design prevents a slow email provider from blocking the primary application request.

52.9 Email Templates

Templates should be centrally managed.

A template might have:

```typescript id="j2jv6f"
type EmailTemplate = {
id: string;
version: number;
locale: string;
subject: string;
body: string;
category: NotificationCategory;
};




Templates should be versioned so that changes can be audited.

---

# 52.10 Template Security

User-controlled content should not be inserted into templates without proper escaping.

For example:



```text id="x9r4eu"
User Input
    |
Validation
    |
Escaping
    |
Template Rendering
    |
Email
Enter fullscreen mode Exit fullscreen mode

The template engine should prevent user input from becoming executable template syntax.

52.11 HTML Email Security

HTML emails should be carefully constructed.

Avoid unnecessarily embedding:

  • active scripts;
  • untrusted HTML;
  • sensitive user information;
  • private media URLs.

Where possible, emails should contain short-lived or authenticated links rather than exposing permanent sensitive resources.

52.12 Password Reset Emails

A password reset email should contain a short-lived, single-use recovery mechanism.

Conceptually:

Password Reset Request
       |
Generate Token
       |
Store Protected Token
       |
Send Email
       |
User Opens Link
       |
Validate Token
       |
Reset Credential
       |
Revoke Appropriate Sessions
Enter fullscreen mode Exit fullscreen mode

The token should not be reusable indefinitely.

52.13 Password Reset Enumeration

A password-reset endpoint should avoid unnecessarily revealing whether a particular email address belongs to an account.

A safer user-facing pattern is conceptually:

"If an account is associated with this address,
you will receive recovery instructions."
Enter fullscreen mode Exit fullscreen mode

The exact wording can be adapted to the application's UX.

52.14 Email Verification

Email verification should use a dedicated token lifecycle.

Create Account
     |
Verification Token
     |
Email Delivery
     |
User Verification
     |
Token Invalidated
Enter fullscreen mode Exit fullscreen mode

The system should prevent:

  • token reuse;
  • unlimited token generation;
  • brute-force guessing;
  • unauthorized email changes.

52.15 Email Change

Changing an account's email address is security-sensitive.

A stronger workflow may be:

Authenticated User
       |
Request Email Change
       |
Additional Verification
       |
Send Confirmation
       |
Verify New Address
       |
Update Identity
       |
Notify Previous Address
Enter fullscreen mode Exit fullscreen mode

Notifying the previous verified address can provide an additional security signal.

52.16 SMS Architecture

SMS may be useful for:

  • OTP;
  • alerts;
  • account recovery in selected circumstances.

However, SMS should not automatically be considered equivalent to phishing-resistant authentication.

The architecture should account for:

  • SIM-related risks;
  • delivery failures;
  • phone-number recycling;
  • abuse;
  • message interception.

52.17 OTP Generation

OTP values must be generated securely.

For example, a six-digit OTP has only a limited number of possibilities, so it must be protected by:

  • short expiration;
  • attempt limits;
  • rate limiting;
  • session binding;
  • secure generation.

Conceptual workflow:

Generate OTP
    |
Store Secure Verification State
    |
Send SMS
    |
User Submits OTP
    |
Validate
    |
Success / Failure
Enter fullscreen mode Exit fullscreen mode

52.18 OTP Security

The system should prevent repeated guessing.

Example:

OTP Attempts
     |
 1 -> Allowed
 2 -> Allowed
 3 -> Allowed
 ...
 Limit
     |
Further Attempts Blocked
Enter fullscreen mode Exit fullscreen mode

The exact limits should be determined by risk analysis.

OTP values should never appear in logs.

52.19 OTP Replay Protection

After successful verification:

OTP
 |
Validated
 |
Immediately Invalidated
Enter fullscreen mode Exit fullscreen mode

The same OTP should not remain valid for repeated authentication operations.

52.20 Notification Rate Limiting

Communication systems can be abused to send large volumes of messages.

Rate limits should exist at several levels:

User
IP / Network
Destination
Account
Organization
Notification Type
Provider
Enter fullscreen mode Exit fullscreen mode

For example:

Password Reset Requests
Email Verification Requests
OTP Requests
Invitation Emails
Enter fullscreen mode Exit fullscreen mode

Each can have its own policy.

52.21 Notification Abuse

Attackers may attempt to abuse a platform by repeatedly requesting messages to another person's address.

Example:

Attacker
   |
Repeated Reset Requests
   |
Victim Inbox
   |
Notification Flood
Enter fullscreen mode Exit fullscreen mode

Defenses include:

  • per-destination rate limits;
  • per-account limits;
  • cooldown periods;
  • abuse detection;
  • CAPTCHA or equivalent challenges where appropriate;
  • generic responses.

52.22 Push Notifications

Push notifications are useful for:

  • AI generation completion;
  • security alerts;
  • account events;
  • workflow completion.

However, notification content can become visible on a locked device.

Avoid placing unnecessary sensitive information in push payloads.

Instead of:

"Your private document 'financial_report.pdf'
was processed."
Enter fullscreen mode Exit fullscreen mode

a safer pattern may be:

"Your document is ready."
Enter fullscreen mode Exit fullscreen mode

The application can reveal details after authenticated access.

52.23 Push Token Management

Push tokens should be associated with application installations rather than treated as permanent user credentials.

Conceptually:

```typescript id="9g6xqk"
type PushDevice = {
id: string;
userId: string;
provider: string;
tokenReference: string;
createdAt: Date;
lastSeenAt: Date;
revokedAt?: Date;
};




Tokens should be revoked when devices are removed or become invalid.

---

# 52.24 In-App Notifications

In-app notifications should be stored server-side when they need persistence.

Example:



```typescript id="b5t1f7"
type InAppNotification = {
  id: string;
  userId: string;
  category: NotificationCategory;
  title: string;
  body: string;
  readAt?: Date;
  createdAt: Date;
};
Enter fullscreen mode Exit fullscreen mode

Access must use object-level authorization.

A user should only be able to retrieve their own notifications or notifications belonging to an authorized organization.

52.25 Notification Authorization

The notification system should verify:

Who triggered the event?
Who should receive it?
Why are they allowed to receive it?
What information may be disclosed?
Enter fullscreen mode Exit fullscreen mode

This is particularly important for organizational systems.

Example:

Organization A
 |
Project X
 |
Private AI Generation
 |
Notification
 |
Authorized Members Only
Enter fullscreen mode Exit fullscreen mode

52.26 Notification Privacy

Notification payloads should follow data minimization.

Avoid including:

  • passwords;
  • API keys;
  • access tokens;
  • complete private documents;
  • unnecessary personal information;
  • sensitive AI prompts.

Prefer references:

Generation Complete
View Result
Enter fullscreen mode Exit fullscreen mode

rather than embedding the actual private result in the message.

52.27 Signed Notification Links

When an email needs to link to a sensitive resource, the destination should still require appropriate authentication.

Email links should not automatically grant permanent access to private data.

If temporary signed links are used, they should:

  • expire;
  • be scoped;
  • be difficult to guess;
  • be revocable where necessary.

52.28 Communication Queues

A queue improves reliability.

Application
   |
Notification Job
   |
Queue
   |
Worker
   |
Provider
Enter fullscreen mode Exit fullscreen mode

The queue should support:

  • retries;
  • backoff;
  • dead-letter handling;
  • priority;
  • cancellation where appropriate;
  • idempotency.

52.29 Notification Job Model

A conceptual job might be:

```typescript id="1v3y0r"
type NotificationJob = {
id: string;
type: string;
recipientId: string;
channel: "email" | "sms" | "push";
attempts: number;
status: "pending" | "processing" | "sent" | "failed";
createdAt: Date;
};




The job should not contain unnecessary secrets.

---

# 52.30 Retry Strategy

Temporary provider failures may be retried.

Conceptually:



```text
Attempt 1
   |
Failure
   |
Wait
   |
Attempt 2
   |
Failure
   |
Longer Wait
   |
Attempt 3
   |
Success / Dead Letter
Enter fullscreen mode Exit fullscreen mode

Permanent errors should not be retried indefinitely.

52.31 Idempotent Notifications

Some notifications should have unique business identifiers.

For example:

PASSWORD_RESET:user123:request456
Enter fullscreen mode Exit fullscreen mode

The exact identifier should be generated safely.

Idempotency prevents accidental duplicate messages during worker retries.

52.32 Provider Abstraction

A provider abstraction allows multiple delivery providers.

```typescript id="xq0z9c"
interface EmailProvider {
send(message: EmailMessage): Promise;
}

interface SmsProvider {
send(message: SmsMessage): Promise;
}

interface PushProvider {
send(message: PushMessage): Promise;
}




This supports:

* provider failover;
* regional routing;
* cost optimization;
* testing;
* migration.

---

# 52.33 Provider Credentials

Communication providers typically require credentials.

Examples include:

* API keys;
* OAuth credentials;
* signing secrets.

These should be stored in secure secret-management infrastructure.

They should never be committed to source control.

---

# 52.34 Webhook Security

Communication providers may send webhooks such as:



```text
EMAIL_DELIVERED
EMAIL_BOUNCED
EMAIL_COMPLAINED
SMS_DELIVERED
SMS_FAILED
Enter fullscreen mode Exit fullscreen mode

Webhook processing should use:

  • signature verification;
  • schema validation;
  • replay protection;
  • idempotency;
  • audit logging.

Unverified webhook data should not directly modify account state.

52.35 Bounce Handling

Email addresses may become invalid.

The system should distinguish:

Temporary Failure
Permanent Failure
Mailbox Full
Invalid Address
Spam Complaint
Enter fullscreen mode Exit fullscreen mode

This allows appropriate action.

Repeated delivery failures may require disabling certain notifications until the address is corrected.

52.36 Spam and Abuse Controls

A responsible communication architecture should monitor:

  • send volume;
  • bounce rate;
  • complaint rate;
  • suspicious destination patterns;
  • repeated verification requests;
  • unusual organization activity.

Abuse detection protects both users and the platform's communication reputation.

52.37 Marketing vs Transactional Messages

The platform should distinguish:

Transactional

Examples:

  • password reset;
  • security alert;
  • invoice;
  • account verification.

Marketing

Examples:

  • promotional offers;
  • product campaigns;
  • newsletters.

They require different consent and preference handling.

The exact legal requirements depend on the user's jurisdiction and the communication channel.

52.38 Unsubscribe Management

Marketing communication should provide appropriate unsubscribe mechanisms.

The preference system should maintain:

Marketing Email
Marketing SMS
Product Announcements
Promotional Push
Enter fullscreen mode Exit fullscreen mode

Security and essential account communications should be handled separately.

52.39 Localization

An international AI platform may support multiple languages.

A notification should therefore be generated through:

Event
 |
User Locale
 |
Template Version
 |
Localized Content
 |
Delivery
Enter fullscreen mode Exit fullscreen mode

The system should avoid translating security-critical values incorrectly.

For example:

  • dates;
  • expiration times;
  • security terminology;
  • account identifiers.

52.40 Time-Zone Handling

Notifications involving time should use explicit time-zone rules.

For example:

UTC Event
   |
User Time Zone
   |
Localized Message
Enter fullscreen mode Exit fullscreen mode

The underlying timestamp should remain unambiguous.

52.41 Notification Preferences and Organizations

Organizations may define additional communication policies.

For example:

Organization Policy
       |
Security Alerts -> Required
Marketing -> Disabled
AI Completion -> Optional
Enter fullscreen mode Exit fullscreen mode

The final notification decision may depend on both user preferences and organization policy.

52.42 Communication Threat Model

Important threats include:

Notification Flooding

Defense:

  • rate limits;
  • cooldowns;
  • abuse detection.

OTP Brute Force

Defense:

  • short expiration;
  • attempt limits;
  • rate limiting.

Fake Webhook

Defense:

  • signature verification.

Webhook Replay

Defense:

  • event IDs;
  • timestamps;
  • replay detection.

Sensitive Data Leakage

Defense:

  • data minimization;
  • authenticated resource access.

Provider Credential Exposure

Defense:

  • secret management;
  • least privilege;
  • rotation.

Unauthorized Notification

Defense:

  • server-side authorization;
  • recipient validation.

52.43 Communication Audit Logs

Important events may include:

NOTIFICATION_CREATED
NOTIFICATION_SENT
NOTIFICATION_FAILED
OTP_REQUESTED
OTP_VERIFIED
OTP_FAILED
EMAIL_VERIFIED
PASSWORD_RESET_REQUESTED
PUSH_DEVICE_REGISTERED
PUSH_DEVICE_REVOKED
WEBHOOK_RECEIVED
WEBHOOK_REJECTED
MARKETING_OPT_IN
MARKETING_OPT_OUT
Enter fullscreen mode Exit fullscreen mode

Audit logs should avoid storing the actual OTP or sensitive message contents.

52.44 Notification Observability

Useful operational metrics include:

Delivery Success Rate
Delivery Failure Rate
Bounce Rate
Complaint Rate
OTP Failure Rate
Queue Delay
Provider Latency
Retry Count
Dead-Letter Count
Enter fullscreen mode Exit fullscreen mode

These metrics can identify both operational and security problems.

52.45 Dead-Letter Queue

Messages that repeatedly fail should move to a controlled dead-letter queue.

Notification
     |
Retries
     |
Still Failing
     |
Dead-Letter Queue
     |
Investigation / Recovery
Enter fullscreen mode Exit fullscreen mode

Dead-letter records should themselves be protected because they may contain message metadata.

52.46 Communication Data Retention

The platform should define retention policies.

Possible data categories:

Message Metadata
Delivery Events
Webhook Events
Notification Preferences
Audit Events
Failed Messages
Enter fullscreen mode Exit fullscreen mode

Not all data needs to be retained forever.

Retention should reflect:

  • security requirements;
  • operational needs;
  • legal obligations;
  • privacy principles.

52.47 Secure Notification Service Architecture

A complete architecture can be represented as:

                       Application Event
                              |
                     Notification Policy
                              |
                   Recipient Authorization
                              |
                       Template Engine
                              |
                     Privacy Filtering
                              |
                       Notification Queue
                              |
                         Worker Layer
                              |
             +----------------+----------------+
             |                |                |
           Email             SMS              Push
             |                |                |
         Provider          Provider          Provider
             |                |                |
             +----------------+----------------+
                              |
                       Delivery Webhooks
                              |
                      Verification Layer
                              |
                     Delivery / Audit DB
Enter fullscreen mode Exit fullscreen mode

52.48 Example Notification Service

```typescript id="d7eq4m"
class SecureNotificationService {
async notifyGenerationComplete(
userId: string,
generationId: string
) {
await authorization.assertCanViewGeneration(
userId,
generationId
);

const notification = await templates.render(
  "generation-complete",
  { generationId }
);

await queue.enqueue({
  type: "GENERATION_COMPLETE",
  userId,
  payload: notification
});
Enter fullscreen mode Exit fullscreen mode

}
}




The authorization check occurs before sensitive information is prepared for delivery.

---

# 52.49 Example OTP Policy



```typescript id="r8t7ce"
type OtpPolicy = {
  expiresInSeconds: number;
  maxAttempts: number;
  maxRequestsPerHour: number;
  purpose:
    | "login"
    | "mfa"
    | "email_verification"
    | "recovery";
};
Enter fullscreen mode Exit fullscreen mode

Different purposes can have different security policies.

52.50 Testing Strategy

Communication systems should be tested at multiple levels.

Unit Testing

Test:

  • template rendering;
  • preference evaluation;
  • OTP expiration;
  • retry decisions;
  • authorization.

Integration Testing

Test:

  • provider APIs;
  • webhooks;
  • queue workers;
  • delivery state changes.

Security Testing

Test:

  • unauthorized notification access;
  • OTP guessing resistance;
  • webhook verification;
  • replay resistance;
  • notification flooding;
  • template injection;
  • sensitive-data leakage.

Reliability Testing

Test:

  • provider outage;
  • queue backlog;
  • worker restart;
  • duplicate events;
  • delayed webhooks;
  • dead-letter recovery.

52.51 Production Checklist

Before production deployment:

  • [ ] Communication providers are abstracted.
  • [ ] Provider credentials are stored securely.
  • [ ] Security notifications are separated from marketing.
  • [ ] Notification authorization is enforced server-side.
  • [ ] Templates are centrally controlled.
  • [ ] User input is safely escaped.
  • [ ] Password-reset tokens are short-lived and single-use.
  • [ ] Email verification tokens are protected.
  • [ ] OTPs have expiration and attempt limits.
  • [ ] OTP values never appear in logs.
  • [ ] Notification endpoints are rate-limited.
  • [ ] Destination abuse controls exist.
  • [ ] Push payloads minimize sensitive information.
  • [ ] Notification queues support retries.
  • [ ] Duplicate jobs are handled safely.
  • [ ] Webhooks use signature verification.
  • [ ] Webhook events are idempotent.
  • [ ] Bounce and complaint handling exists.
  • [ ] Marketing preferences are respected.
  • [ ] Security alerts cannot be silently disabled when policy requires them.
  • [ ] Notification data has retention rules.
  • [ ] Communication events are audited.
  • [ ] Provider failures have recovery procedures.
  • [ ] Dead-letter processing exists.
  • [ ] Communication monitoring is operational.

52.52 Final Architecture Principle

A secure notification system follows:

Application Event
      |
Policy
      |
Authorization
      |
Privacy Filtering
      |
Template
      |
Queue
      |
Provider
      |
Verified Delivery Event
      |
Audit
Enter fullscreen mode Exit fullscreen mode

The most important principle is:

A notification should reveal only the minimum information necessary to accomplish its purpose, to a recipient who is authorized to receive it, through a delivery channel protected against abuse.

Communication infrastructure therefore becomes another security boundary of the AI platform—not merely a collection of email and SMS APIs.

Top comments (0)