Writer × AegisAI: Going Beyond Rules With AI-Native Email Security
In its first week connected to AegisAI, Writer found more than 69 malicious emails sitting in employee inboxes with no configuration or threat hunting by the team. | Measure | Result | | Increase in recall over existing stack | +26% | | Credential-theft attacks live in inboxes at time of report | 19 | | Additional spam caught | 4,021 (365 per day) | | Rules or configuration written by Writer | 0 | | User escalations after deployment | 0 | Customer: Writer, an enterprise AI platform Environment: Google Workspace, existing email security layers, Gmail native filtering

Results at a Glance
Challenges
Solutions
About Writer
Writer is one of the original pioneers of enterprise AI - building its own models. Its Palmyra model family powers AI HQ, the platform that Uber, Salesforce, Accenture, Intuit, Marriott and Vanguard use to build, activate and supervise AI agents. Writer is headquartered in San Francisco, sells exclusively to the enterprise, and ships fast. Writer’s security team is built the same way as its product. There are no appliances, no MX records rerouted through a gateway, and no mail filter someone racked in 2019. The stack is API-first and run by engineers who ship, wired so that security decisions flow through the same automation the rest of the company runs on. Few teams of its size are this far along, and fewer were asking these questions this early. The team also knows exactly what it is defending. At an AI company, the credentials that matter are not the ones a generic phishing kit chases. They are an API key for a sending platform, a Workspace mailbox, and the approval behind an invoice. Writer mapped that risk early and staffed for it, which is why it was scrutinizing its inbox layer long before anything forced the question. ## Why Writer Ran the Evaluation Writer was running several layers of email security alongside Gmail’s native filtering. But tuning rules had always been a balancing act between over-blocking and letting attacks slip through, and as AI-generated attacks became more varied, that balance got harder to find. ### Tuning rules means choosing how to fail Every rules engine forces the same trade. Tighten it, and legitimate mail lands in quarantine for someone to release by hand. Loosen it, and real attacks reach the inbox. Writer’s team invested real effort in moving that dial and never found a setting that was right in both directions. The threshold strict enough to catch a vendor-themed lure also caught customer and prospect mail. The threshold that let customer mail through let the lure through too. That is not a tuning failure. It is a property of deciding by pattern match: a rule cannot tell a real invoice from a fraudulent one, only a familiar pattern from an unfamiliar one. Getting out of that trade is what led the team to an AI-native approach rather than a better-tuned rule set. > I was tired of choosing which way to be wrong. Tighten the rules and my team releases customer mail by hand. Loosen them and something real lands. Going AI-native meant I stopped tuning a dial and started getting verdicts with the evidence attached. ### The attack surface grows faster than anyone can write rules Freeman has written publicly about this problem. In his framing, “a threat model is a graph”: features, integrations and agent tool calls are its edges, and the graph grows with every merge. You cannot hire your way past it. A defense that needs someone to describe each new attack before it can catch one is structurally behind the attacker. ### A detector is not a control Freeman has also been blunt about the industry’s habit of selling alerts instead of outcomes. “A detector is a doorbell,” he wrote. “It can tell you somebody is at the door. It doesn’t lock it.” Writer’s existing setup had the same limit. It scored mail that something else had already flagged as suspicious. It did not investigate every message, and it could not show what sat at the end of an attack chain. ### Finding out cost nothing AegisAI connects to Google Workspace through a read-only API and analyzes mail already sitting in inboxes. The evaluation required no commitment, no change to mail flow and no production risk. Writer ran both systems side by side on the same live traffic for eleven days and compared the results. The intent was explicit from the day the shared channel opened: settle the question with evidence, not vendor claims.
What was getting through
The Problem: Novel Attacks No One Has Written a Rule For
A rule can only be written for something someone has already seen. The attacks reaching Writer were built to give a rule nothing to fire on: real sending platforms, compromised vendor domains, valid SPF and DKIM, lookalike infrastructure registered the morning of the attack, and a malicious link hidden one layer down inside an attachment. Three are worth examining in full. Each made their way into user inboxes. | Attack | Why every rule passed it | Where it leads | | DocuSign envelope lure, sent to a finance user | Sent from the genuine DocuSign platform (dse_NA3@docusign.net), SPF and DKIM passing on docusign.net. The fraudulent remittance advice is a PDF inside a real envelope. | Credential harvest at a QuickBooks lookalike: quickbooks.echomint.us | | Voicemail lure from a compromised vendor | Sent from dcbconst.com, a real vendor domain the attacker had compromised. SPF and DKIM passing, with a genuine business reply chain padded underneath to borrow reputation. | Fake Google Voice page harvesting the user’s Workspace password | | SendGrid API alert, aimed at a developer | SendGrid abuse from bluefireins.com, SPF and DKIM passing, linking to a pixel-accurate Twilio SendGrid sign-in clone on sendgrid.us-corp2.com, first seen the day it was used. | SendGrid API key theft, then outbound abuse from Writer’s own infrastructure | None of these is a variant of a known campaign. Each is a one-off construction aimed at a named person in a named role, and the giveaway is not in the headers. It is that the request makes no sense in context: an accounts-payable envelope sent to someone who does not pay that vendor, a voicemail notification from a construction supplier, an API permissions alert pointing to a domain registered that morning. AegisAI’s agents reason about who is asking for what. They follow links to their final destination and open attachments to find what is hidden one layer down. > ‘No rule matched’ isn’t an answer when the sender is a real DocuSign address. Somebody has to open the PDF and follow the link all the way to the end. Nobody has the headcount to do that on every email, and that is exactly the work AegisAI took off my team.
Deployment
Live Traffic, Real Results
This was not a comparison performed in a vacuum; AegisAI scored the same live traffic the existing solution was already filtering, over the same window, against a ground-truth labeled set. The malicious emails AegisAI found were not quarantined, not flagged and not waiting in a review queue. They were delivered, and Writer employees had opened several of them. Some credential-theft attacks were still live when the report was written, either unread in one inbox or already clicked in another. That includes the three attacks above, which were still reachable when the findings were presented. > The first report wasn’t a benchmark. It was more than a dozen credential-theft emails sitting in my users’ inboxes, with a link to each one. You can’t be clearer than that. The gap is held in the tier below “malicious” as well. On top of Gmail’s native filtering, AegisAI caught 4,021 additional spam messages over the same window, roughly 365 a day that Writer’s people would otherwise have triaged by hand. Every miss shared one trait: the infrastructure or sender was legitimate at the moment of delivery. That is the boundary of rule-based detection, not a tuning problem. No change to a threshold would have caught a genuine DocuSign envelope carrying a fraudulent PDF. > Rule-based systems rely on the mail already being flagged by something else. AegisAI investigated everything and showed me the malicious content at the end of the chain. One gives you a finding. The other gives you a fix. Run them side by side on your own traffic for a week and you can stop wondering.
Visibility
What AegisAI detected
Per-user analytics
Deployment: Three Fields, Nothing to Configure
Writer’s entire setup was a single Slack message. Damian, who leads security engineering, provided three items: a super admin, an AegisAI administrator, and a list of addresses to exclude from scanning. That was the full list. No rules written, no thresholds tuned, no models retrained. No MX record changes, no mail rerouting, no appliance racked and no endpoint agent installed. Existing filtering kept running, untouched, throughout. > We connected AegisAI on a Tuesday, and by the end of the week I was looking at real attacks in my own inboxes. No scoping call, no statement of work, no six-week baseline to sit through before it says anything useful. It just brought me answers. The system adapts on its own instead of asking for configuration. In the first week, AegisAI’s agents followed a link in an Ethena phishing simulation because it looked exactly like a real attack. The platform self-corrected immediately, registering Ethena as Writer’s training vendor so simulation links are now recognized and left alone. No one at Writer wrote an allowlist entry, and AegisAI flagged the click to Writer so it would not skew Ethena’s results. ## Integration: MCP for an Agentic Security Stack On day one, before any contract existed, Writer asked what AegisAI could feed into its SIEM and the rest of its stack. For a team that builds agents for a living, the real question was sharper: not does it have an API, but can our agents use it directly. AegisAI exposes every detection in three ways: a REST API, a CrowdStrike integration and an MCP server. The MCP server is what fits Writer best. It turns AegisAI’s detections into a tool Writer’s own agents can call, rather than a feed someone has to build a connector for. Agents can ask which users were targeted this week, what evidence sits behind a verdict, or whether a flagged mailbox matches an endpoint alert. An agentic security program needs a detection layer agents can call. A rule engine that drops alerts into a queue cannot provide that. As a result, AegisAI slots into the stack instead of becoming one more console someone has to remember to check. > Everything in our stack has to be callable by an agent. A detector that drops alerts into a queue is a dead end. MCP means my agents can ask AegisAI a question and get the evidence back, not just a score.
Less to think about
Where Writer Is Now, and What Comes Next
On October 1, Writer moved from evaluation to enforcement. It took one additional permission on the same tenant and no change to production. AegisAI now quarantines what it had previously only labeled. **Clearing live attacks.** Every credential-theft finding carries a console link, so the response is a quarantine or a password reset rather than an investigation. One user had replied to an attacker, which raises the odds of a follow-up attempt against that person. **Calendar, not just the inbox.** With quarantine enabled, attacks delivered as meeting invites are removed from users’ calendars as well as their mailboxes. **Modules under evaluation.** Data loss prevention is first, with shadow IT, account takeover, phishing simulation and brand protection available on top of core detection. For a security team that builds agents, the measure is not how many alerts arrive. It is how little of the system anyone has to operate. Writer configured three fields, granted one permission, and wrote nothing. > Account takeover, DLP, shadow IT and brand protection are four products, four consoles and four renewals everywhere else. Here they’re the same agents. We didn’t just save money. We stopped maintaining four integrations nobody owned. ## Two AI-Native Companies, One Bet Writer builds agents that enterprises trust with their work. AegisAI builds agents that investigate every inbound email the way a senior analyst would. Neither could have shipped what it ships three years ago, and neither is defending a product designed for a slower threat. That is what makes this integration more than a webhook. Writer’s security team calls AegisAI’s detections from its own agents. What AegisAI ships next, including automated action on identity risk, data loss prevention, account takeover and brand protection, arrives on the same agents, the same models and the same console, with no new rule library in between. As Writer’s agent surface grows, the layer defending it grows on the same curve. The email security market has spent a decade selling detectors and leaving the operating to the customer. Both companies are built on the opposite bet: systems that do the work and show the evidence. Writer is proving it in the product enterprises run on. AegisAI is proving it in the inbox.
See what AI-native security feels like
Thirty minutes. Real attacks pulled from environments like yours (BEC, vendor fraud, credential phishing) with the reasoning behind each verdict. No setup required.
Five-minute connect · monitoring mode · disconnect any time without touching mail routing
