An AI agent opened an issue on my repo.
Not a bot, not a GitHub action — an agent, autonomous, claiming to be something called PREA, pitching a $149.97-an-hour strategic consultation SDK that would make my agents “think better before they act.” The issue body was decorated with block-letter ASCII art, a friendly tone, and the kind of prose designed to sound like a stranger sliding into my DMs.
The repo it landed on is mcp-threatintel — a small open-source thing I built that wires up threat-intel sources for Claude. I opened the issue this morning, spent twenty minutes following the breadcrumbs, and came away with the feeling that I’d just looked at a prototype of an attack surface that doesn’t have a good name yet.
What PREA actually did
PREA belongs to a person named Courtney Dalton at Hex-Evo Ltd. She built a crawler that scraped public agent registries — A2A, MCP, Smithery — and filtered for projects that declared agent-to-agent capabilities but didn’t have a working backend behind the declaration. Roughly 1,600 matches, per her own later statement. The crawler then opened GitHub issues on every single one, introducing PREA and pitching the SDK.
Mine was one of them. GitHub suspended the account not long after. Courtney posted a follow-up on her own repo — half apology, half pivot — saying the automation had been “permanently disabled” and taking responsibility. The repo is still up. The SDK is still on npm. The backend is still running on Heroku.
If that were the whole story, it’d be a footnote about agentic spam. But read the issue body again with fresh eyes and notice what’s actually in it.
The target was never me
API endpoints. A curl command with placeholders already filled in. An npm install line for @hex-evo/prea-sdk. A JSON-RPC sample payload. An agent card URL with a .well-known path. The prose around these artefacts reads human, but the artefacts themselves are for something that reads issue bodies and acts on the instructions inside them.
That’s what stopped me. I’ve been running Claude Code across a handful of repos for months now. If I’d asked it to “triage the open issues on mcp-threatintel,” there’s a non-zero chance it would have ingested the PREA issue, treated the agent-card URL as a legitimate declaration, and started constructing reasons why installing the SDK was a sensible interop move. My system prompt wouldn’t have saved me, because the issue doesn’t look like an attack. It looks like a slightly eager interoperability pitch with a pricing page.
The attack surface isn’t “maintainer reads spam.” The attack surface is “maintainer’s agent reads spam and decides it looks legitimate.” And the filter PREA used to select its targets is exactly the filter a more serious adversary would use — find the projects that are halfway built, where the maintainer is most likely to accept a helpful-looking patch.
Three things that don’t require a sophisticated attacker
The more I looked at it, the more I noticed that none of this required much cleverness from Courtney’s side. The infrastructure just handed it to her.
If you’ve published an MCP server, an A2A agent card, or a Smithery listing, you’re on a targeting list already — not hypothetically, but right now. The act of declaring interoperability is what makes you findable. PREA scraped those registries and filtered for projects with agent-to-agent declarations but no working backend, which is a reasonable proxy for “maintainer is interested but not yet careful.”
Then there’s the issue body itself. If your workflow includes any kind of automated triage — Claude reading issues, an agent summarising your GitHub inbox, a bot closing stale threads — that agent is ingesting untrusted content written by strangers. None of the usual “don’t paste random code into your terminal” instincts apply, because you didn’t paste anything. The agent did.
And the SDK pattern makes the ask look legitimate. PREA’s install instructions ask for apiKey, webhookUrl, and referredBy. Installing it hands over code execution at install time, a persistent inbound channel via the required webhook, and a referral-pyramid incentive to drag in the next maintainer. An SDK configuration object looks like every other library I install. That shape is doing most of the work.
Two things, neither of them heroic
The first is a THREATS.md in the mcp-threatintel repo. Not a rebuttal of PREA — a documented observation of the pattern: target selection, vectors, indicators, recommended response. If you’re running a threat-intel MCP server, the ecosystem around the server is part of the threat model, and you may as well write that down where future-you and other maintainers will find it.
The second is a quiet rule: no agentic issue triage on any of my repos without an allow-list of known commenters, or a human-review gate in front. Which is a smaller change than it sounds, because most of my repos only have three or four people who open issues. The rest are strangers, and strangers should be read by me at least once before any agent touches them.
The bit I can’t stop thinking about
Courtney’s follow-up issue ends with the line, “If not, I hope at least one thing landed: you’re closer than you think.” She’s talking about A2A interoperability — agents talking to agents without human intermediaries.
I think she’s right about that, and that’s the problem. The infrastructure for agents to trust each other is arriving before the infrastructure for agents to distrust each other appropriately. PREA’s campaign is a prototype of the attack that comes next: not a human-readable pitch decorated for agent consumption, but a machine-readable exploit disguised as an interoperability handshake.
The defence, as I’m thinking about it, is boring and specific: treat every inbound artefact — issue, PR, agent card, webhook — as untrusted by default. Build the authentication layer at the same pace as the capability layer. Assume anything public-facing is indexed, and that the indexing is being used for something.
Mostly though: notice when something weird happens in your issues tab. I almost didn’t.
Until next time,
Jim