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 noti...
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
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
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";
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
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
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
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
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."
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
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
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
52.18 OTP Security
The system should prevent repeated guessing.
Example:
OTP Attempts
|
1 -> Allowed
2 -> Allowed
3 -> Allowed
...
Limit
|
Further Attempts Blocked
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
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
For example:
Password Reset Requests
Email Verification Requests
OTP Requests
Invitation Emails
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
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."
a safer pattern may be:
"Your document is ready."
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;
};
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?
This is particularly important for organizational systems.
Example:
Organization A
|
Project X
|
Private AI Generation
|
Notification
|
Authorized Members Only
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
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
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
Permanent errors should not be retried indefinitely.
52.31 Idempotent Notifications
Some notifications should have unique business identifiers.
For example:
PASSWORD_RESET:user123:request456
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
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
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
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
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
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
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
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
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
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
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
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
});
}
}
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";
};
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
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.