Building an automated threat intelligence publication

Nirad sells network security to Indian enterprises and government bodies, mostly through partners. Between deals there was no regular reason for a buyer, or a partner's customer, to hear from us. Global threat feeds exist, but they rarely focus on the actors and incidents that matter to Indian organisations. That gap was the editorial angle.

Issues are drafted and checked by AI agents, then pushed to a working branch of the repository. Once I approve the build, it merges to main through a pull request and deploys automatically on Cloudflare Pages. The build also generates the site's RSS feeds, and the email side runs off those feeds, so after my go-ahead everything downstream happens on its own.

Three feeds, not one

A single feed would have sent a Friday "weekly brief" email stuffed with five AI Watch items, which isn't what subscribers signed up for. The email platform can't filter one feed by category, so the build generates a separate feed per edition and each gets its own scheduled email campaign. The digest leads with one story summarised in full, followed by headline links for the rest.

Agents write and check. I approve. Everything after that is automatic.

Getting agents to write something a security team would trust

Writing more than 60 issues by hand wasn't realistic for a one-person marketing team, so I built the editorial side as a set of AI agents. A writer agent researches the latest disclosures and drafts each issue in the publication's fixed structure: what happened, why it matters for India, the action to take, and the sources behind every claim.

Drafting turned out to be the easy part. In threat intelligence, a wrong version number or an unsourced claim does real damage to the brand, so no draft goes straight out. Validator agents review it first and send it back to the writer when a check fails. They run four checks on every story: each claim has a cited source; CVE IDs, version numbers and dates are correct; the story is genuinely relevant to Indian organisations; and it follows the fixed format of what happened, why it matters, the action to take, and sources. Only a draft that passes every check is pushed to the repository.

The last gate is me. I review the build and give the go-ahead before it merges and ships. I kept that step on purpose: an automated security publication still needs a person accountable for what it says.

Confirmation emails were landing in spam

The emails were going out from the email platform's generic shared address, with no authentication for our domain. I traced the company's DNS and mail setup, found an existing SPF record with a hard-fail policy that a naive addition would have broken, and wrote exact instructions for IT: a merged SPF record, a DKIM record, domain verification and a monitoring-mode DMARC policy. After IT applied them, the platform confirmed the domain and a raw-header check showed SPF, DKIM and DMARC all passing.

Every signup was silently failing

The subscribe form returned a success response, the visitor saw a success message, and nothing arrived in the subscriber list. Working through the browser's network requests, I found the cause: the form posted directly to the email platform in a mode that can't carry a captcha token, while the platform had reCAPTCHA switched on for that form. Every submission was rejected without an error. Turning the captcha off fixed it immediately.

That removed the bot protection, so I replaced it with a hidden honeypot field and a time check that rejects submissions made faster than a person could type. I also moved to single opt-in to cut friction, and rewrote the success message so it no longer told people to check an inbox for a confirmation that wasn't coming.

Header check after IT applied the DNS changes I specified.

The bug that was dropping every signup, and the replacement bot protection.