Notes from the desk

Detections.ai is a community library for detection engineering. Its pitch is one line: “Someone already wrote it. Find it. ‘Borrow’ it. Make it yours.”

As of 30 September 2026 the site claims tens of thousands of community detections and 17,000 detection engineers. It adds an AI assistant that generates and refines rules, translation across nine query languages, and MITRE ATT&CK mapping. The community tier is free. Private team workspaces and automated hunting sit in a paid enterprise tier.

For a small team with no dedicated detection engineer, that’s the useful part. For common techniques, a rule usually exists already. Finding it is faster than writing one.

Treat what you borrow like any other code from the internet. Read the logic, test it against your own logs for false positives, and check that the fields it queries exist in your data before it goes live. A community rule you haven’t tested is a guess about someone else’s environment.

Simon Willison’s lethal trifecta is the best one-line test I know for an AI agent. An agent is exposed when it has all three of: access to private data, exposure to untrusted content, and a way to communicate externally. With all three, anyone who can put text in front of the model can ask it to send your data out, and it may well do it.

I used it for business workflows in the least-autonomy post. The same test applies to the coding agent on your own machine, and that’s where it’s easiest to miss.

A coding agent already reads your repos, your .env files and whatever your shell can reach. That’s the first leg. Add an MCP server that reads GitHub issues, web pages or email, and you have the second: anyone can file an issue. Add web fetch, a tool that opens pull requests, or plain curl, and you have the third. Willison’s post cites a real case, found by Marco Milanta and Luca Beurer-Kellner: the GitHub MCP server read a malicious public issue and leaked private repo data through a pull request.

Before you add the next MCP server, ask three questions:

1. What private data can this session reach?
2. What text in this session did someone else write?
3. What can this session send, post or fetch?

If all three have answers, take one away. Use a separate session for untrusted content, give it no secrets, or block outbound requests. Guardrail products that promise to catch “95% of attacks” don’t fix this. As Willison puts it, in web application security 95% is a failing grade.

I run my own setup the same way. A separate session reads untrusted content and holds no secrets. Web fetch, curl and pull-request tools ask before they run. I add MCP servers one at a time and put these three questions to each.