2026-02-02 · Authensor

How to Prevent AI Agents from Sending Unauthorized Emails

To prevent AI agents from sending unauthorized emails, Slack messages, or notifications, use SafeClaw action-level gating to block network and shell_exec actions targeting SMTP servers, messaging APIs, and notification endpoints. SafeClaw denies outbound communication attempts before they execute. Install with npx @authensor/safeclaw.

The Risk

An AI agent with network access or shell access can send emails. sendmail, curl to an SMTP API, calls to SendGrid/Mailgun/SES endpoints, Slack webhook posts — these are all standard commands an agent can generate. If the agent decides that "notify the team" means sending an email to your entire customer list, that email goes out instantly. There is no unsend.

The consequences scale fast. An agent sending a test email to one person is embarrassing. An agent sending a hallucinated status update to 10,000 customers from your verified domain is a business crisis. An agent posting confidential information to a public Slack channel is a data breach. An agent triggering a webhook that sends SMS notifications at $0.01 per message to your entire user base is an unexpected bill.

Agents generate outbound communication for reasonable purposes — sending deployment notifications, alerting on errors, responding to support tickets. The problem is that the agent doesn't verify recipients, doesn't check content, and doesn't understand the difference between a test environment and production. "Send a test notification" can target real users if the agent pulls contacts from a production database.

Email is particularly dangerous because it comes from your domain, your SMTP credentials, with your DKIM signature. Recipients have no way to know an AI sent it. This creates legal, compliance, and reputation risks.

The One-Minute Fix

Step 1: Install SafeClaw.

npx @authensor/safeclaw

Step 2: Get your free API key at safeclaw.onrender.com (7-day renewable, no credit card).

Step 3: Add this policy rule:

- action: network
  pattern: "smtp|sendgrid|mailgun|ses\\.amazonaws|slack\\.com/api|hooks\\.slack\\.com"
  effect: deny
  reason: "Outbound email and messaging blocked"

The agent can no longer send emails, Slack messages, or notifications through any common service.

Full Policy

name: block-outbound-messaging version: "1.0" defaultEffect: deny rules: # Block SMTP connections - action: network pattern: "smtp://|:587|:465|:25" effect: deny reason: "SMTP connections blocked" # Block email API services - action: network pattern: "sendgrid\\.com|mailgun\\.net|ses\\.amazonaws|postmarkapp\\.com|mailchimp\\.com|sparkpost\\.com" effect: deny reason: "Email API service access blocked" # Block messaging platform APIs - action: network pattern: "slack\\.com/api|hooks\\.slack\\.com|discord\\.com/api|api\\.telegram\\.org" effect: deny reason: "Messaging platform API access blocked" # Block SMS/notification services - action: network pattern: "twilio\\.com|nexmo\\.com|vonage\\.com|sns\\.amazonaws|pushover\\.net" effect: deny reason: "SMS and notification service access blocked" # Block sendmail and mail CLI commands - action: shell_exec pattern: "sendmail|mail\\s+-s|mutt\\s|postfix" effect: deny reason: "CLI email commands blocked"

# Allow standard development network access - action: network pattern: "registry\\.npmjs\\.org|api\\.github\\.com|pypi\\.org|localhost|127\\.0\\.0\\.1" effect: allow reason: "Development services permitted"

What Gets Blocked

These action requests are DENIED:

{
  "action": "network",
  "url": "https://api.sendgrid.com/v3/mail/send",
  "agent": "notification-bot",
  "result": "DENIED — Email API service access blocked"
}

{
  "action": "network",
  "url": "https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXX",
  "agent": "deploy-agent",
  "result": "DENIED — Messaging platform API access blocked"
}

{
  "action": "shell_exec",
  "command": "sendmail customer@example.com < /tmp/message.txt",
  "agent": "support-agent",
  "result": "DENIED — CLI email commands blocked"
}

What Still Works

These safe actions are ALLOWED:

{
  "action": "network",
  "url": "https://registry.npmjs.org/express",
  "agent": "code-assistant",
  "result": "ALLOWED — Development services permitted"
}

{
  "action": "network",
  "url": "https://api.github.com/repos/user/project/pulls",
  "agent": "code-assistant",
  "result": "ALLOWED — Development services permitted"
}

Your agent can still access npm, GitHub, PyPI, and localhost for development work. It just can't send emails, messages, or notifications to external services.

Why Other Approaches Don't Work

Revoking SMTP credentials prevents the agent from using your email service, but it also prevents your application from sending emails. And the agent can still use sendmail or any other local mail transfer agent on the system.

Network firewalls can block outbound SMTP but require OS-level configuration, don't discriminate between your application's legitimate emails and the agent's unauthorized ones, and don't cover HTTP-based email APIs (SendGrid, Mailgun, SES).

Prompt instructions ("never send emails") are not enforceable. The agent may interpret "notify the team about the deploy" as a direct instruction to send emails, overriding any system prompt guardrails.

API key scoping (read-only SendGrid keys) helps for one service but doesn't cover all messaging channels. The agent could use curl to hit a Slack webhook that doesn't require authentication, or use the local sendmail binary.

SafeClaw blocks both network actions to messaging APIs and shell_exec actions using mail commands. Sub-millisecond evaluation. Deny-by-default architecture means new messaging services are blocked automatically. Every denied action is logged in a tamper-proof audit trail (SHA-256 hash chain). 446 tests, TypeScript strict mode, zero third-party dependencies. The control plane sees only action metadata, never your email content or recipients.

Cross-References

Try SafeClaw

Action-level gating for AI agents. Set it up in your browser in 60 seconds.

$ npx @authensor/safeclaw