I let AI bots read my content, then figured out how to charge them 🤖💸

I let AI bots read my content, then figured out how to charge them 🤖💸

A build-in-public story about AWS, encrypted disks that fight back, and teaching a compliance framework to talk to an AI agent

Okay so here's the thing nobody tells you about launching a compliance advisory business: at some point you end up in a terminal at 11pm arguing with a Mac Mini about a LUKS passphrase. This is that story. 🫠

🏗️ The setup

I run First Step Technology, a cybersecurity/compliance advisory shop. I also, apparently, cannot help myself when it comes to "let's just build the infrastructure instead of paying someone else to."

So ComplianceFirst.io

went from idea to fully live AWS deployment: CloudFront + S3, layered WAF (IP reputation, OWASP core rules, known-bad-inputs, Bot Control), least-privilege IAM split between a console admin identity and a scoped CLI deployer. Standard stuff, mostly.

Then I found out AWS shipped something wild: AI Traffic Monetization. You can literally charge AI bots — GPTBot, ClaudeBot, PerplexityBot, the whole crew — for crawling your content. Real USDC settlement via the x402 protocol, through Coinbase's developer platform.

I was not going to let that sit unused. 👀

🧱 The console doesn't have the button you're looking for

Here's a fun one for anyone who's tried this: the AWS WAF console straight up does not expose the Monetize action anywhere in the visual rule builder. Allow, Block, Count, CAPTCHA, Challenge — that's it. I spent way too long convinced I was missing a button.

Turns out the feature is real, it's just API/CLI-only right now. So instead of clicking, I ended up:

aws wafv2 update-web-acl --generate-cli-skeleton > skeleton.json
grep -A 10 '"Monetize"' skeleton.json

…and built the rule directly against the real, live API schema instead of trusting a blog post (including mine, going forward — always verify against --generate-cli-skeleton

, don't trust docs that might be stale). Turns out PriceMultiplier

wants a whole number 1-100 as a percentage, not a decimal like I first assumed. AWS's own validation error caught that one for me. 🙏

{
  "Name": "monetize-verified-ai-bots",
  "Statement": {
    "LabelMatchStatement": {
      "Scope": "LABEL",
      "Key": "awswaf:managed:aws:bot-control:bot:category:ai"
    }
  },
  "Action": {
    "Monetize": { "PriceMultiplier": "100" }
  }
}

Ran it in test mode on Base Sepolia first, obviously. Within a day: 141 real requests from GPTBot, ChatGPT-User, ClaudeBot, Bytespider, Perplexity, Meta's crawler, Cohere. Real companies, real traffic, all correctly labeled and ready to monetize once I flip to mainnet. 🎉

🔐 Then the Mac Mini decided to fight me

Separate project, same week: standing up a third machine for internal docs + a compliance data pipeline. Full-disk LUKS encryption, because obviously — it's going to hold client compliance data eventually.

Problem: encrypted disks don't unlock themselves, and this machine is headless. Enter dropbear-initramfs

— a tiny SSH server that runs before the real OS even boots, so you can unlock the disk remotely instead of walking over with a keyboard every single reboot.

I set it up. It "worked." Then it didn't. ssh root@ip

→ connection refused → dropbear clearly starting on screen → nothing listening. Spent a chunk of time convinced it was a networking issue.

It wasn't. The actual bug: dropbear can't read standard OpenSSH-format private keys. It needs its own binary format. My first pass just did a plain cp

of the host key — which looks like it works, right up until dropbear tries to actually parse it and chokes.

sudo dropbearconvert openssh dropbear \
  /etc/ssh/ssh_host_ed25519_key \
  /etc/dropbear/initramfs/dropbear_ed25519_host_key

One command. That was it. Also found a sneaky trailing space in /etc/initramfs-tools/initramfs.conf

on the DEVICE=

line that wasn't helping. Config files really do just sit there quietly wrecking your day. 😤

📜 Turning a PDF into something an AI agent can actually use

The actual point of that machine: a pipeline that pulls real NVD vulnerability data and NIST framework controls, then converts each requirement into structured JSON with plain-English guidance an AI coding assistant can act on.

def generate_agent_rule(control_id, framework):
    ...

Real output, for real control 3.1.1 of NIST SP 800-171:

{
  "control_id": "3.1.1",
  "requirement": "Limit system access to authorized users...",
  "agent_guidance": "When generating or reviewing code/infrastructure,
    ensure compliance with control 3.1.1... Flag any implementation
    that does not satisfy: Limit system access to authorized users..."
}

Drop that into Claude Projects or a Copilot instructions file, and your AI assistant starts reasoning about compliance gaps while you're writing code, instead of everyone finding out three weeks before an audit. 110 controls done for CMMC Level 2, 15 more for CMMC Level 1 (fun fact: that one's not even a NIST framework, it maps to a completely different source, FAR 52.204-21 — learned that the hard way when NIST's own catalog search came up empty).

Important caveat I'm putting in writing for anyone building something similar: this isn't a scanner. It doesn't background-sweep your repo. It's context that makes your AI's reasoning better informed — think "editor with a style guide," not "automated compliance certification." Setting that expectation correctly with clients matters a lot more than the tech itself.

🎯 What I'd tell someone starting this

--generate-cli-skeleton

before assuming you're wrongcp

-ing a key file between two tools that both technically "use SSH keys" is not a safe assumption — formats differAnyway. Bots are reading my compliance articles and will soon be paying for the privilege, and my Mac Mini finally unlocks itself like a reasonable adult. Building in public is chaotic but I'm here for it. 🚀

#aws

#buildinpublic

#cybersecurity

#compliance

#selfhosted

#linux